Sistema de tickets da Microsoft: as 5 opções reais em 2026

A Microsoft tem um sistema de tickets?

Não como um produto que você possa comprar com esse nome.

O mais próximo é o Dynamics 365 Customer Service, que a Microsoft posiciona com a frase "Capacite os representantes de atendimento a resolver problemas rapidamente usando agentes de IA". É uma aplicação de gestão de casos que fica sobre a stack do Dynamics 365 e do Power Platform, vendida como o software corporativo é vendido: a única chamada para ação de cada plano pago é Fale com a gente. A linha de vendas atende de segunda a sexta, das 6h às 15h, horário do Pacífico.

Esse enquadramento importa mais do que parece. Um sistema de tickets é uma fila com um fluxo de trabalho. Um caso de CRM é um registro vinculado a um cliente, e os dois se sobrepõem o suficiente para que alguns compradores acabem procurando um sistema de tickets CRM em vez de escolher um caminho. Mas a forma de compra e o preço não têm nada a ver, nem o esforço de configuração, e é por isso que tantas equipes de TI acabam construindo algo por conta própria.

Mais uma mudança de nomenclatura vale conhecer antes de ler qualquer página da Microsoft em 2026. A Microsoft renomeou os humanos. Nas páginas do Customer Service, a pessoa que responde tickets agora é um "representante de atendimento" ou "service rep", e a palavra "agente" foi reatribuída à IA. A seção dedicada na página do produto está literalmente intitulada AGENTES DE ATENDIMENTO, descrevendo "atendimento agêntico". Quando um documento da Microsoft diz que um agente resolveu o caso, isso não significa que uma pessoa o fez.

As cinco rotas, lado a lado

Aqui está a comparação honesta antes de eu passar por cada uma. Todo preço abaixo é o preço de tabela nos EUA, por usuário ao mês, pago anualmente, retirado das próprias páginas de preços da Microsoft em 31 de julho de 2026.

Duas coisas chamam atenção nessa tabela. Relatórios estão faltando na ponta barata de cada rota, incluindo o próprio produto de 50 $ da Microsoft. E o ID de ticket, aquilo que faz de uma fila realmente uma fila, não existe de forma adequada até a rota três. Se IA na fila é o motivo real pelo qual você está comparando rotas, meu olhar mais amplo sobre IA para sistemas de tickets vale a pena ler junto com este.

Rota 1: a caixa de entrada compartilhada

Quase toda fila de suporte da Microsoft começa aqui, e por um tempo funciona bem. Uma caixa de entrada compartilhada no Outlook não custa nada além das licenças do Microsoft 365 que você já tem. Todo mundo consegue vê-la, e ninguém precisa aprender nada novo. Para sistemas de tickets de equipes pequenas que nunca crescem além de um punhado de agentes, geralmente é a resposta completa.

Ela falha em uma coisa: não há ID de ticket, então não há estado. Você não consegue saber se um e-mail está sendo tratado. Você não consegue saber se a thread que chegou na terça é o mesmo problema da semana passada. E dois agentes eventualmente vão responder ao mesmo cliente em um intervalo de um minuto. Toda solução alternativa que as pessoas inventam (categorias de cor, uma pasta "assumido", uma convenção de nomes no assunto) é uma reimplementação artesanal de um campo de status.

O limite é mais baixo do que as equipes esperam. Assim que mais de duas pessoas trabalham na mesma caixa de entrada, ou assim que alguém pergunta "quanto tempo estamos levando para responder?", a caixa de entrada já deixou de ser suficiente. Escrevi uma comparação mais completa de caixa de entrada compartilhada versus sistema de tickets, além de um olhar separado sobre software de central de ajuda por e-mail para equipes que querem manter o e-mail como porta de entrada sem perder a fila.

A conclusão: ok como ponto de partida, mas não construa sua estrutura em torno disso. No momento em que você está escrevendo regras sobre quem toca em quê, você já superou isso.

Rota 2: uma lista do SharePoint com Power Automate por cima

