Essa pergunta chega na minha caixa de entrada com alguma frequência, quase sempre vinda de alguém que já está atendendo cliente por e-mail e WhatsApp e cansou de explicar a mesma coisa quatro vezes por dia. A pessoa quer um lugar com a cara da empresa onde o cliente encontre a resposta sozinho, abra um chamado quando não encontrar e acompanhe o que aconteceu depois. E quer que isso pareça parte do site, e não uma página genérica de fornecedor.
A boa notícia é que esse produto já existe, e você provavelmente já paga por ele sem saber. Todo helpdesk que se leva a sério entrega um portal junto com a caixa de tickets. O que muda entre um e outro é até onde vai a personalização e em qual plano ela destrava. Existem três caminhos pra chegar lá, e o texto abaixo é o que eu falo pra quem me pergunta.
Caminho 1: o portal que vem com o helpdesk
Freshdesk, Freshservice e Zendesk trazem um portal pronto no dia em que você cria a conta. Ele nasce num subdomínio do fornecedor, com um tema padrão e a base de conhecimento vazia. O trabalho é deixar ele com a sua cara, e a lista do que dá pra mexer é maior do que a maioria imagina:
- Domínio próprio. O portal responde em
ajuda.suaempresa.com.br, com certificado, em vez do endereço do fornecedor. - Marca. Logo, favicon, cores primárias e fonte, escolhidos num painel, sem código.
- Tema em HTML e CSS. Quando o painel não basta, o tema é editável. Cabeçalho, rodapé, página inicial, página de artigo: cada uma tem o seu template e aceita o CSS que você quiser.
- Estrutura de artigos. Categorias, pastas e artigos com controle de quem vê o quê. Um artigo pode ser público, só pra clientes logados ou só pra um grupo específico.
- Formulários condicionais. O formulário de abertura de chamado muda conforme o que o cliente escolhe. Selecionou "problema com pedido", aparece o campo de número do pedido. Selecionou "dúvida", não aparece.
- Área logada. O cliente cria uma conta ou entra por SSO, vê os chamados dele, responde por ali e acompanha o status sem mandar e-mail perguntando.
- Vários portais. Um por marca, um por país ou um por produto, cada um com o seu domínio e o seu visual, todos caindo na mesma operação.
A pegadinha é que a personalização mais profunda fica nos planos de cima. No Freshdesk, por exemplo, o plano Growth já traz base de conhecimento e portal, mas o domínio próprio e os portais múltiplos aparecem a partir do Pro. Antes de assinar, vale conferir em qual plano fica cada item da lista acima, porque o preço de "só quero o meu domínio no portal" pode ser a diferença entre dois planos.
Pra quem serve: a grande maioria. Se a sua operação atende por ticket e quer um portal profissional em semanas, é aqui que você começa.
Caminho 2: o portal no seu site, com o helpdesk por trás
A segunda opção é manter o portal no seu próprio site ou CMS e embutir os pedaços do helpdesk nele. Você cria a página "Central de ajuda" no WordPress, no Webflow ou no que for, e coloca dentro dela o widget de suporte e a base de conhecimento do helpdesk. O widget abre o formulário e o chat, a base de conhecimento pode ser embutida ou consultada pela API, e o ticket cai na mesma fila de sempre.
A vantagem é a liberdade visual total: é o seu site, com o seu design system, o seu menu e o seu SEO. O portal deixa de parecer uma ilha.
A pegadinha é que agora são dois sistemas pra manter alinhados. O artigo que você atualiza no helpdesk precisa aparecer atualizado no site. A categoria que muda de nome precisa mudar nos dois lugares. E a área logada, onde o cliente acompanha os chamados, continua vivendo no portal do helpdesk, porque reconstruir isso no CMS já é o caminho 3.
Pra quem serve: empresas com um site forte, um time de marketing que cuida dele e uma base de conhecimento que não muda toda semana.
Caminho 3: o portal construído na API
O terceiro caminho é escrever o portal do zero, usando a API do helpdesk como back-end. O Freshdesk, o Freshservice e o Zendesk expõem por API tudo o que o portal deles faz: criar ticket, listar os tickets de um contato, responder, buscar artigo, anexar arquivo. Você monta a interface que quiser e conversa com o helpdesk por trás.
Quando vale a pena? Em dois cenários que eu vejo com frequência. O primeiro é quando o suporte precisa morar dentro do seu aplicativo: o cliente já está logado no seu produto e abrir uma aba nova pra pedir ajuda quebra a experiência. O segundo é quando a área logada precisa mostrar dados que não estão no helpdesk. Status do pedido no ERP, fatura em aberto no financeiro, contrato vigente: nada disso o portal pronto sabe, e o seu portal pode juntar tudo numa tela só.
A pegadinha é o custo, e não só o de construir. Um portal próprio é um produto de software, e produto de software pede manutenção pra sempre. A API muda de versão, o navegador muda, a lei de privacidade muda, alguém do time sai e leva o conhecimento junto. Se você não tem um time de desenvolvimento que vai cuidar disso daqui a três anos, esse caminho vira uma dívida.
Pra quem serve: empresas de software com produto próprio, ou operações onde o cliente precisa ver dados de vários sistemas no mesmo lugar.
Os três caminhos lado a lado
| Portal do helpdesk | No seu site + helpdesk | Construído na API | |
|---|---|---|---|
| Tempo pra ir ao ar | Dias a poucas semanas | Semanas | Meses |
| Custo | A licença do plano | Licença + horas de web | Licença + desenvolvimento + manutenção |
| Liberdade de marca | Alta, dentro do tema | Total nas páginas públicas | Total |
| Área logada | Pronta, com SSO | Continua no portal do helpdesk | Do jeito que você desenhar |
| Manutenção | Do fornecedor | Dois sistemas pra alinhar | Sua, pra sempre |
| Pra quem serve | A maioria das operações | Quem tem site forte e time de marketing | Quem tem produto próprio e time de dev |
O que avaliar antes de assinar
Seja qual for o caminho, o portal só funciona quando as cinco camadas dele funcionam juntas: base de conhecimento, chatbot, formulário, área logada e acompanhamento de ticket. Eu detalhei cada uma, e o checklist de QA pra testar antes de publicar, em outro artigo aqui no blog. Se você vai comparar fornecedores, leve essa lista pra demonstração e peça pra ver cada camada funcionando, e não só o tema bonito.
Aqui na Red Lotus, que é parceira autorizada Freshworks em São Paulo, o pedido mais comum é o caminho 1 com uma pitada do 2: portal do Freshdesk no domínio da empresa, tema ajustado pra bater com o site, e o widget embutido nas páginas onde o cliente costuma travar. Se o seu caso é esse, ou se você está em dúvida sobre qual plano cobre o que você precisa, um parceiro de implementação Freshworks resolve isso em uma conversa. É o que a gente faz.
Perguntas frequentes
Dá pra usar o meu domínio no portal do Freshdesk?
Sim. O portal responde em um subdomínio seu, como ajuda.suaempresa.com.br, com certificado SSL. No Freshdesk, o domínio próprio está disponível a partir do plano Pro; no Growth o portal fica no endereço do fornecedor.
O portal pode ser em português e em inglês?
Pode. Os portais dos principais helpdesks são multilíngues: você escolhe os idiomas suportados, traduz os artigos e os textos da interface, e o cliente vê a versão dele. A tradução dos artigos é trabalho seu, mas a estrutura e a troca de idioma já vêm prontas.
Preciso de desenvolvedor pra personalizar o portal?
Pra logo, cores, domínio, formulários e estrutura de artigos, não. Tudo isso é painel. Pra mexer no tema em HTML e CSS ou pra embutir o widget no seu site, ajuda ter alguém que entenda de front-end, mesmo que por poucas horas. Só o caminho 3, o portal construído na API, exige um time de desenvolvimento de verdade.
Quanto tempo leva pra colocar um portal no ar?
Com o portal do helpdesk, a configuração visual e o domínio saem em dias. O que define o prazo é o conteúdo: escrever os primeiros artigos e desenhar os formulários costuma tomar de duas a quatro semanas em uma operação de porte médio. Portal embutido no site leva mais algumas semanas de trabalho de web. Portal na API é projeto de meses.
Leandro é fundador da Red Lotus Tecnologia, especializada em implantação, suporte e evolução do Freshdesk para times de atendimento no Brasil.