O Milldesk é frequentemente associado ao suporte de TI, e faz sentido: nasceu como ferramenta de help desk e service desk. Mas a estrutura de chamados, SLA e workflow que organiza uma equipe de TI é a mesma que resolve o principal problema de uma operação de facilities: demandas chegando por canais diferentes, sem registro formal, sem prazo definido e sem visibilidade de quem está fazendo o quê.

Empresas como a Jungheinrich já usam o Milldesk para facilities e pós-vendas no mesmo ambiente em que a TI opera, sem precisar de sistemas diferentes para cada área.

O que é facilities e por que a gestão de chamados importa nesse contexto

Bem, facilities é a área responsável por manter a infraestrutura física e os serviços de suporte que sustentam a operação de uma empresa. O escopo varia conforme o porte da organização, mas costuma cobrir:

• Manutenção predial: sistemas elétricos, hidráulica, climatização, elevadores, estrutura civil e instalações físicas em geral.
• Serviços de apoio: limpeza, recepção, copa, jardinagem e conservação de áreas comuns.
• Segurança patrimonial: controle de acesso, CFTV, portaria e vigilância.
• Gestão de contratos com terceiros: prestadores de serviço com SLA contratual que precisam ser monitorados quanto a prazo e qualidade de execução.
• Infraestrutura de trabalho: suprimentos, manutenção de equipamentos de escritório e gestão de ativos físicos.

O desafio operacional de facilities é muito semelhante ao de TI: volume alto de demandas vindas de diferentes solicitantes, serviços com urgências muito distintas entre si e prestadores externos que precisam ser coordenados com prazo e qualidade monitorados.

Sem um sistema de chamados, essas demandas chegam por WhatsApp, e-mail e ligação, ficam registradas na memória de quem recebeu e somem quando essa pessoa está ausente.

Como o Milldesk se aplica à operação de facilities na prática

O sistema de chamados do Milldesk não é exclusivo para TI. A estrutura de categorias, formulários, SLA e workflow pode ser configurada para qualquer tipo de demanda de serviço interno, incluindo as que chegam à equipe de facilities.

Na prática, uma solicitação de manutenção de ar-condicionado, uma ocorrência de infiltração, um pedido de revisão de contrato com terceirizado ou uma solicitação de acesso de visitante podem ser abertas pelo próprio solicitante no portal, receber categoria e prioridade automáticas e seguir um fluxo de aprovação e atribuição configurado pelo gestor, sem que o analista de facilities precise receber a demanda por mensagem e registrá-la manualmente depois.

Cada chamado gera um registro com histórico completo, o que resolve um problema frequente em facilities: a rastreabilidade de intervenções em equipamentos e ativos.

Quando o mesmo ar-condicionado apresenta o mesmo problema pela terceira vez, o histórico de chamados mostra o padrão antes que alguém precise lembrar ou procurar anotação antiga.

Como o SLA funciona para serviços de facilities

O controle de SLA no Milldesk funciona para chamados de facilities da mesma forma que para chamados de TI: o prazo começa a contar no registro, o alerta dispara antes do vencimento e o escalonamento automático aciona o nível seguinte quando o prazo não é cumprido.

Isso resolve um problema concreto com prestadores externos: o prazo contratual para atendimento frequentemente não é acompanhado de nenhum mecanismo ativo de controle.

O contrato diz que o prestador deve comparecer em até 24 horas para chamados urgentes, mas ninguém recebe alerta quando esse prazo está vencendo.

Em detalhes, o Milldesk faz esse acompanhamento automaticamente, com alertas configuráveis por nível de urgência e escalonamento automático quando o prestador não responde dentro do prazo acordado.

A gestão de nível de serviço em facilities funciona melhor quando os prazos por tipo de chamado estão calibrados com base no histórico real de atendimento, separando urgências diferentes com SLAs diferentes:

• Chamados críticos de facilities, como queda de energia, vazamento ativo ou falha no sistema de climatização em área crítica, com prazo de resposta em horas.
• Chamados de manutenção corretiva não crítica, como equipamento com desempenho degradado ou instalação com defeito sem risco imediato, com prazos em dias.
• Solicitações de rotina e agendamento preventivo, com datas programadas e execução dentro de janelas planejadas pela equipe.

Facilities e TI no mesmo ambiente: o modelo CSC

Empresas que adotam o conceito de Centro de Serviços Compartilhados (CSC) centralizam o atendimento de múltiplas áreas em uma única plataforma de chamados, com filas, categorias e SLAs distintos para cada departamento. O usuário abre o chamado no mesmo portal, independentemente de o pedido ser para TI, facilities, RH ou financeiro.

O Milldesk suporta esse modelo com workflow visual configurável por área, permitindo que cada departamento tenha seu próprio fluxo sem interferir no dos outros. Os benefícios práticos do modelo CSC com o Milldesk incluem:

• Uma única interface para o solicitante, independentemente da área que vai atender, reduzindo a dúvida de “para quem eu peço isso”.
• Relatórios consolidados por área, com o gestor de facilities acompanhando apenas os chamados da sua fila e a liderança tendo visibilidade de toda a operação de serviços internos.
• Configurações independentes por departamento, onde facilities, TI e RH têm categorias, formulários, SLAs e responsáveis distintos dentro da mesma plataforma.
• Redução de sistemas paralelos, eliminando a necessidade de ferramentas diferentes para cada área que precisa organizar demandas de serviço interno.

Como começar a usar o Milldesk em facilities sem reformular a operação inteira

A transição não exige começar do zero. O caminho mais comum em operações que já usam o Milldesk para TI é estender a ferramenta para facilities de forma incremental:

• Mapeie as categorias de demanda mais frequentes da área com base nas solicitações que chegam informalmente hoje, por WhatsApp, e-mail ou ligação direta.
• Configure formulários específicos para cada categoria identificada, com os campos que o técnico ou prestador precisa para executar sem pedir complementação depois.
• Defina SLAs por tipo de chamado usando o histórico real de tempo de atendimento para não negociar prazo acima ou abaixo do que a operação consegue cumprir.
• Ative o portal de abertura para os solicitantes da área, reduzindo a entrada de demandas por canais informais e centralizando tudo no sistema desde o início.
• Configure alertas de vencimento para chamados com prestadores externos, garantindo que o SLA contratual seja monitorado ativamente, não apenas verificado quando alguém lembra.

O Milldesk cobra em reais e oferece suporte em português, o que facilita a adoção tanto por equipes de TI quanto por analistas de facilities sem histórico em ferramentas de help desk.

Teste gratuitamente por 7 dias e veja como a mesma estrutura que organiza o suporte de TI funciona para a operação de facilities da sua empresa.