Essa é a construção caseira clássica, e a que mais me perguntam sobre. Uma lista do SharePoint guarda os tickets. Um fluxo do Power Automate detecta novos itens e dispara notificações, e uma aba do Teams exibe a lista. Parece grátis porque você já paga pelos três, embora valha a pena verificar os preços do SharePoint frente a uma central dedicada antes de assumir que isso se mantém em escala.

É uma opção real. Também carrega o teto mais precisamente documentado de toda a stack da Microsoft, e quase ninguém verifica esse teto antes de construir.

O muro dos 5.000 itens

O List View Threshold do SharePoint é 5.000. Nas próprias palavras da Microsoft: "Operações que excedem esse limite são bloqueadas". O motivo é o bloqueio de linhas do SQL: acima de aproximadamente 5.000 linhas bloqueadas, o SQL Server considera mais eficiente bloquear a tabela inteira, então a Microsoft bloqueia a consulta em vez disso.

Três detalhes que se perdem na maioria dos relatos:

• O aviso aparece em 3.000, não em 5.000. Você o verá na página de Configurações da Lista bem antes de algo realmente quebrar.
• O número não é fixo. A Microsoft pondera isso diretamente: "O número real nem sempre é 5.000, e pode variar dependendo do seu site, da quantidade de atividade no banco de dados e da configuração do seu site."
• Você não pode aumentá-lo. A substituição de 20.000 itens para auditores e administradores é um recurso do SharePoint Server. No SharePoint Online, o limite "não pode ser alterado".

A lista em si suporta 30 milhões de itens. Esse é o número que as pessoas citam quando dizem que o SharePoint escala bem. Mas uma fila é, na verdade, uma visualização sobre uma lista, e visualizações quebram muito antes da lista. Uma equipe que fecha 200 tickets por mês entra na faixa de aviso em 15 meses, e na faixa de bloqueio em dois anos.

O fluxo que a executa está no piso mais baixo

O Power Automate classifica cada conta em um perfil de desempenho. Uma equipe que constrói sobre as licenças do Microsoft 365 que já possui cai em Low, a pior linha de cada tabela que a Microsoft publica. No Low:

• 10.000 solicitações do Power Platform por 24 horas, contra 200.000 no Medium e 500.000 no High.
• Apply to each limitado a 5.000 itens de array, contra 100.000 em qualquer outro perfil. A paginação também limita em 5.000, então isso se acumula com o limite do SharePoint em vez de cancelá-lo.
• O intervalo mínimo de recorrência é de 60 segundos, então um fluxo de "novo ticket" que faz polling tem um atraso de detecção no pior caso de um minuto inteiro antes que algo seja disparado.
• O próprio conector do SharePoint limita a 600 chamadas de API por conexão a cada 60 segundos.

E o assassino silencioso: segundo a documentação de limites do Power Automate da Microsoft, um fluxo que fica acima dos limites "por 14 dias, o sistema o desativa". Fluxos com erros também são desativados após 14 dias. Uma fila cujo roteamento simplesmente para de funcionar silenciosamente duas semanas depois de um pico de volume é uma terça-feira muito ruim.

Mais uma pegadinha de licenciamento está aqui. Uma licença comum do Microsoft 365 carrega 6.000 solicitações do Power Platform por usuário a cada 24 horas, não as 40.000 que um assento pago do Power Platform recebe. Cada chamada de conector conta como uma solicitação, assim como toda ação HTTP, e também toda ação integrada, desde inicializar uma variável até um compose simples. A Microsoft diz isso claramente na sua documentação de limites de solicitação: "Tanto ações bem-sucedidas quanto falhas contam para esses limites. Tentativas e solicitações de paginação também contam."

A conclusão: uma boa escolha para uma fila interna pequena com volume previsível e sem plano de crescimento. Não coloque uma fila voltada ao cliente nela, e marque um lembrete para o dia em que a lista passar de 3.000 linhas.

Rota 3: Power Apps sobre o Dataverse

Se a construção do SharePoint é onde as equipes começam, essa é para onde elas escalam quando ele começa a ranger. Um Power App orientado a modelo sobre o Dataverse te dá um modelo de dados real, relacionamentos reais, um ID de ticket real e uma interface que você controla.

