Possui diversas bases de conhecimento e pretende reunir pelo menos algumas delas. Mas qual o conteúdo que deve ser migrado? O que deve permanecer onde está? E o que acontece com artigos duplicados, traduções, anexos ou páginas que já estão bem posicionadas no Google?
Neste guia, vamos começar pela consolidação da base de conhecimento (incluindo quando faz mais sentido manter alguns conteúdos separados) e depois abordar a migração da base de conhecimento em si: o que pode ser migrado, como se preparar para isso e como evitar que o conteúdo e o tráfego de pesquisa se percam durante o processo.
O que é a consolidação de bases de conhecimento?
Estes elementos nem sempre têm equivalentes diretos no novo sistema: uma base de conhecimento pode utilizar categorias enquanto outra utiliza pastas, ou armazenar traduções e campos de artigos de forma diferente. Portanto, pode acabar por organizar o conteúdo de forma diferente depois de tudo estar num só lugar.
Consolidação versus integração: de qual precisa?
As pessoas optam pela integração quando querem manter as bases de conhecimento separadas, mas facilitar a localização do conteúdo. Dito isto, deve considerar a consolidação se quiser deixar de manter a mesma informação em locais diferentes.
Digamos que os seus programadores mantêm a documentação técnica no Confluence e a sua equipa de suporte publica o guia do cliente no Zendesk. Todos estão satisfeitos por continuar a utilizar estes sistemas, mas os colaboradores querem pesquisar em ambos a partir de um único lugar. Nesse caso, a pesquisa federada pode ser suficiente. O Happeo, por exemplo, pode exibir resultados de sistemas conectados, como Confluence e Zendesk na mesma interface de pesquisa.
No entanto, a pesquisa federada não ajudará se o problema estiver no próprio conteúdo. Se as duas bases de conhecimento se sobrepõem, ainda terá de manter duas versões da mesma informação. A consolidação de bases de conhecimento permite unificar o conteúdo de ambas e manter uma única versão.
Mas não precisa de consolidar tudo. O seu conteúdo de suporte pode ir para uma única base de conhecimento, enquanto os seus programadores mantêm a documentação no Confluence, onde já a gerem.
Quando manter as bases de conhecimento separadas faz mais sentido
Mantenha as suas bases de conhecimento separadas, desde que cada uma ainda tenha uma razão clara para existir. Por exemplo:
- Os seus leitores precisam de informações diferentes. Os clientes podem querer instruções sobre como alterar as definições da conta, e os agentes de suporte necessitam do procedimento de escalonamento para uma alteração que não ocorreu.
- Alguns conteúdos requerem um acesso mais restrito. A divisão entre base de conhecimento interna e externa pode valer a pena manter se restringir as instruções internas, mas disponibilizar os seus artigos públicos a todos.
- A propriedade do conteúdo já é clara. Os programadores podem manter a documentação técnica onde já a atualizam, enquanto a equipa de suporte trata dos artigos orientados para o cliente.
Veja agora o que acontece após uma mudança de produto. Duas pessoas precisam de atualizar dois artigos que respondam à mesma questão? Têm de se lembrar qual a versão que pertence a qual sistema? Os leitores encontram por vezes as duas versões?
Nesse caso, está a manter o mesmo conhecimento duas vezes. Reunir estes artigos resulta numa única versão para atualizar, deixando o resto das suas bases de conhecimento intactas.
Por que razão as equipas acabam por consolidar bases de conhecimento?
As empresas desejam ter cinco locais para documentação. Uma base de conhecimento pode ser adquirida. O suporte pode começar a utilizar uma nova plataforma, enquanto os artigos úteis permanecem na antiga. As equipas de produto e de suporte podem criar documentação separada e, posteriormente, descobrir que parte dela aborda os mesmos assuntos.
Portanto, antes de combinar bases de conhecimento, descubra como chegou a elas. A resposta irá ajudá-lo a decidir o que reunir e o que faz sentido manter separado.
Fusões e aquisições
Uma aquisição pode deixá-lo com anos de conteúdo que ainda precisa. Quando a Oneflare adquiriu a UrbanYou, esta última contava com mais de 200.000 tickets, para além da sua base de conhecimento e outros dados de clientes. A Oneflare queria manter este histórico, pelo que Help Desk Migration o transferiu para a nova Zendesk .
Mas antes de combinar o conteúdo das centrais de ajuda das duas empresas, examine atentamente os artigos. Pode encontrar um que ainda receba tráfego, mas use a marca antiga, ou um que aborde o mesmo tópico que o seu, mas que tenha alguns detalhes que faltam no seu artigo. Decida o que fazer em cada um destes casos antes de fundir várias bases de conhecimento, enquanto ainda tem as versões originais em front .
Proliferação de ferramentas e documentação duplicada
A proliferação de bases de conhecimento torna-se um bom motivo para consolidar as ferramentas de documentação quando as pessoas têm de pensar em que secção de um artigo se enquadra antes de poderem trabalhar nele.
Imagine que pretende consolidar a documentação entre equipas. O suporte tem a sua central de ajuda, o produto mantém a sua própria documentação e os artigos antigos ainda estão num sistema que ninguém desativou completamente. Um novo artigo poderia facilmente ser publicado em mais do que um destes sistemas, pelo que a sua localização depende geralmente de quem o publica. Com o tempo, o conteúdo relacionado acaba por se espalhar por estes sistemas, mesmo que ninguém crie duplicados deliberadamente.
Custo de uma base de conhecimento fragmentada
Num inquérito da APQC de 2021 a 982 trabalhadores do conhecimento, os inquiridos gastaram, em média, 2,8 horas por semana a procurar ou a solicitar informações de que necessitavam. Os colaboradores também referiram perder tempo a recriar informações já existentes e a procurar pessoas que pudessem responder às suas perguntas.
A documentação fragmentada pode gerar o mesmo tipo de trabalho. Um artigo numa base de conhecimento pode responder à questão, mas é ainda necessário verificar se outro sistema tem uma versão mais recente. Esta é uma etapa extra que a consolidação da gestão do conhecimento pode eliminar ao reunir conteúdo sobreposto.
O que pode consolidar
O que pode migrar depende das duas plataformas envolvidas. Um registo ou campo existente na origem pode não ter equivalente no destino, pelo que a migração necessita de funcionar dentro dos limites suportados por ambos os sistemas.
Artigos, categorias e meios de comunicação
Mantenha a relação entre um artigo e tudo o que o leitor necessita para o utilizar. Por exemplo, um guia de instalação perde parte do seu valor se as capturas de ecrã desaparecerem, e um artigo de resolução de problemas pode ficar incompleto sem o PDF anexado.
As categorias requerem um pouco mais de planeamento, uma vez que as duas plataformas podem organizar os artigos de formas diferentes. Pode mapear uma categoria de origem para uma categoria ou pasta diferente no destino, em vez de copiar a estrutura antiga exatamente. Help Desk Migration suporta este tipo de mapeamento, bem como imagens e anexos incorporados, para pares de plataformas compatíveis.
Traduções e conteúdos multilingues
Verifique as traduções separadamente. Algumas plataformas permitem migrá-las juntamente com os artigos originais; outras deixam apenas o conteúdo na língua padrão.
Mesmo quando ambas as plataformas suportam traduções, a forma como são armazenadas na origem é importante. Help Desk Migration, por exemplo, pode migrar versões de idioma que partilhem o mesmo ID de artigo. Se os IDs não corresponderem, apenas a versão predefinida será importada.
Autores, metadados e campos personalizados
Antes de os recriar, decida quais os metadados e as definições de acesso que ainda utiliza. A sua equipa pode depender do autor, do estado, das etiquetas, dos campos personalizados ou das definições de visibilidade de um artigo para gerir quem pode visualizar ou publicar o conteúdo.
Analise os campos que pretende manter e veja onde essa informação pode ser armazenada no novo sistema. Alguns terão uma correspondência óbvia, enquanto outros podem precisar de um campo personalizado ou de um pouco mais de trabalho para serem mapeados corretamente.
Como planear um projeto de consolidação de bases de conhecimento
Em primeiro lugar, faça uma auditoria a todas as bases de conhecimento existentes
Faça um inventário único de todas as bases de conhecimento que planeia consolidar. Registe o URL, o estado, o idioma, a categoria, a última atualização, o proprietário, os redirecionamentos e os anexos de cada artigo e, em seguida, adicione os dados de tráfego ou de utilização (se disponíveis).
Inclua também as ligações entre cada artigo. Registe as suas traduções, links internos e quaisquer ficheiros ou imagens de que os leitores necessitem para seguir as instruções. Precisará destes detalhes posteriormente, ao verificar como o conteúdo funcionará na nova base de conhecimento.
Escolhendo a plataforma de destino
O seu inventário fornece uma lista de itens a verificar em cada plataforma que está a considerar. Analise o conteúdo e a estrutura que já utiliza: a plataforma é compatível com as suas categorias, traduções, permissões e os campos que pretende manter? Preste especial atenção a tudo o que já sabe que seria difícil de substituir.
Eliminar conteúdo duplicado e padronizar antes de fundir
Ao consolidar artigos da base de conhecimento, precisa de decidir o que fazer com aqueles que se sobrepõem. Uma versão pode já conter todas as informações relevantes, mas não presuma que a mais recente é a mais precisa. Por vezes, o artigo final necessitará de informações de várias versões.
Algumas opções de migração permitem deixar para trás o conteúdo indesejado, em vez de migrar toda a base de conhecimento. Help Desk Migration, por exemplo, suporta a filtragem de artigos por categoria, secção ou intervalo de datas para FreshdeskparaZendesk migrações.
Este é também um bom momento para organizar a terminologia e as categorias, enquanto ainda sabe a origem de cada artigo. Defina os nomes que serão utilizados na base de conhecimento consolidada e aplique-os ao conteúdo que escolheu migrar.
Passo a passo: Migração de conteúdo da base de conhecimento entre plataformas
Antes da migração
Comece por alguns dos artigos que têm maior probabilidade de causar problemas: aqueles com categorias aninhadas, formatação invulgar, imagens incorporadas, anexos ou campos que não têm uma correspondência clara no destino. Em seguida, compare as versões migradas com as originais para ver o que foi transferido corretamente e o que não foi.
Help Desk Migration permite fazê-lo com uma Migração de Demonstração. Pode utilizar uma amostra aleatória ou escolher até 20 artigos, o que é útil se já souber quais serão provavelmente mais difíceis.
Durante a migração
Alguns problemas de migração são esperados:
- Faltam imagens ou anexos
- Alterações ou quebras de formatação
- As categorias ou secções acabam no lugar errado
- Os valores dos campos personalizados estão em falta ou mapeados incorretamente
- Alterações nas permissões ou nas definições de visibilidade
- Os artigos publicados ou editados durante a migração estão ausentes do destino
Os relatórios de migração mostrarão os registos com falha e os registos ignorados, mas terá de verificar o conteúdo migrado para obter o restante.
Outras questões são mais difíceis de prever porque a própria transferência pode parecer bem-sucedida:
- Os campos comportam-se de maneira diferente. O destino aceita o valor, mas interpreta-o de forma diferente.
- Alterações no HTML. As tabelas, âncoras, elementos incorporados ou formatação de código podem ser afetados, mesmo que o artigo pareça correto à primeira vista.
- Os limites da API tornam a migração mais lenta. Um teste pequeno pode permanecer dentro dos limites, enquanto a migração completa é limitada.
- As automatizações reagem aos registos importados. As notificações, workflows, webhooks ou outros processos podem ser executados quando o destino recebe o conteúdo migrado.
- Os resultados da pesquisa alteram-se. O destino pode indexar o mesmo conteúdo de forma diferente, dificultando a localização de alguns artigos.
Pode preparar-se para alguns destes problemas verificando os limites da API de destino e observando o que acontece quando os registos importados acionam as suas automatizações. A formatação e a pesquisa são mais difíceis de prever, por isso teste ambas com o conteúdo migrado antes de fazer a transição completa.
Após a migração
Após a conclusão da migração, compare a origem e o destino para verificar se falta algum registo para além dos já marcados como falhos ou ignorados. Se estiver a utilizar a migração para unificar a documentação de suporte de diversas fontes, também terá de migrar o conteúdo que foi adicionado ou atualizado durante a execução dessas migrações.
Na Help Desk Migration, a funcionalidade de Migração Delta auxilia nas alterações posteriores de registos compatíveis, evitando a necessidade de repetir toda a migração. Verifique a compatibilidade da Migração Delta com a sua origem e destino antes de a utilizar para o conteúdo da base de conhecimento.
Por fim, mantenha a base de conhecimento antiga disponível durante algum tempo após a mudança. Quando um link antigo não funciona ou alguém reporta conteúdo em falta, precisará da fonte para ver o que estava lá e corrigir o problema rapidamente.
A consolidação prejudicará o seu posicionamento nos motores de busca?
É possível que as suas classificações oscilem durante algum tempo se a consolidação gerar novos URLs para os seus artigos. O Google precisa de encontrar e rastrear os novos URLs, e algumas flutuações de classificação são normais enquanto rastreia e reindexa as páginas movidas. No entanto, o que faz com os URLs antigos é mais importante.
Preservação de URLs e redireccionamentos entre fontes fundidas
Quando vários artigos são unificados num só, pode acabar com URLs antigos para o mesmo artigo novo. Digamos que combina três artigos semelhantes de bases de conhecimento diferentes. Cada um dos seus URLs ainda precisa de redirecionar para a versão consolidada, mesmo que alguns venham de outra plataforma ou domínio.
A Google recomenda redireccionamentos permanentes no servidor, como 301 ou 308, e afirma que não causam perda de PageRank. Cada URL antigo deve ir diretamente para o seu novo destino, em vez de passar por um redirecionamento anterior.
Tem mais controlo sobre os links dentro da sua própria base de conhecimento. Direcione-os diretamente para os novos URLs e deixe os redirecionamentos para lidar com backlinks, favoritos e links em sites que não controla. O mesmo acontece com os URLs canónicos, as anotações hreflang e os sitemaps: se contiverem um URL antigo, substitua-o pelo novo.
Assim que a nova base de conhecimento estiver ativa, vale a pena monitorizar o Search Console para identificar URLs antigos que o Google continua a rastrear, novas páginas que ainda não indexou e erros de rastreio ou indexação. O Google afirma que pode demorar algumas semanas para que a maioria das páginas de um site pequeno ou médio sejam atualizadas no seu índice, e mais tempo para sites maiores. Por isso, mantenha os redireccionamentos durante pelo menos um ano para dar ao Google tempo suficiente para voltar a rastrear os URLs e transferir os sinais para os novos.
Riscos da consolidação da base de conhecimento e como evitá-los
Já nos deparámos com perda de dados, links partidos e artigos duplicados ou conflituantes durante o processo de consolidação. Agora, vamos analisar mais detalhadamente o que pode correr mal e o que pode fazer para evitar estes problemas.
Perda e corrupção de dados
Parte da perda de dados decorre das limitações da própria plataforma de destino. Uma plataforma pode restringir o tamanho dos artigos, anexos, profundidade das categorias ou outras partes da base de conhecimento, enquanto alguns campos podem até não estar disponíveis.
Antes de iniciar a migração completa, verifique os limites e as notas de migração específicos para a sua origem e destino. Podem ser surpreendentemente específicos: em alguns pares de plataformas, as datas dos artigos podem mudar para a data da migração, enquanto as etiquetas, anexos ou outros dados podem exigir uma migração personalizada para serem transferidos.
Ligações cruzadas quebradas
As ligações entre artigos podem ser quebradas quando o destino lhes atribui novos IDs. Algumas ferramentas de migração podem atualizar estes links automaticamente. Help Desk Migration, por exemplo, faz isto para ligações internas e referências cruzadas durante as migrações suportadas.
Após a migração, acompanhe a nova base de conhecimento em busca de links quebrados. Verifique separadamente os artigos traduzidos e os links dentro do HTML do artigo, pois estes podem ser mais fáceis de passar despercebidos.
Artigos duplicados ou contraditórios
Podem ainda aparecer duplicados mesmo que tenha limpo o conteúdo antes da migração. Dois artigos que pretendia combinar podem chegar como artigos separados, ou algo que migrar pode sobrepor-se ao conteúdo já existente no destino.
Pesquise na nova base de conhecimento os tópicos que consolidou e compare os resultados. Neste momento, está a verificar se existem duplicados que surgiram durante a migração, uma vez que já lidou com os que encontrou na origem.
Lista de verificação de consolidação
Não precisa de verificar tudo manualmente. Algumas decisões exigem uma pessoa que conheça o conteúdo, enquanto as exportações, os relatórios de migração e os rastreadores podem tratar de grande parte da verificação.
| O que verificar | Como verificar isso | Quem deve lidar com isso? |
|---|---|---|
| Tudo foi migrado? | Compare as contagens de origem e de destino e, em seguida, reveja os registos com falha e os que foram ignorados no relatório de migração. | Proprietário de migração |
| Os artigos chegaram intactos? | Compare uma amostra com os originais, especialmente artigos com imagens, ficheiros, traduções e campos personalizados. | Equipa de conteúdo |
| Ainda existe algum item duplicado? | Pesquise pelos mesmos tópicos e compare resultados semelhantes lado a lado. | Proprietários do conteúdo |
| Os links internos funcionam? | Analise a nova base de conhecimento em busca de erros 404 e de links que ainda utilizem URLs antigos. | SEO / equipa técnica |
| Os URLs antigos levam às páginas corretas? | Analise a sua lista de URLs antigos e verifique o destino final de cada redireccionamento. | SEO / equipa técnica |
| Os dados de SEO sobreviveram? | Rastrear títulos, meta descrições, links canónicos, hreflang e URLs do mapa do site. | Equipa de SEO |
| Houve alguma alteração durante a migração? | Compare as datas de criação e atualização após o prazo limite ou utilize a Migração Delta, se disponível. | Proprietário de migração |
| O Google está a encontrar as novas páginas? | Verifique o Search Console em busca de problemas de indexação e URLs antigos que o Google ainda está a acompanhar. | Equipa de SEO |
| É possível desativar com segurança as antigas bases de conhecimento? | Faça-o apenas depois de as verificações acima estarem concluídas e qualquer conteúdo em falta ou incorreto ser corrigido. | Proprietário de migração |
Conclusão
Uma boa consolidação de bases de conhecimento não tem de terminar com tudo num único sistema. Alguns conteúdos podem permanecer onde estão; o restante necessita de um destino claro e de um plano para o que acontecerá à sua estrutura, ligações e outros dados quando for migrado.
Após tomar estas decisões, Help Desk Migration pode tratar da transferência entre plataformas compatíveis. Pode utilizar uma Migração de Demonstração para ver como o seu conteúdo será apresentado antes de optar pela migração completa.
Perguntas frequentes
Migra o conteúdo da base de conhecimento entre plataformas, ligando ou exportando a origem, mapeando os seus registos e campos para o destino, executando uma migração de teste e, em seguida, transferindo toda a base de conhecimento. Verifique o conteúdo migrado antes de desativar a origem, especialmente artigos com anexos, traduções, campos personalizados ou formatação complexa.
Normalmente, é possível migrar artigos da base de conhecimento, categorias, anexos, imagens incorporadas, traduções, autores e metadados. Os registos e campos exatos que podem ser transferidos dependem do que as plataformas de origem e de destino suportam.
Deve manter as bases de conhecimento separadas quando estas servem públicos diferentes, exigem níveis de acesso distintos ou têm responsáveis claros que as mantêm de forma independente. A consolidação faz mais sentido quando o mesmo conteúdo ou conteúdo sobreposto precisa de ser mantido em vários locais.
A consolidação da base de conhecimento pode provocar alterações temporárias no ranking se os artigos forem movidos para novos URLs, mas a alteração dos URLs não significa automaticamente a perda de posições no ranking. Mapeie os URLs antigos para os seus novos destinos, utilize redireccionamentos permanentes, atualize os links internos e monitorize a indexação após a migração.
Não existe um cronograma fixo para a consolidação da base de conhecimento, uma vez que esta depende da quantidade e complexidade do conteúdo, das plataformas envolvidas e do nível de limpeza ou desduplicação necessário. Uma migração de teste pode ajudar a identificar problemas, mas o projeto completo também requer tempo para revisão de conteúdo, mapeamento de URLs, testes e verificações pós-migração.
Escolha um destino que suporte o conteúdo, a estrutura, as permissões, os idiomas, os metadados e os fluxos de trabalho que precisa de manter. Teste artigos representativos antes de optar pela plataforma para verificar como a sua base de conhecimento existente será transferida.