Perguntas frequentes

1. O Milldesk funciona para facilities ou só para TI?
   O Milldesk funciona para qualquer área que precise organizar demandas de serviço interno. Empresas como a Jungheinrich já usam a ferramenta para TI, facilities e pós-vendas no mesmo ambiente.
2. Como o Milldesk ajuda na gestão de prestadores externos de facilities?
   Registrando chamados com prazo contratual no sistema, ativando alertas antes do vencimento e escalando automaticamente quando o prestador não responde dentro do prazo acordado.
3. O que é o modelo CSC e como o Milldesk suporta essa estrutura?
   CSC é o Centro de Serviços Compartilhados, onde TI, facilities, RH e outras áreas atendem pelo mesmo portal. O Milldesk permite filas, categorias e SLAs distintos por departamento dentro da mesma plataforma.
4. Como facilities se beneficia do histórico de chamados no Milldesk?
   O histórico vinculado ao ativo ou local revela padrões de recorrência em equipamentos ou instalações antes que o problema se torne crônico, sem depender da memória de quem atendeu antes.
5. Como começar a usar o Milldesk para facilities sem reformular tudo?
   Mapeando as categorias de demanda mais frequentes que chegam hoje por canais informais, configurando formulários específicos para cada uma e ativando o portal de abertura para os solicitantes da área.

Em muitas operações de TI, o volume de chamados que chega todo dia não é composto principalmente de falhas. A maior parte são pedidos previsíveis: acesso a sistema, instalação de software, criação de usuário, redefinição de senha.

A gestão de solicitações de serviço é a prática do ITIL 4 que cuida exatamente dessa demanda recorrente, separando-a do fluxo de urgência reservado para incidentes e tratando-a com o processo que ela merece: padronizado, rastreável e com prazo visível para quem pediu.

O que é uma solicitação de serviço segundo o ITIL 4

Uma solicitação de serviço é um pedido formal de algo que o usuário precisa e que não representa uma falha em andamento. Pedir acesso a um sistema, solicitar instalação de software, requisitar um novo equipamento ou pedir a redefinição de uma senha são exemplos clássicos.

O incidente corrige algo que parou de funcionar. A solicitação de serviço entrega algo que o usuário está pedindo de forma planejada, sem nenhuma falha por trás do pedido.

Misturar os dois tipos de chamado na mesma fila com o mesmo critério de prioridade cria dois problemas ao mesmo tempo: solicitações simples esperam mais do que precisam, e o acúmulo de pedidos de rotina consome capacidade que deveria estar disponível para incidentes críticos.

O sistema de chamados que separa solicitações de incidentes desde a abertura resolve esse conflito antes que ele precise ser gerenciado manualmente a cada chamado que entra.

Por que solicitações de rotina precisam de um fluxo próprio

Quando solicitações e incidentes compartilham a mesma fila sem distinção, a triagem manual vira trabalho permanente. Alguém precisa olhar para cada chamado, decidir o que é urgente de verdade e redistribuir a fila, o tempo todo, sem critério formal para apoiar essa decisão.

Um fluxo próprio para solicitações resolve isso configurando o caminho que cada tipo de pedido vai percorrer antes do primeiro chamado chegar. Os benefícios diretos de ter esse fluxo separado incluem:

• Triagem automática por tipo de pedido, com o chamado já chegando categorizado, com responsável atribuído e prazo ativo desde a abertura, sem etapa manual entre a solicitação e o início do atendimento.
• SLA calibrado para a complexidade real de cada pedido, e não para a urgência média da fila geral, o que evita que solicitações simples pareçam atrasadas por um prazo pensado para incidentes.
• Aprovações estruturadas dentro do sistema, eliminando e-mails paralelos que saem do fluxo rastreável e ficam aguardando retorno em caixas de entrada que ninguém monitora formalmente.
• Histórico vinculado ao solicitante e ao tipo de pedido, permitindo identificar padrões de demanda por área ou por tipo de acesso que orientam decisões de automação ou de dimensionamento da equipe.

A gestão do catálogo de serviços sustenta essa separação: cada tipo de solicitação tem formulário específico, prazo definido e responsável atribuído no momento da abertura.

Como o volume de solicitações revela o que precisa de automação primeiro

O histórico de chamados abertos antes de qualquer estruturação formal é a fonte mais confiável para priorizar o que automatizar primeiro. Uma análise simples por categoria já revela padrões que a percepção do dia a dia esconde:

• Solicitações de altíssima frequência e baixa complexidade são os primeiros candidatos à automação, como redefinição de senha ou liberação de acesso padrão, onde um formulário estruturado e aprovação automática reduzem o tempo de atendimento de horas para minutos.
• Solicitações de frequência média com etapa de aprovação são o segundo grupo prioritário, como instalação de software pago ou acesso a sistemas sensíveis, onde o fluxo de aprovação formaliza quem precisa autorizar antes da execução.
• Solicitações raras mas de alto custo quando mal executadas fecham a lista, como provisionamento de novo equipamento, onde o formulário estruturado evita que informações críticas fiquem de fora do pedido inicial e causem retrabalho na entrega.

Os relatórios segmentados por categoria do Milldesk tornam esse padrão visível sem depender de levantamento manual.

Como automatizar solicitações recorrentes sem perder rastreabilidade

O padrão de repetição de muitas solicitações é o que torna a automação especialmente eficaz. Os elementos centrais dessa automação são:

• Formulários pré-configurados por tipo de solicitação, coletando exatamente os dados necessários sem exigir descrição livre, o que reduz chamados incompletos que precisam de complementação antes de seguir.
• Aprovações automáticas ou direcionadas para o responsável correto conforme o tipo de solicitação e o nível de acesso envolvido, eliminando e-mails paralelos fora do sistema.
• Execução padronizada das etapas técnicas com o workflow visual definindo o caminho exato que cada pedido percorre do registro até o encerramento, sem variação entre técnicos diferentes executando a mesma solicitação.

Como definir prazos para solicitações sem subestimar a complexidade

O prazo de uma solicitação varia muito conforme o pedido. Uma redefinição de senha leva minutos; a criação de um ambiente de acesso completo pode levar dias, dependendo das aprovações envolvidas. Definir esse prazo exige olhar para o tempo real gasto em cada tipo de solicitação no histórico, não para uma estimativa genérica.

A gestão de nível de serviço trata esse ponto: o prazo precisa refletir o que a operação efetivamente faz, negociado com quem depende daquele serviço.

Quando o prazo é coerente com o histórico, o solicitante sabe o que esperar e a equipe não opera sob pressão artificial de um número que nunca foi realista para a complexidade real do pedido.