O problema é o licenciamento, e a Microsoft coloca isso da forma mais clara possível: "Construir apps não é cobrado, mas usá-los exige licenças pagas." O Power Apps Developer Plan gratuito cobre construção e testes em três ambientes de desenvolvedor, com um teto de 750 fluxos de automação por mês. Produção é uma SKU diferente.

Então o piso real é de 35 $ por agente ao mês, com compromisso anual, antes de um único ticket ser respondido. Dez agentes são 350 $ ao mês, ou 4.200 $ ao ano, por um software que você ainda tem que construir e manter você mesmo.

Duas notas de rodapé mordem na prática. Primeiro, as concessões do Dataverse são agrupadas no nível do tenant em vez de por usuário: 250 MB de banco de dados e 2 GB de arquivo por assento Premium, então dez agentes compartilham um pool de 2,5 GB de banco de dados. Um sistema de tickets com anexos vai esgotar o pool de banco de dados muito antes do pool de arquivos, e ampliá-lo custa 40 $ por GB ao mês. Segundo, os recursos agênticos da Microsoft no Power Apps estão "disponíveis apenas em apps orientados a modelo" - se você construir sua fila como um app de tela (canvas), essa camada simplesmente não existe para você.

O problema de delegação sobre o qual ninguém avisa

Se você construir sobre o SharePoint em vez do Dataverse, a delegação do Power Apps muda silenciosamente o que seu app pode fazer. Aquela que pega todo mundo: os campos de ID do SharePoint parecem números no Power Apps, mas são texto por baixo, então o SharePoint só "suporta a operação de igual ('=')" para a delegação em um campo de ID. Operadores relacionais simplesmente não funcionam. "Mostre-me todo ticket com um ID acima de 4.000" não é uma consulta delegável.

Not nunca delega. Catorze campos de sistema nunca delegam. UpdateIf e RemoveIf na verdade não delegam de fato, eles "funcionam localmente e simulam a delegação com um limite de 500/2000 registros." Cada um é sobrevivível por conta própria. Juntos, são o motivo pelo qual as filas caseiras da Microsoft ganham fama de serem rápidas no primeiro dia e lentas no dia 400.

A conclusão: a construção certa se seu fluxo de trabalho é verdadeiramente incomum e você tem alguém técnico na equipe. Se seus requisitos são "tickets, status, atribuição, SLAs", você está a ponto de passar meses reconstruindo uma central de ajuda interna que já existe como produto empacotado. Várias centrais internas empacotadas cobrem exatamente esse formato de fábrica, e se o custo de licenciamento for a objeção, existe um sistema de tickets de código aberto que você poderia hospedar você mesmo. A própria Microsoft enquadra assim, listando "Gestão de central de ajuda" como um de seus templates prontos para uso do Power Apps, junto com integração de novos funcionários e checkout de ativos.

Rota 4: um agente do Copilot Studio dentro do Teams

Essa é mais uma camada de desviação do que um sistema de tickets, e vale a pena separá-la, porque muitos projetos de "construímos um sistema de tickets no Teams" são na verdade isso.

O Copilot Studio é a plataforma low-code da Microsoft para construir agentes. Ela absorveu o Power Virtual Agents, publica no Teams, SharePoint e Microsoft 365 Copilot, e alcança mais de 1.400 conectores. A Microsoft afirma que 90% das Fortune 500 o usam. No G2 ele tem nota 4,4 de 5 em 156 avaliações.

Para uma fila de TI com perguntas repetidas ("como redefino minha VPN", "onde está a política de despesas"), um agente no Teams que lê seu SharePoint e Confluence é um uso legitimamente bom da stack, e é exatamente o tipo de trabalho que a IA no Microsoft Teams faz bem - é basicamente um bot de suporte de TI no Teams sentado na frente da sua fila. O que você não obtém é uma fila, um status, uma atribuição ou qualquer relatório sobre o que ele não conseguiu responder.

O modelo de custo é o que vale entender antes de se comprometer, e merece sua própria seção.

