Objetivo: Este manual define o padrão obrigatório de escrita para a criação de artigos de Base de Conhecimento (KCS) voltados ao time de Suporte e Implantação. Toda nova funcionalidade, módulo ou correção de sistema deve ser documentada estruturando rigorosamente os 5 tópicos abaixo.

📑 Detalhamento dos 5 Tópicos Obrigatórios

1. Descrição do Recurso e Conceito Operacional

Neste item, o analista deve explicar o porquê a funcionalidade existe e qual o comportamento macro dela no negócio do cliente.

• O que escrever: O conceito técnico do recurso, o modelo de operação de mercado em que ele se aplica (varejo, indústria, franquias, etc.) e as regras gerais que o software segue.
• O que evitar: Textos comerciais, adjetivos (“sistema moderno”, “ferramenta incrível”) ou focar em preço/vendas. O foco aqui é a regra de negócio pura.

2. Fluxo Lógico do Sistema (Back-end & Aplicação Local)

Aqui deve ser descrito o caminho que a informação faz por dentro do ecossistema de software. O suporte precisa saber onde o dado nasce e para onde ele vai.

• O que escrever: Dependências de tabelas, se o recurso exige sincronização (carga de tabelas), como a informação trafega entre o ERP em nuvem e o PDV local/offline, rotinas de banco de dados afetadas e APIs envolvidas.
• O que evitar: Instruções de clique (isso vai no item 3). Este tópico é conceitual-estrutural.

3. Guia de Configuração e Ativação

O passo a passo prático, “clique a clique”, para colocar a funcionalidade para rodar do zero.

• O que escrever: Nome exato das telas, localização de parâmetros no menu, o nome das flags (caixas de seleção) que precisam ser marcadas, se exige reinicialização do sistema ou carga de dados, e configurações físicas de hardware (drivers, balanças, impressoras, TEF), se houver.
• O que evitar: Passos genéricos como “configure o sistema”. Seja cirúrgico: “Acesse Menu X > Submenu Y > Ative a flag Z”.

4. Resultado Esperado (Critérios de Sucesso na Implantação)

Os critérios físicos, visuais e de sistema que provam que a configuração deu certo. É o roteiro de testes finais do analista de suporte antes de encerrar o chamado.

• O que escrever: O que deve aparecer na tela após a ação, o tempo aceitável de resposta do sistema, o comportamento físico do hardware (ex: acionamento da guilhotina, abertura de gaveta) e a validação visual do documento gerado (formatos, dados obrigatórios no cupom/relatório).
• O que evitar: Termos subjetivos como “veja se funcionou”. Defina o comportamento exato esperado da aplicação.

5. Resolução de Problemas (Troubleshooting)

A engenharia reversa do erro. Mapeamento dos problemas que o cliente final vai pegar no dia a dia e como o suporte resolve rápido no primeiro nível.

• O que escrever: Uma matriz contendo obrigatoriamente três pilares para cada erro:
  1. Sintoma: O que o cliente/operador vê na tela ou o comportamento anômalo do sistema.
  2. Causa Provável: O motivo técnico real do erro (parâmetro incorreto, falta de carga, driver de terceiro desatualizado, queda de conexão).
  3. Solução Técnica Direta: O comando, ajuste ou correção exata que o analista de suporte deve executar para sanar o problema imediatamente.
• O que evitar: Respostas genéricas como “entre em contato com o desenvolvimento”. O troubleshooting deve dar autonomia total para o suporte de nível 1 e 2 resolverem o problema.