O que monitorar para saber se a prática está funcionando

Acompanhar a eficiência da gestão de solicitações exige indicadores separados dos que se usam para incidentes:

• Tempo médio de atendimento por tipo de solicitação, identificando quais pedidos consistentemente ultrapassam o prazo e merecem revisão de processo ou de SLA.
• Volume de solicitações por categoria ao longo do tempo, revelando tendências que orientam decisões de dimensionamento da equipe ou de expansão do catálogo.
• Taxa de solicitações que precisaram de complementação após a abertura, sinalizando que o formulário daquele tipo de pedido não está coletando as informações certas desde o início.
• Percentual de aprovações que ocorreram fora do sistema, indicando que algum fluxo ainda depende de e-mail ou mensagem direta fora da rastreabilidade do sistema de help desk.
• Taxa de reabertura por tipo de solicitação, revelando pedidos que foram encerrados sem estar realmente concluídos e que voltam como chamado novo dias depois.

Teste o Milldesk gratuitamente por 7 dias e organize as solicitações de serviço da sua operação com fluxo próprio, prazo visível e rastreabilidade completa.

Perguntas frequentes

1. O que é uma solicitação de serviço no ITIL 4?
   É um pedido formal de algo que o usuário precisa, mas que não representa uma falha em andamento, como acesso a um sistema, instalação de software ou redefinição de senha.
2. Por que solicitações de serviço não devem ter o mesmo prazo de incidentes?
   Porque não representam urgência operacional real. Misturar os dois tipos de chamado na mesma fila atrasa solicitações simples e pode consumir capacidade reservada para incidentes críticos.
3. Como identificar quais solicitações automatizar primeiro?
   Pelo volume real de chamados por categoria no histórico. As de altíssima frequência e baixa complexidade têm o maior potencial de ganho imediato com automação.
4. Como definir o prazo de uma solicitação de serviço?
   A partir do tempo médio real gasto naquele tipo específico de pedido no histórico, não por estimativa genérica aplicada a todas as solicitações igualmente.
5. O que indica que o fluxo de aprovação ainda não está estruturado?
   Um percentual alto de aprovações acontecendo fora do sistema, por e-mail ou mensagem direta, sem registro no histórico do chamado.

A maioria das operações de TI que tenta montar um catálogo de serviços comete o mesmo erro de origem: trata o catálogo como uma lista única, voltada ao mesmo tempo para o usuário que vai abrir o chamado e para o técnico que vai executá-lo.

O resultado é um documento que não serve bem a nenhum dos dois públicos. A gestão do catálogo de serviços no ITIL 4 resolve esse problema separando duas camadas com propósitos diferentes, e entender essa separação é o que faz a prática funcionar de verdade.

As duas camadas do catálogo que a maioria ignora

O ITIL 4 distingue o catálogo de serviços completo do catálogo de requisição de serviços, e a confusão entre os dois é a raiz da maioria dos catálogos que ninguém usa.

O catálogo de serviços completo é o documento técnico, voltado para dentro da operação de TI. Ele lista cada serviço com profundidade: SLA (Acordo de Nível de Serviço) associado, dependências técnicas, custo de manutenção, responsável interno e nível de criticidade para o negócio.

Esse documento serve para o gestor de TI decidir onde investir, para o financeiro entender o custo de cada serviço e para a área de infraestrutura mapear dependências antes de qualquer mudança.

O catálogo de requisição de serviços é a vitrine que o usuário final vê. É deliberadamente mais simples: mostra apenas o que pode ser pedido naquele momento, em linguagem de negócio, sem os detalhes técnicos que não interessam a quem só quer resolver um problema.

Um usuário não precisa saber qual servidor hospeda o sistema de e-mail para solicitar uma nova caixa de correio.

Quando uma operação tenta usar o catálogo técnico completo como interface de abertura de chamado, o resultado é um portal confuso, cheio de termos que o usuário não entende, e que acaba sendo ignorado em favor do velho hábito de mandar e-mail ou ligar direto para o técnico conhecido.

Por que tentar documentar tudo de uma vez trava o catálogo

Um padrão recorrente em projetos de catálogo de serviços é a tentativa de mapear cada serviço possível antes de publicar qualquer coisa, buscando um catálogo “completo” desde o primeiro dia.

Esse objetivo nunca é alcançado, porque a operação de TI muda mais rápido do que qualquer documentação consegue acompanhar.

O catálogo não é um projeto com data de entrega, é um processo contínuo. A primeira versão pode e deve ser incompleta, cobrindo apenas os serviços de maior volume identificados no histórico de chamados.

Publicar uma versão simples e usá-la gera mais valor do que esperar uma versão perfeita que nunca sai do papel.

O sistema de chamados que permite adicionar itens ao catálogo de requisição de forma incremental, sem precisar reconfigurar tudo a cada inclusão, é o que viabiliza essa abordagem gradual na prática.

O que entra primeiro no catálogo de requisição de serviços

Definir a ordem de prioridade na construção do catálogo evita o efeito de tentar abraçar tudo e não publicar nada. A lógica mais eficiente segue o volume real de chamados, não a percepção de importância.

• Solicitações de altíssima frequência e baixa complexidade, como redefinição de senha ou liberação de acesso padrão, que se beneficiam imediatamente de um formulário estruturado e de aprovação automatizada.
• Solicitações de frequência média que exigem aprovação de terceiro, como instalação de software pago ou acesso a sistemas sensíveis, onde o catálogo formaliza quem precisa aprovar antes da execução.
• Solicitações raras mas de alto custo quando mal executadas, como provisionamento de novo equipamento, onde o formulário estruturado evita que informações críticas fiquem de fora do pedido inicial.

Os relatórios por categoria de chamados já abertos antes de qualquer catálogo formal são a fonte de dados mais confiável para essa priorização, porque mostram o que a operação já faz, não o que alguém imagina que deveria fazer.

Como o catálogo de requisição se conecta ao SLA sem expor complexidade técnica

Cada item do catálogo de requisição precisa de um prazo visível para o solicitante, mas esse prazo carrega, por trás, toda a complexidade calculada na gestão de nível de serviço. O usuário não precisa ver a fórmula, só o resultado: “este pedido costuma ser atendido em até quatro horas”.

Essa tradução é o que separa um catálogo bem construído de uma lista técnica disfarçada de portal de autoatendimento. Se o prazo exibido depende de variáveis que o usuário não controla nem entende, como disponibilidade de licença ou aprovação de outro departamento, o catálogo precisa deixar isso explícito de forma simples, não esconder a informação até o pedido travar na fila.