O segundo medidor: Copilot Credits

Aqui está a parte que surpreende quem calculou a Microsoft só pelo custo do assento. A licença do assento não inclui a IA. No Customer Service Professional e Enterprise, todos os quatro agentes de atendimento nomeados da Microsoft - o Agente de Gestão de Casos, o Agente de Gestão de Conhecimento do Cliente, o Agente de Intenção do Cliente e o Agente de Avaliação de Qualidade - estão todos marcados como "Requer Copilot Credits (vendidos separadamente)" na própria comparação de planos da Microsoft, algo que vale a pena ler junto com qualquer plano de desviação de tickets que você esteja construindo em torno disso.

Você compra créditos através do Copilot Studio a 200 $ por 25.000 Copilot Credits ao mês, pago anualmente. Isso equivale a 0,008 $ por crédito de tabela, embora a Microsoft nunca publique uma tarifa por crédito. Ambos os planos de crédito trazem o mesmo pré-requisito, impresso em cada cartão: "Uma assinatura do Azure é necessária para usar agentes."

O número que você não consegue obter é o número de que precisa. A própria nota de rodapé da Microsoft diz que, sempre que uma ação ou resposta é concluída por um agente, "um número variável de Copilot Credits será cobrado dependendo do uso específico", segundo sua página de preços do Power Automate. As taxas publicadas vão de 1 crédito para uma resposta clássica até 100 para uma resposta generativa premium. Some 10 pelo grounding do grafo do tenant, e um medidor separado de tokens premium por cima disso quando um modelo de raciocínio está envolvido. Não existe em nenhum lugar uma cifra de créditos por ticket resolvido, então você consegue calcular seu custo por pacote de créditos, mas nunca seu custo por ticket - exatamente a lacuna que um sistema de tickets com IA com preço por ticket foi feito para fechar.

O nível Premium a 195 $ lista "Capacidade incluída" para esses agentes, mas a nota de rodapé 6 qualifica isso como "Capacidade base de Copilot Credit" sem quantidade publicada. O número só existe no guia de licenciamento para download.

Nada disso é um risco teórico. Em junho de 2026, um usuário do r/copilotstudio descreveu exatamente o que um medidor imprevisível faz quando algo entra em loop:

"Eu então implantei um agente de dev para prod. Isso é tudo - um único agente. Hoje verifiquei minha assinatura do Azure e há uma fatura de ~47.000 $."

Woke up to a $47K bill after deploying ONE Copilot Studio agent, Reddit

O mecanismo apareceu nas respostas, e essa é a parte que vale a pena absorver antes de ligar qualquer coisa:

"Orçamentos para PAYG com assinaturas do Azure no Copilot têm apenas fins de alerta. Não há uma parada de serviço rígida para isso... tivemos um fluxo de agente disparado por e-mail entrante que entrou em loop enviando e-mails para a própria caixa de entrada por engano."

NikoThe1337, no mesmo tópico, Reddit

Um orçamento de pagamento por uso no Azure alerta, ele não interrompe. Um fluxo disparado por e-mail que pode responder à própria caixa de entrada é um loop, e o medidor continua correndo até alguém notar.

Quero ser justo aqui. Isso não é incompetência, é um problema real de modelagem: o uso realmente varia, e uma tarifa fixa por ticket significa que o fornecedor absorve a variância em vez do cliente. A própria pesquisa de preços da eesel pousou com força do outro lado disso. Testamos unidades inventadas e as retiramos, porque "crédito" forçava os clientes a fazer contas - a reação que ouvíamos repetidamente era alguma versão de "espera, o que é um crédito?" Tickets e sessões de chat são unidades em que os gestores de suporte já pensam. Quando a pessoa que precisa defender o orçamento não consegue prever a fatura, o lançamento trava no setor de compras, e nenhuma qualidade de modelo resolve isso.

Rota 5: Dynamics 365 Customer Service

O produto real. Se você quer que a Microsoft te venda um verdadeiro sistema de tickets ITSM em vez das partes soltas, é isso.

O que um caso realmente é