Como o catálogo técnico orienta decisões que o usuário nunca vê

Enquanto o catálogo de requisição cuida da experiência de quem abre o chamado, o catálogo técnico completo serve a um propósito diferente: dar ao gestor de TI visibilidade sobre onde a operação está investindo esforço e onde está exposta a risco.

Cruzar o catálogo técnico com o volume de incidentes por serviço, por exemplo, revela quais sistemas concentram mais instabilidade em relação à sua importância para o negócio.

Um serviço de baixa criticidade que consome volume alto de chamados pode ser candidato a descontinuação. Um serviço crítico com poucos incidentes registrados pode estar sob monitoramento insuficiente, não necessariamente estável.

Essa análise depende de dados que só existem quando os chamados estão vinculados de forma estruturada a cada serviço do catálogo, e não dispersos em categorias genéricas que não correspondem a nenhum item formal.

Como manter as duas camadas do catálogo sincronizadas

O maior risco de manter dois catálogos separados é deixá-los dessincronizados: o catálogo técnico evolui com mudanças na infraestrutura, mas o catálogo de requisição que o usuário vê continua desatualizado, ou vice-versa.

A sincronização funciona melhor quando existe um responsável único pela governança do catálogo, mesmo que a manutenção do conteúdo seja distribuída entre diferentes áreas técnicas.

Esse responsável garante que toda mudança no catálogo técnico, como a descontinuação de um serviço ou alteração de SLA, seja refletida no catálogo de requisição antes que o usuário tente solicitar algo que já não existe mais daquela forma.

Checklist para implantar a gestão do catálogo de serviços no Milldesk

Antes de publicar a primeira versão do catálogo de requisição, vale validar estes pontos com a equipe:

• Os 10 a 15 tipos de chamado mais frequentes do histórico já têm um item correspondente mapeado, com campos específicos definidos para cada um.
• Cada item tem um prazo visível vinculado ao SLA real daquele tipo de serviço, calculado a partir de dados de atendimento, não de estimativa.
• As aprovações necessárias estão identificadas e configuradas no workflow visual, sem depender de e-mail paralelo fora do sistema.
• Existe um responsável definido pela atualização do catálogo, com rotina clara de revisão quando um serviço muda ou é descontinuado.
• O catálogo técnico completo está separado do catálogo de requisição, evitando que detalhes irrelevantes para o usuário final apareçam no portal de abertura.

O Milldesk permite configurar formulários específicos por tipo de solicitação, com SLA vinculado e fluxo de aprovação definido, sustentando tanto a vitrine simplificada que o usuário acessa quanto os dados estruturados que o gestor de TI precisa para decisão.

Teste o Milldesk gratuitamente por 7 dias e comece o catálogo de serviços pelos itens de maior volume da sua operação.

Perguntas frequentes

1. Catálogo de serviços e catálogo de requisição de serviços são a mesma coisa?
   Não. O catálogo de serviços completo é técnico e detalhado, voltado para a gestão interna de TI. O catálogo de requisição é a versão simplificada que o usuário final vê no portal de abertura de chamados.
2. Por que tentar mapear todos os serviços de uma vez trava o projeto?
   Porque a operação de TI muda constantemente e nenhuma documentação alcança esse ritmo. Publicar uma primeira versão incompleta, cobrindo os serviços de maior volume, gera valor imediato em vez de esperar uma versão que nunca fica pronta.
3. Por que o prazo do catálogo de requisição não deveria expor a complexidade técnica?
   Porque o usuário final não precisa entender as variáveis internas que definem o SLA, apenas o resultado prático: quanto tempo aquele pedido específico costuma levar.
4. Como decidir qual serviço entra primeiro no catálogo de requisição?
   Pelo volume real de chamados já registrados no histórico, priorizando solicitações de alta frequência e baixa complexidade antes de itens raros, mas de execução mais delicada.
5. Quem deve ser responsável pela manutenção do catálogo?
   Idealmente uma pessoa ou função única com governança sobre o catálogo, garantindo que mudanças no catálogo técnico sejam refletidas no catálogo de requisição antes que o usuário tente solicitar algo desatualizado.

Um incidente é qualquer interrupção não planejada de um serviço ou redução na qualidade de um serviço que já estava funcionando. A gestão de incidentes é a prática do ITIL 4 responsável por restaurar essa operação o mais rápido possível, minimizando o impacto para o usuário e para o negócio.

O critério de sucesso aqui não é eliminar a causa do problema, mas resolver o sintoma com velocidade, sem depender de quem está de plantão no momento.

O que caracteriza um incidente na gestão de chamados de TI

Um incidente acontece quando um serviço que funcionava normalmente para de funcionar ou passa a operar com qualidade reduzida. Um servidor que cai, um sistema lento, uma impressora que não responde: todos esses casos são incidentes, porque interrompem algo que já estava ativo.

Isso é diferente de uma solicitação de serviço, que é um pedido de algo novo, como acesso a um sistema ou instalação de software. Confundir incidente com solicitação é um dos erros mais comuns em operações que não seguem critério formal, porque os dois tipos de chamado exigem tratamento, prazo e prioridade diferentes.

O sistema de chamados que separa esses dois fluxos desde a abertura evita que solicitações simples concorram pelo mesmo prazo de atendimento que incidentes críticos, o que distorce a fila e prejudica quem realmente precisa de resposta rápida.

As etapas do processo de gestão de incidentes segundo o ITIL 4

O ITIL 4 estrutura a gestão de incidentes em etapas sequenciais, desde a identificação até o encerramento formal. Seguir essa sequência é o que garante que nenhum incidente seja esquecido no meio do caminho.

• Identificação e registro: o incidente pode ser identificado por monitoramento automático, contato direto do usuário ou alerta de outra ferramenta. Um incidente que não é registrado não existe para o processo, e por isso não pode ser priorizado nem escalado.
• Categorização e priorização: o chamado é classificado por tipo e recebe prioridade com base em impacto e urgência, não em percepção individual de quem abriu o ticket.
• Diagnóstico e escalonamento: o primeiro nível de atendimento tenta resolver o incidente. Quando não consegue, o chamado escala para o nível seguinte sem depender de decisão manual.
• Resolução e encerramento: o serviço é restaurado e o chamado é formalmente encerrado, com o registro completo do que foi feito disponível para consulta futura.

A priorização automática aplicada nesse fluxo segue a matriz de impacto e urgência: alto impacto combinado com alta urgência gera prioridade crítica, enquanto baixo impacto e baixa urgência ficam no final da fila, independentemente da ordem de chegada.

Por que incidente e problema não são a mesma coisa

A gestão de incidentes foca em restaurar o serviço rapidamente. A gestão de problemas investiga a causa raiz para evitar que o mesmo incidente aconteça de novo.

Tratar os dois processos como sinônimos é o que faz equipes resolverem o mesmo incidente repetidamente sem nunca eliminar a origem.

Um exemplo prático ajuda a entender a diferença: se um servidor cai e a equipe reinicia o serviço, o incidente foi resolvido. Mas se a causa da queda não foi investigada, é provável que o mesmo incidente volte a acontecer dias depois.

A gestão de incidentes apaga o incêndio. A gestão de problemas investiga por que ele começou.

Por isso, incidentes recorrentes do mesmo tipo são um sinal de que vale abrir um chamado de problema para investigação mais profunda, em paralelo à resolução rápida que a gestão de incidentes já entrega.

Como reduzir o tempo médio de resolução de incidentes

O indicador mais usado para medir a eficiência da gestão de incidentes é o tempo médio de resolução, conhecido como MTTR (Mean Time To Resolve). Reduzir esse tempo depende de três fatores que se reforçam mutuamente:

• Detecção mais rápida, idealmente por monitoramento proativo que identifica o incidente antes que o usuário perceba e abra o chamado manualmente.
• Diagnóstico inicial eficiente, com o técnico do primeiro nível tendo acesso a uma base de conhecimento com soluções documentadas de incidentes semelhantes já resolvidos.
• Escalonamento sem atraso, quando o primeiro nível não resolve o incidente dentro de um prazo definido, ele precisa subir automaticamente para o nível seguinte, sem depender de alguém perceber que está parado.

O controle de SLA com escalonamento automático é o que sustenta esse terceiro ponto na prática, garantindo que incidentes críticos não fiquem presos esperando que alguém olhe para a fila no momento certo.

Como estruturar a gestão de incidentes no Milldesk

Implementar a gestão de incidentes seguindo as práticas do ITIL 4 não exige reconstruir a operação do zero. O Milldesk oferece a estrutura necessária para que o processo funcione desde o primeiro chamado:

• O formulário de abertura separa incidentes de solicitações de serviço desde o início, evitando que os dois fluxos se misturem na mesma fila de prioridade.
• A priorização automática aplica a matriz de impacto e urgência configurada pelo gestor, garantindo que incidentes críticos entrem na frente sem decisão manual a cada chamado.
• O escalonamento por níveis redireciona o incidente automaticamente quando o prazo do nível atual vence sem resolução, mantendo o fluxo ativo mesmo em momentos de sobrecarga da equipe.
• A base de conhecimento integrada disponibiliza soluções de incidentes anteriores diretamente no ticket, reduzindo o tempo de diagnóstico do técnico responsável.
• Os relatórios de MTTR e taxa de reabertura permitem acompanhar se o processo de gestão de incidentes está realmente reduzindo o impacto na operação ao longo do tempo.

Teste o Milldesk gratuitamente por 7 dias e estruture a gestão de incidentes da sua operação com práticas alinhadas ao ITIL 4.

Perguntas frequentes

1. O que é um incidente segundo o ITIL 4?
   É uma interrupção não planejada de um serviço ou uma redução na qualidade de um serviço que já estava em funcionamento, como um sistema lento ou uma queda de servidor.
2. Qual a diferença entre incidente e solicitação de serviço?
   O incidente interrompe algo que já funcionava. A solicitação de serviço é um pedido de algo novo, como acesso a um sistema. Os dois exigem prioridade e tratamento diferentes.
3. O que é MTTR e por que ele importa?
   MTTR é o tempo médio de resolução de incidentes. Reduzir esse indicador depende de detecção rápida, diagnóstico eficiente com base de conhecimento e escalonamento automático sem atraso.
4. Gestão de incidentes e gestão de problemas são a mesma prática?
   Não. A gestão de incidentes restaura o serviço rapidamente. A gestão de problemas investiga a causa raiz para evitar que o mesmo incidente se repita.
5. Como a priorização de incidentes funciona na prática?
   Pela combinação de impacto e urgência. Alto impacto com alta urgência gera prioridade crítica, independentemente da ordem de chegada do chamado na fila.

Quando uma equipe de suporte adota práticas certificadas, o que está em jogo não é apenas o conhecimento individual de quem passou por uma certificação ITIL.

É a adoção de processos validados por um framework reconhecido internacionalmente, testados em milhares de operações diferentes, que reduzem a dependência de improviso e de conhecimento tácito concentrado em poucas pessoas da equipe.

O que torna uma prática de TI certificada

Uma prática é considerada certificada quando segue uma estrutura formal, documentada e reconhecida por um framework de governança de TI, como o ITIL 4. Isso significa que cada etapa do processo tem critério definido, desde a abertura de um chamado até o encerramento, sem depender da experiência individual de quem está atendendo.

A diferença de maturidade de uma equipe estruturada acontece, por exemplo, quando um técnico sai da empresa e o conhecimento sobre como tratar determinado tipo de chamado não vai com ele, porque está documentado no processo, não só na cabeça da pessoa.

O sistema de help desk que aplica práticas certificadas estrutura isso de forma nativa: categorias, fluxos de atendimento e critérios de priorização seguem um padrão consistente, independentemente de qual técnico está na fila no momento.

Por que a certificação do processo importa mais que a certificação individual

É comum confundir práticas certificadas com profissionais certificados. Ter um analista com certificação ITIL Foundation na equipe não garante que a operação siga práticas certificadas se o processo em si não está estruturado dessa forma.

A certificação individual ajuda o profissional a entender o framework, mas é a aplicação consistente desse framework no fluxo de atendimento que gera o resultado.

Isso fica claro quando se observa o que realmente muda na prática:

• Processos documentados e replicáveis, onde qualquer novo técnico consegue entender o fluxo de atendimento sem depender de treinamento informal com colegas mais experientes.
• Critérios objetivos de priorização, baseados em impacto e urgência, em vez de decisão individual sobre o que parece mais urgente no momento.
• Métricas padronizadas de acompanhamento, que permitem comparar desempenho entre períodos e identificar desvios reais, não apenas percepção subjetiva de que a fila está pior.

Quais são as 34 práticas do ITIL 4

O ITIL 4 organiza suas práticas certificadas em três categorias. Entender essa divisão ajuda a priorizar onde investir esforço de implementação primeiro.

• Práticas de gestão geral: aplicáveis a toda a organização, não só à área de TI, como gestão de riscos, gestão financeira de serviços e gestão de fornecedores.
• Práticas de gestão de serviço: específicas para operações de TI, como gestão de incidentes, gestão de problemas, gestão do catálogo de serviços e gestão de nível de serviço.
• Práticas de gestão técnica: focadas em infraestrutura e desenvolvimento, como gestão de implantação e gestão de infraestrutura e plataforma.