Os casos do Dynamics são mais rígidos do que a maioria dos tickets de central de ajuda. Vale a pena conhecer as restrições antes de desenhar um fluxo de trabalho em torno delas.

• Três status vêm de fábrica: Ativo, Resolvido, Cancelado. Ativo traz substatus nomeados (Em andamento, Em espera, Aguardando detalhes, Investigando).
• A fusão de casos tem um teto de 10. Por padrão, você pode fundir até 10 casos por vez, e o caso fundido muda para Cancelado com um motivo de status Fundido.
• A hierarquia tem exatamente dois níveis. Um caso filho não pode ter um caso filho, e um caso pai não pode ser filho de outro caso. Se o seu modelo de escalonamento tem três níveis de aninhamento, ele não se encaixa.
• A migração de SLA tem um teto. Mover mais de 1.000 SLAs pode falhar na verificação de pré-migração, e as condições de SLA em entidades relacionadas são limitadas a um nível.

Nenhuma dessas é um fator decisivo. São todas o tipo de coisa que você quer descobrir na semana um, e não na semana nove, especialmente se a gestão de SLA for a parte com que sua equipe realmente se importa.

O preço, e o portão que importa

O ponto sensível aqui é o portão dos relatórios. A 50 $ por assento, o Professional te dá gestão de casos e nenhum analytics ou relatório de KPI. Também nenhuma integração com o Microsoft Teams e nenhum roteamento unificado. Tudo isso começa no assento Enterprise de 105 $, um salto de 110% para desbloquear a capacidade de medir sua própria fila.

Note também que o Premium (195 $) fica muito próximo do Enterprise (105 $) mais o Contact Center (110 $), agrupado com um desconto de 20 $. A voz então é uma terceira conta: a nota de rodapé 8 afirma que "o preço do Azure Communication Services é separado e não incluído", então o assento de 195 $ compra o software do contact center e não os minutos.

O que a Microsoft consegue provar

Todo ponto de prova na página vem do carrossel de clientes da Microsoft, então leia-os como publicados pelo fornecedor, e não como independentes. O mais forte: a Lenovo com uma redução de 20% no tempo de atendimento, a Lexmark com um aumento de 23% na produtividade da central de atendimento, e a Hype com uma taxa de resolução na primeira chamada de 90% com uma redução de 70% na intervenção do representante de atendimento. A própria implantação interna da Microsoft afirma 50% de economia no tempo de processo.

O posicionamento dos analistas é real. A Microsoft é uma Líder no Forrester Wave para Soluções de Atendimento ao Cliente, T1 de 2026, publicado em 11 de março de 2026, e uma Líder no Gartner Magic Quadrant de 2025 para o Centro de Engajamento com o Cliente de CRM, a mesma categoria em que a ServiceNow compete. Duas coisas vale notar assim mesmo. A própria interpretação da Microsoft sobre o posicionamento no Wave usa a frase "visão equivalente", uma linguagem inusitadamente cautelosa para dizer voluntariamente sobre si mesma. E o estudo de Impacto Econômico Total que ela promove é datado de março de 2024, dois anos antes da página em que ele aparece.

A conclusão: a resposta certa se o suporte é voltado ao cliente, o volume é real e a empresa já roda sobre o Dynamics. É a resposta errada para uma central de TI interna de 12 pessoas, onde a licença, o parceiro de implementação e o ciclo de vendas juntos custam mais do que o problema em si. Para essa escala, um sistema de tickets interno construído sobre uma central mais leve - Jira incluído - te leva mais rápido até lá.

Calcule quanto isso custaria de verdade

Preços de tabela escondem a forma da conta, então coloque seus próprios números.

Mude o número de assentos e as alternâncias para ver como as quatro rotas da Microsoft se classificam para sua equipe. O momento interessante é o ponto em que a construção própria deixa de ser a opção barata.

Executando com dez pessoas, a rota de construir você mesmo parece uma vitória fácil, a 350 $ por mês contra 500 $ do Dynamics Professional. Executando com dez pessoas com IA na fila, a diferença se estreita para 550 $ contra 700 $, por um sistema que ainda precisa de alguém da sua equipe para cuidar dele. Esses 150 $ por mês compram um trabalho de meio período que você não orçou.