Para a maioria das operações de suporte, o ponto de partida recomendado são as práticas de gestão de serviço, porque é onde o impacto no dia a dia do atendimento aparece primeiro e de forma mais visível para o usuário final.

Como aplicar práticas certificadas sem burocratizar o atendimento

O medo mais comum ao adotar um framework como o ITIL 4 é transformar o atendimento em um processo lento e cheio de etapas burocráticas. Esse risco existe quando a prática é implementada de forma literal, sem adaptação à realidade da operação.

O objetivo de uma prática certificada não é seguir o manual à risca, é resolver melhor com menos retrabalho.

Na prática, isso significa adaptar o nível de detalhe da prática ao tamanho e à maturidade da equipe. Uma operação pequena não precisa de todos os campos e aprovações que uma operação de grande porte exige. O framework é um guia, não uma camisa de força.

O workflow visual de um sistema de chamados é o que permite essa adaptação: o gestor configura o nível de formalidade que faz sentido para a operação, mantendo a essência da prática certificada sem adicionar etapas que não agregam valor ao atendimento.

Como medir se as práticas certificadas estão funcionando na operação

Adotar uma prática certificada sem medir resultado é repetir o erro de operar por costume, só que com um nome mais sofisticado. A prova de que uma prática está funcionando aparece nos indicadores, não na adesão formal ao framework.

Os sinais mais claros de que as práticas certificadas estão gerando resultado real incluem:

• Redução no tempo médio de resolução, porque o processo elimina etapas redundantes e direciona o chamado certo para o técnico certo desde a abertura.
• Queda na taxa de reabertura, indicando que os chamados estão sendo resolvidos de forma definitiva, não apenas contornados temporariamente.
• Consistência entre técnicos diferentes, com tempos de resolução e qualidade de atendimento parecidos independentemente de quem assumiu o chamado.

O sistema de chamados com relatórios detalhados é o que permite acompanhar esses indicadores de forma contínua, transformando a adoção de práticas certificadas em um ciclo de melhoria, não em um projeto pontual de implementação.

Como o Milldesk sustenta a adoção de práticas certificadas

Implementar práticas certificadas exige uma ferramenta que absorva a estrutura sem exigir que a equipe aprenda um sistema complexo. O Milldesk foi desenvolvido com aderência às práticas do ITIL 4, oferecendo:

• Workflow visual configurável que reflete o fluxo de atendimento definido pela equipe, com etapas, responsáveis e critérios de transição alinhados às práticas certificadas escolhidas.
• Priorização automática por impacto e urgência, eliminando a decisão subjetiva sobre qual chamado é mais urgente no momento.
• Relatórios segmentados por técnico, categoria e período, permitindo acompanhar se as práticas adotadas estão gerando resultado real na operação.
• Base de conhecimento integrada ao fluxo de atendimento, sustentando a documentação de processo que caracteriza uma prática certificada.
• Suporte em português e implantação acompanhada, reduzindo a curva de adaptação ao adotar um framework novo na operação.

Teste o Milldesk gratuitamente por 7 dias e veja como aplicar práticas certificadas sem burocratizar o atendimento da sua equipe.

Perguntas frequentes

1. O que diferencia uma prática certificada de um processo informal?
   A prática certificada segue uma estrutura documentada e validada por um framework como o ITIL 4, com critérios objetivos em cada etapa. O processo informal depende da experiência individual de quem está atendendo, o que gera inconsistência entre técnicos.
2. Ter um profissional certificado em ITIL garante práticas certificadas na operação?
   Não necessariamente. A certificação individual ajuda o profissional a entender o framework, mas só gera resultado real quando o processo da operação é estruturado de acordo com essas práticas.
3. Quantas práticas o ITIL 4 reconhece?
   O ITIL 4 organiza 34 práticas em três categorias: gestão geral, gestão de serviço e gestão técnica. As práticas de gestão de serviço costumam ser o ponto de partida para operações de suporte.
4. Adotar práticas certificadas torna o atendimento mais lento?
   Não quando implementado corretamente. O risco de burocratização existe na aplicação literal do framework sem adaptação ao tamanho da operação. O objetivo da prática certificada é reduzir retrabalho, não adicionar etapas desnecessárias.
5. Como saber se as práticas certificadas estão funcionando?
   Pelos indicadores: redução no tempo médio de resolução, queda na taxa de reabertura e consistência de desempenho entre técnicos diferentes, acompanhados por relatórios contínuos.

Migrar de uma ferramenta legada é uma decisão que a maioria das equipes adia mais do que deveria. O sistema atual tem problemas conhecidos, mas a ideia de mover anos de histórico, reconfigurar fluxos e treinar a equipe numa nova plataforma parece um risco maior do que conviver com as limitações do que já existe.

Na prática, o custo de não migrar cresce silenciosamente a cada mês que passa. Entender o que está em jogo na transição é o que permite planejar uma migração para o Milldesk sem perda de dados e sem impacto na operação durante o período de corte.

O que significa migrar de uma ferramenta legada na prática

Antes de mais nada, vale dizer que uma ferramenta legada não significa necessariamente sistema antigo. Na verdade, significa qualquer plataforma que a operação cresceu além: um sistema que não escala com o volume de chamados, que não oferece controle de SLA nativo, que cobra em dólar sem suporte em português ou que simplesmente não entrega a visibilidade que o gestor precisa para tomar decisão.

O primeiro passo antes de qualquer migração é mapear o que realmente precisa ser transferido. Nem tudo que está na ferramenta atual tem valor operacional, e tentar migrar tudo de uma vez é a principal razão pela qual projetos de transição atrasam ou perdem dados no caminho.

De forma geral, os dados se dividem em duas categorias:

• O que precisa ser migrado: histórico de chamados encerrados, cadastro de solicitantes, contratos ativos, SLAs vigentes e base de conhecimento com soluções documentadas que a equipe ainda consulta.
• O que pode ser reconfigurado no destino: fluxos de atendimento, regras de priorização, categorias de chamado, níveis de acesso por perfil e integrações com outros sistemas.

Quais dados têm mais risco de se perder na migração

de uma ferramenta legada

O histórico de chamados encerrados é o dado mais sensível da transição porque, uma vez perdido, não tem como recuperar. Ele sustenta análises de recorrência, justificativas para decisões de dimensionamento de equipe e, em alguns setores, é exigido por compliance por períodos determinados.

Antes de iniciar qualquer exportação, vale validar em qual formato a ferramenta atual permite extrair os dados: CSV, JSON, API ou exportação manual.

Ferramentas legadas mais antigas muitas vezes só exportam relatórios em PDF, o que inviabiliza a importação estruturada no sistema de chamados de destino.

O cadastro de solicitantes é o segundo ponto crítico. Quando os dados de usuário não são migrados corretamente, o histórico de chamados perde o vínculo com a pessoa e vira um registro órfão que não serve para análise nem para consulta no atendimento.

A validação dos campos de nome, e-mail e telefone antes da importação é o que garante que a ligação entre chamado e solicitante se mantenha intacta.

Como o Milldesk recebe dados de sistemas anteriores

O Milldesk aceita importação de dados via arquivo estruturado, o que cobre a maioria dos cenários de migração de ferramentas que permitem exportação em CSV ou planilha.

Em detalhes, o time de implantação acompanha esse processo desde o mapeamento dos campos até a validação dos dados importados, sem que a equipe de TI precise desenvolver nenhum conector ou script personalizado.

Para histórico que não pode ser importado de forma estruturada, a alternativa mais comum é manter a ferramenta legada em modo leitura por um período determinado, geralmente de 30 a 90 dias, enquanto a operação já está rodando integralmente no Milldesk. Isso garante acesso ao histórico antigo sem atrasar o corte para o novo sistema.

O sistema de help desk do Milldesk foi desenvolvido para absorver operações de diferentes portes, com suporte em português e cobrança em reais, o que elimina duas das principais fricções que aparecem durante migrações de plataformas internacionais.

O que configurar no Milldesk antes de fazer o corte

Fazer o corte antes de o sistema destino estar configurado é o segundo erro mais comum em migrações, perdendo apenas para a falta de backup dos dados de origem. Antes de desligar a ferramenta anterior, o Milldesk precisa estar com a estrutura básica pronta para absorver o volume real da operação.

Os pontos que precisam estar configurados antes do primeiro chamado entrar incluem:

• Categorias e subcategorias de chamado alinhadas com o vocabulário que a equipe e os solicitantes já usam, para evitar retrabalho de reclassificação depois da migração.
• SLAs por nível de prioridade com os prazos calibrados a partir do histórico real de tempo de resolução, não de estimativas. O Milldesk permite configurar SLAs com pausa automática para períodos de aguardo de retorno.
• Fluxos de atendimento configurados no workflow visual, com regras de encaminhamento, escalonamento e notificação ativas antes do primeiro chamado entrar.
• Perfis de acesso configurados por nível de permissão, garantindo que técnicos, gestores e solicitantes vejam apenas o que precisam desde o primeiro acesso.

A importância do período de transição de ferramentas

A migração de uma ferramenta legada não termina após a ativação da nova. Para melhor entender, o período de transição, que vai do corte até a operação estar estabilizada na nova plataforma, é onde a maioria dos problemas aparecem e onde a equipe precisa de mais suporte.

Manter a ferramenta legada em modo leitura durante esse período é uma proteção importante: se um dado crítico não migrou corretamente ou se um fluxo precisa de ajuste, a operação não para.

No caso do Milldesk, a priorização de chamados já funciona desde o primeiro, mas as configurações finas de escalonamento e SLA geralmente precisam de uma ou duas semanas de operação real para serem ajustadas.

Vale dizer ainda que o Milldesk oferece suporte humanizado em português durante todo esse processo, o que faz diferença especialmente para equipes que estão migrando de plataformas internacionais com suporte via ticket em inglês.

O que avaliar antes de fechar a decisão de migração

Migrar de uma ferramenta legada para o Milldesk é uma decisão que vale ser tomada com critérios claros, não apenas com a insatisfação com o sistema atual como único argumento.

Antes de fechar, vale confirmar:

• Que dados precisam ser migrados e em qual formato a ferramenta atual permite exportá-los, para evitar surpresas no meio do projeto.
• Que o histórico de chamados críticos está coberto por backup independente antes do início da migração, independentemente do que o fornecedor atual garante.
• Que o Milldesk já está configurado com SLAs, fluxos e categorias antes do corte, para que a operação não precise improvisar nos primeiros dias.
• Que a ferramenta legada ficará em modo leitura por pelo menos 30 dias depois do corte, como proteção contra dados que não migraram de forma estruturada.
• Que a equipe passou por pelo menos uma sessão de uso guiado antes do primeiro chamado entrar no novo sistema, para evitar resistência no período crítico da transição.

Conheça o Milldesk, solicite uma demonstração e avalie a migração com o time de implantação antes de tomar qualquer decisão.

Perguntas frequentes

1. O que é uma ferramenta legada no contexto de help desk?
   É qualquer plataforma que a operação cresceu além: sistema que não escala com o volume, sem controle de SLA nativo, com suporte limitado ou que não entrega a visibilidade necessária para a gestão.
2. O Milldesk consegue importar dados de outras ferramentas?
   Sim. O Milldesk aceita importação via arquivo estruturado e o time de implantação acompanha o processo desde o mapeamento dos campos até a validação dos dados importados.
3. O que fazer com o histórico que não pode ser importado?
   A alternativa mais comum é manter a ferramenta legada em modo leitura por 30 a 90 dias enquanto a operação já roda no Milldesk, garantindo acesso ao histórico antigo sem atrasar o corte.
4. Quais dados têm mais risco de se perder na migração?
   Histórico de chamados encerrados e cadastro de solicitantes. A perda do vínculo entre chamado e pessoa torna o histórico inutilizável para análise e consulta no atendimento.
5. O que precisa estar configurado no Milldesk antes do corte?
   Categorias de chamado, SLAs por nível de prioridade, fluxos de atendimento no workflow visual e perfis de acesso por nível de permissão.
6. Quanto tempo dura o período de transição?
   Depende do volume de dados e da complexidade dos fluxos. Operações menores estabilizam em uma a duas semanas; operações com histórico extenso e muitas regras podem levar até 60 dias para ajuste fino das configurações.

O WhatsApp Business já é canal de suporte em boa parte das operações de TI no Brasil, mas integrar o WhatsApp Business ao Milldesk é o que transforma conversas avulsas em chamados rastreáveis, com prazo, responsável e histórico.

De forma simples e breve, o processo é direto e não exige configuração técnica complexa. A extensão do Chrome do Milldesk foi desenvolvida especificamente para esse fim, e o resultado é um fluxo onde cada mensagem recebida vira ticket em segundos, sem alternância de telas e sem digitação manual.

O que é necessário antes de integrar o WhatsApp Business ao Milldesk