O que as pessoas realmente dizem sobre rodar tickets na Microsoft

Para isso, li muitos tópicos do r/sysadmin e r/msp que remontam a 2020, incluindo bastante discussão sobre se um sistema de tickets gratuito vale a pena tentar antes de comprar qualquer coisa. Uma frase aparece em quase todos eles, e não é uma comparação de recursos.

"Ao longo da minha carreira, a frase 'por que não? temos as licenças' foi dita pelo menos uma vez por alguém em um cargo de negócios sênior (ou pelo gerente de projeto) para todos os projetos da minha lista dos dez piores projetos."

BrainWaveCC, Is Microsoft Dynamics 365 a viable ticketing system candidate?, Reddit

Esse é o motor da decisão, e vale a pena nomear isso, porque "já pagamos por ele" é um argumento sobre a fatura, não sobre a adequação. No mesmo tópico, alguém cuja empresa já havia se comprometido descreveu o resultado:

"Acabamos de iniciar um projeto usando o Dynamics como substituto do nosso sistema de tickets. Até agora não estamos impressionados. Mas nosso CIO seguiu adiante de qualquer forma porque tínhamos licenças para ele."

admlshake, Is Microsoft Dynamics 365 a viable ticketing system candidate?, Reddit

Os tópicos sobre Power Apps se dividem em uma linha mais clara, e a divisão é sobre quem mantém, e não sobre se funciona ou não. As pessoas que construíram o próprio relatam que ele roda bem por anos:

"Desenvolvi um sistema de tickets com Power Apps e um pouco de Power Automate (antes Flow). Todo o nosso banco de dados está no SharePoint Online. Está em produção desde novembro de 2019, funciona muito bem."

Neiviv2828, Building a ticketing system using the MS Power Platorm?, Reddit

Pessoas que herdaram um contam uma história bem diferente:

"Meu antecessor o usou para aprender a power platform. Ótimo... mas o problema é que existem uma dúzia de excelentes sistemas de tickets por aí, a maioria gratuitos até certo ponto, e que não são realmente caros de qualquer forma. Então o que ficamos foi uma porcaria cheia de bugs que faltava 90% dos recursos básicos que eu esperaria ver (e precisaria). Depois de uma semana lutando com ele, foi para a lixeira."

canadian_sysadmin, O365 ticketing, Reddit

Os dois relatos são verdadeiros ao mesmo tempo, o que é a parte útil de lê-los lado a lado. Uma fila caseira do Power Apps é um projeto pessoal que por acaso se tornou crítico para o negócio. Ela funciona exatamente enquanto seu autor ainda estiver lá.

O último tema é a escala, e os números que as pessoas dão são mais baixos do que você imaginaria. Um sysadmin que havia construído a versão de lista do SharePoint mais Power Automate, com notificações e destaque de SLA e tudo, encerrou seu relato com uma recomendação direta contra:

"Eu não recomendaria isso. 300 funcionários já são o suficiente para investir em uma central de atendimento DE VERDADE."

Ayy4K, O365 ticketing, Reddit

Como escolher de verdade

Tirando o licenciamento, tudo se reduz a quatro perguntas.

A fila é voltada ao cliente? Se for, pule as rotas um e dois e vá direto olhar um sistema de tickets baseado em nuvem adequado. Um limite de visualização de 5.000 itens e um atraso de polling de 60 segundos são problemas toleráveis internamente, e clientes não têm essa tolerância.

Você precisa medir isso? Se alguém vai pedir o tempo de primeira resposta, é o assento Enterprise de 105 $ ou uma central diferente. O nível de 50 $ não consegue responder a essa pergunta, e construir os relatórios você mesmo no Power BI adiciona outra licença. Essa mesma lacuna de medição é o motivo pelo qual a classificação de tickets precisa vir primeiro - você não pode reportar sobre uma categoria que nunca marcou.