Antes de configurar qualquer integração, dois requisitos precisam estar ativos: uma conta WhatsApp Business instalada no dispositivo da equipe e o Milldesk configurado com o cadastro dos solicitantes que entram em contato via WhatsApp. Esses dados são usados pela extensão para identificar automaticamente quem está abrindo o chamado.

O WhatsApp Business (diferente do WhatsApp pessoal) oferece funcionalidades específicas para operações de suporte:

• Perfil comercial completo, com nome da empresa, descrição, horário de atendimento e link de contato, o que dá credibilidade ao canal e organiza as expectativas do usuário.
• Mensagens automáticas de saudação e ausência, que informam o usuário quando a equipe não está disponível e reduzem a percepção de falta de resposta fora do horário comercial.
• Etiquetas para organização de conversas, que facilitam a triagem manual enquanto o volume ainda é baixo e a integração com o sistema de chamados está sendo configurada.

Com esses dois pontos ativos, a integração com o Milldesk pode ser feita sem dependência de equipe técnica especializada.

Como instalar e configurar a extensão do Chrome do Milldesk

A extensão do Chrome é o mecanismo central da integração entre o WhatsApp Business Web e o sistema de chamados do Milldesk. A instalação é feita diretamente na Chrome Web Store e não exige configuração de servidor ou acesso a APIs externas.

O processo de configuração segue esta ordem:

1. Instale a extensão do Chrome do Milldesk disponível na Chrome Web Store e faça login com as credenciais do sistema – a extensão se conecta automaticamente ao ambiente da sua operação.
2. Acesse o WhatsApp Business Web no navegador com a extensão ativa. Um botão do Milldesk aparece dentro da interface do WhatsApp, disponível em qualquer conversa aberta.
3. Configure os campos padrão de abertura, definindo quais informações serão coletadas na conversão: categoria do chamado, nível de prioridade e departamento responsável, para que a priorização automática funcione desde o primeiro ticket.
4. Cadastre os solicitantes recorrentes no Milldesk com nome, e-mail e telefone, para que a identificação automática funcione no momento da conversão. Contatos já cadastrados são reconhecidos pelo sistema sem nenhuma ação adicional.

Com a extensão instalada e os campos configurados, o primeiro chamado pode ser convertido imediatamente, sem nenhuma etapa técnica adicional.

Como converter uma conversa do WhatsApp em chamado no Milldesk

Com a extensão ativa, o processo de conversão é direto. Dentro de qualquer conversa no WhatsApp Business Web, o botão do Milldesk fica visível na interface – um clique abre o formulário de abertura com os dados do solicitante já preenchidos, caso ele esteja cadastrado.

O técnico revisa a descrição, confirma a categoria e a prioridade e registra o chamado. A partir desse momento, o ticket entra na fila unificada do sistema com SLA ativo, número de protocolo gerado e histórico iniciado.

O usuário pode ser notificado automaticamente com o número do chamado, o que encerra a dependência do acompanhamento pela conversa do WhatsApp.

Afinal, a conversa no aplicativo continua existindo para comunicação direta, mas o controle do atendimento passa a acontecer integralmente no Milldesk, com visibilidade para toda a equipe e dados acessíveis no dashboard em tempo real.

O que muda na operação depois que a integração está ativa

Quando o WhatsApp Business está integrado ao sistema de help desk, a fila de atendimento passa a refletir todos os canais em um único lugar.

O gestor não precisa mais checar o WhatsApp separadamente para saber o que está em aberto, afinal, cada mensagem convertida em ticket aparece no dashboard com o mesmo status, prazo e visibilidade dos chamados de e-mail e portal.

O controle de SLA começa a funcionar para o canal assim que o primeiro ticket é convertido. O escalonamento automático, configurado previamente no workflow visual, aciona o nível superior quando o prazo não é cumprido, sem depender de monitoramento manual.

O histórico de cada solicitante fica vinculado ao cadastro no sistema, o que significa que em um novo contato via WhatsApp, o técnico acessa os atendimentos anteriores imediatamente, sem precisar recuperar a conversa no aplicativo ou perguntar ao colega o que foi tratado antes.

Passo a passo completo para integrar o WhatsApp Business ao Milldesk

A integração é rápida e a equipe absorve o fluxo no primeiro dia de uso. Para garantir que tudo funcione corretamente desde o início, siga esta sequência antes de converter o primeiro chamado:

1. Ative uma conta WhatsApp Business no dispositivo da equipe e configure o perfil comercial com nome, horário de atendimento e mensagem automática de saudação.
2. Instale a extensão do Chrome do Milldesk na Chrome Web Store e conecte ao ambiente do sistema com as credenciais da sua operação.
3. Cadastre os solicitantes recorrentes no Milldesk com nome, e-mail e telefone para que a identificação automática funcione na conversão.
4. Configure os campos de abertura com categoria, prioridade e departamento, garantindo que a priorização automática e o SLA sejam aplicados corretamente desde o primeiro ticket.
5. Acesse o WhatsApp Business Web com a extensão ativa, abra uma conversa e converta o primeiro chamado para validar o fluxo completo antes de liberar para toda a equipe.

Teste o Milldesk gratuitamente por 7 dias e configure a integração com o WhatsApp Business na sua operação.

Perguntas frequentes

1. O Milldesk tem integração nativa com o WhatsApp Business?
   Sim. O Milldesk oferece uma extensão do Chrome que converte conversas do WhatsApp Business Web em tickets diretamente no sistema, sem necessidade de API externa ou configuração técnica avançada.
2. Preciso de conta WhatsApp Business para integrar ao Milldesk?
   Sim. A conta WhatsApp Business é necessária para usar o WhatsApp Business Web, que é onde a extensão do Chrome do Milldesk opera para converter conversas em chamados.
3. A extensão do Chrome funciona em qualquer navegador?
   A extensão foi desenvolvida para o Google Chrome. Para usá-la, o WhatsApp Business Web precisa estar aberto no Chrome com a extensão instalada e conectada ao ambiente do Milldesk.
4. O SLA funciona para chamados convertidos do WhatsApp? Sim. Assim que o chamado é convertido, ele entra na fila com o SLA ativo, seguindo os mesmos critérios de prazo, alerta e escalonamento configurados para os demais canais.
5. Como o histórico do solicitante fica registrado?
   Cada chamado convertido é vinculado ao cadastro do solicitante no sistema. Em novos contatos via WhatsApp, o histórico completo de atendimentos anteriores está acessível desde o início da conversa.
6. Quantos técnicos podem usar a extensão simultaneamente?
   Cada técnico instala a extensão no próprio Chrome e acessa com suas credenciais do Milldesk. Não há limite de usuários simultâneos – cada um opera de forma independente dentro do sistema.