Alguém é responsável pela construção? Um sistema de tickets em Power Apps vem com um mantenedor associado, seja ele nomeado ou não. Se a resposta for "nosso gerente de TI vai fazer isso ao lado do trabalho dele", o custo real é maior do que a licença.

A IA é o motivo real pelo qual você está comprando? Essa é a que costuma ser mal escopada com mais frequência. Equipes vão procurar um novo sistema de tickets quando o objetivo real é fazer menos tickets chegarem a um humano. Migrar de plataforma para conseguir IA é a forma mais cara de comprar IA, e é por isso que meu guia de IA para central de ajuda de TI defende adicionar camadas em vez de trocar quase sempre. Se sua equipe já está profundamente inserida na Microsoft, o movimento mais rápido geralmente é automatizar o suporte do Microsoft Teams por cima da fila que você já tem.

Vale a pena dizer isso claramente: nada disso torna a Microsoft uma escolha ruim. O Dynamics 365 é um produto sério com reconhecimento real de analistas, e o Power Platform de fato consegue construir coisas que uma central de ajuda empacotada não consegue. O modo de falha não é escolher a Microsoft. É escolher a rota barata da Microsoft para um problema que precisava da cara, e depois encontrar a lacuna nos 3.000 itens de lista. Leia minha análise mais ampla sobre ticketing de TI automatizado se você ainda estiver decidindo qual caminho combina com você.

eesel para uma fila de tickets da Microsoft

Se a desviação é o motivo pelo qual você está lendo isso, e não uma central nova, você provavelmente não precisa migrar de plataforma alguma.

A eesel é uma camada de IA que se conecta à central e à documentação que você já usa - sua base de conhecimento interna incluída. Ela lê o Microsoft Teams, SharePoint, Confluence e seus tickets existentes, redige ou envia respostas na ferramenta em que sua equipe já está, e entra em produção em minutos em vez de em um trimestre de implementação. Duas coisas importam especificamente contra as rotas da Microsoft acima. Ela cobra por ticket, não por crédito, então o número que você leva para o financeiro é um número que você consegue prever. E cada lançamento é simulado primeiro contra seus tickets históricos, então você vê o que ela teria respondido, e o quão bem, antes de tocar em uma fila ao vivo. Eu construí isso porque já vi um bot que soa confiante dar respostas erradas silenciosamente, e uma vez já é suficiente.

A central de TI interna de uma fintech, rodando sobre o Jira Service Management com Confluence e Slack por trás, colocou a eesel como a primeira respondedora na fila da sua central de ajuda. A desviação subiu para 15% no caminho para uma meta de 55%. O chefe de TI deles colocou assim:

"Nós a usamos para ser a primeira respondedora dos nossos tickets de central de ajuda no Jira. Ela essencialmente age exatamente como um agente agiria."

Jason Loyola, Head of IT na InDebted

Esse é o mesmo tipo de trabalho que uma central de TI baseada em stack Microsoft está tentando fazer quando coloca IA em uma central de ajuda interna em vez de um agente do Copilot Studio, menos as contas de créditos. Grátis para testar, e a configuração leva aproximadamente o mesmo tempo que ler este post.

Onde isso te deixa

Não existe um sistema de tickets da Microsoft. Existe um CRM de 50 a 195 $ chamado Dynamics 365 Customer Service, e um kit de construção chamado Power Platform. A decisão interessante é qual dos dois seu problema realmente merece.

As cinco rotas são reais, e estão ordenadas. Caixa de entrada compartilhada até duas pessoas colidirem. SharePoint e Power Automate até 3.000 itens. Power Apps quando o fluxo de trabalho é realmente seu e alguém é o responsável. Copilot Studio quando o objetivo é a desviação. Dynamics quando suporte é o negócio.

A única coisa que eu não faria é comprar o assento e assumir que a IA vinha incluída. No Professional e no Enterprise ela não vem. Ela é medida em uma unidade cujo custo por ticket a Microsoft não publica, e precisa de uma assinatura do Azure conectada antes de funcionar. Qualquer que seja a rota que você escolher, avalie o preço desse medidor antes de assinar, não depois.