A emissão de tickets parece limpa no palco. Você obtém os números, as filas, os painéis. Mas, na realidade, esse modelo só mede a dor depois que o sistema já falhou. A parte cara do problema geralmente começa muito antes. Começa quando o funcionário perde 10 minutos, depois 20 e eventualmente desiste. Ele tem novamente. Ele perde o trabalho. Ele perde a reunião ou compartilha o arquivo errado porque o caminho certo parou de funcionar. E essa é a parte que a maioria das equipes de suporte ainda não vê. O melhor modelo de suporte interno hoje não tem a ver com triagem mais rápida. Tem a ver com eliminar completamente necessidades de triagem. Imagine um agente autônomo dentro do Microsoft 365 que observa o contexto, identifica atritos precocemente e age antes que uma pessoa sequer pense em abrir um portal. Neste episódio, quero mostrar por que o modelo de Helpdesk falha. O que realmente o substitui e como você pode administrá-lo sem criar caos.

Se essa mudança for importante para o seu trabalho, assine o M365-FM. Porque é um nível mais profundo, o problema real não é a fila, é o modelo por trás dela. A morte do ticket. O antigo fluxo de suporte ainda está em todo lugar. Algo quebra. Um usuário percebe. O usuário tenta explicar. Então, a TI traduz essa explicação em uma categoria, uma prioridade e talvez um grupo de atribuição. O problema entra em uma fila. Alguém o classifica. Outra pessoa pede mais detalhes. Outra equipe se envolve. O tempo segue passando enquanto o trabalho real continua a parar. Esse processo parece normal porque é familiar, mas familiar e eficaz não são a mesma coisa. Um ticket não é suporte. Um ticket é a evidência de que o suporte chegou a atrasar. No momento em que um ticket sequer existe, o funcionário já encontrou o atrito e perdeu o contexto. Ele já desviou sua atenção do trabalho que estava tentando fazer.

A fila não é o serviço. A fila registra falhas. Em grandes ambientes, Microsoft 365, a triagem manual vira o real ponto crítico. Isso não acontece porque as equipes de suporte são preguiçosas. Acontece porque as pessoas estão sendo solicitadas a fazer algo que não se encaixa mais na escala do ambiente. Você tem mais usuários, mais dispositivos, mais aplicativos, mais políticas. Você tem mais casos extremos cruzando equipes. SharePoint, Exchange, Intune e entra ao mesmo tempo. O volume não cresce apenas. As combinações crescem. É aí que o modelo antigo falha. A maioria das equipes responde adicionando mais estruturas. Elas criam outro portal, outro bot ou outra regra de roteamento. Mas, na realidade, isso apenas adiciona mais uma camada entre o funcionário e a resolução. O sistema ainda está esperando o usuário perceber o problema, descrevê-lo e pedir ajuda da maneira certa. O trabalhão começa em um portal de suporte.

Ele começa no Teams, no Outlook, em um documento de que alguém precisa agora. Ou em uma reunião que começa em 30 segundos. É aí que a demanda de suporte realmente começa. O modelo de emissão de tíquetes é completamente desvinculado desse momento. O custo oculto é muito maior do que se o relatório de fila mostra. As pessoas entram acentram. Incidentes duplicados se acumulam em um sub-roll diferente. Artigos de conhecimento ficam absurdos. Analistas passam o dia inteiro classificando, roteando, esclarecendo em vez de realmente consertar as coisas. O tempo para a resolução se estende, porque cada transferência adiciona um atraso. E cada atraso elimina o contexto original. Pesquisas sobre ar de agente e operações de TI apontam para o mesmo programa estrutural. Pelo menos 80% do esforço ainda está preso em trabalho reativo no estilo etio. Esse número é importante porque informa exatamente para onde o trabalho está.

Não está indo para resiliência ou prevenção, está indo para reação. Depois que você vê isso, o tíquetes começa a se parecer menos com o modelo operacional e mais com sintoma. É um sintoma de um sistema que só responde depois que o dano é visível. Portanto, a próxima pergunta não é como processar tíquetes mais rápido. É o que o sistema deve fazer antes que um tíquetes seja necessário. O modelo de funcionário invisível. Então o que realmente substitui o tíquet? Não é apenas mais um chatbot em cima da mesma bagunça. E certamente não é uma porta de entrada mais bonita para mesmo haver a fila. A mudança é muito mais profunda do que isso porque o funcionário invisível é um trabalhador operacional que vive dentro do seu ambiente Microsoft 365. E se a gente tem identidade própria, escopo de trabalho definido, memória do que fez ontem e regras rígidas sobre o que pode ou não tocar e regras rígidas sobre o que pode ou não tocar.

Essa distinção é importante. Um chatbot espera que você digite um prompt, mas um funcionário invisível observe as condições mudarem. Ele começa pelo contexto, em vez de começar por uma conversa. Por conseguir ver estados de login, integridade do dispositivo, status da licença e o compartilhamento de arquivos, não precisa esperar o atrito surgir. Em vez de perguntar como pode ajudar depois que algo quebra, ele faz constantemente uma pergunta diferente em segundo plano. O que está se afastando do estado de que esse funcionário precisa para fazer seu trabalho agora? É aí que as coisas mudam. O modelo é incorporado diretamente no próprio trabalho. Quando alguém entra em uma reunião e o áudio falha, ou um convidado não consegue abrir um arquivo recém-enviado, o velho mundo cria um relatório e transfere. No novo modelo, a gente vê o padrão imediatamente, verifica se a condição corresponde a um problema conhecido e se executa a próxima ação segura para corrigi-lo.

Talvez ele redefine um caminho, acione uma verificação de política ou redirecione uma solicitação e peça a MFA antes de documentar o ajuste. O ponto é simples. A primeira resposta não requer mais que um humano leia uma descrição vaga e adivinha o que aconteceu. Isso parece invisível quando funciona bem, porque não há sala de espera nem formulário. Selecione uma categoria para preencher, para preencher. O suporte aparece como fluxo a restaurar. O funcionário simplesmente volta ao trabalho, em muitos casos nem vê o maquinário funcionando nos bastidores. Você já pode ver como isso muda a sua lógica de equipe. O modelo antigo contrata pessoas para absorver o volume, classificar solicitações e limpar contextos quebrados entre diferentes equipes. O novo modelo precisa de menos pessoas fazendo triagem e mais pessoas projetando proteções, definindo estados desejados e supervisionando como esses agentes se comportam ao longo do tempo.

Os humanos permanecem no sistema, mas todo o formato de seu trabalho diário muda. Pesquisa sobre a de agente no suporte continua apontando nessa direção. O suporte de rotina pode avançar para o tratamento baseado em exceções, o que cria ganhos de eficiência enormes quando o ambiente e as políticas são bem delimitados. Essa última parte é vital porque não é mágica. Se seus dados forem fracos ou seu processo for confuso, o agente não se tornará inteligente só porque você decidiu chamá-lo de autônomo. Tudo isso fez sentido para mim quando parei de pensar no agente como um recurso de software e comecei a vê-lo como um funcionário não humano com um crachá. Um trabalhador real precisa de uma identidade, descrição de cargo, permissões e um gestor a reportar. O agente precisa exatamente dessas mesmas coisas porque o valor vem de uma ação confiável dentro de um sistema, não de uma linguagem inteligente e uma janela bate-papo.

O funcionário invisível não é truque de interface. É uma nova camada de suporte que observa o atrito em todo o conjunto do Microsoft 365, age de acordo com a política e direciona a atenção humana para as exceções que realmente precisam de julgamento. Depois que esse modelo ficar claro, a próxima pergunta se torna muito prática. Como a preempção realmente funciona? A arquitetura da preempção. Então, como a preempção realmente funciona dentro do Microsoft 365? A mudança passa de solicitação e resposta para raciocínio e orquestração de eventos. Isso parece técnico, mas o modelo é simples depois que você o desmembra. Primeiro, algo no ambiente muda, depois o sistema interpreta se essa mudança significa risco ou desvio. E por fim, toma a ação aprovada usando as ferramentas já existentes em sua pilha. Comece com a camada de eventos. O Microsoft 365 já produz sinais em toda parte. O Enter observa o comportamento de login enquanto o Intune rastreia a postura e conformidade do dispositivo.

O Defender observa atividades suspeitas e o Teams mostra exatamente quando uma reunião falha ou a qualidade da chamada cai. O SharePoint e o Exchange expõem padrões de acesso e atividade de conteúdo, enquanto sinais de integridade do serviço informam quando a plataforma isso é o problema. Quando você adiciona ações do usuário a isso, tem um fluxo constante de contexto. A maioria das organizações coleta sinais, mas muito poucas realmente os usam como sistema de suporte. Eventos brutos por si só não ajudam porque precisam de uma camada de raciocínio para dar sentido ao ruído. É aqui que o funcionário invisível deixa de ser um teatro de automação e começa a agir como operador real. O agente analisa o sinal, compara o estado atual com o estado desejado e decide qual classe de ação é segura a tomar. Um problema de áudio não é o mesmo que um login arriscado e um link quebrado é diferente de uma incompatibilidade de licença.

O agente precisa classificar o problema primeiro, pois agir sem classificação só cria erros mais rápido. Em seguida vem a orquestração. Depois que o agente entende o problema, ele pode usar o mecanismo certo para responder. Pode ser o Power Automate para fluxo de trabalho, o Pilot Studio para lógica ou o Microsoft Graph para ações e contextos do sistema. As ferramentas importam, mas o que conta é como elas se conectam entre si. Você não está criando um prompt inteligente, mas sim uma cadeia que pode detectar, decidir, agir e verificar. Essa última parte é perdida o tempo. Um sistema de autocorreção não para depois que a ação é tomada. Ele executa um loop no qual detecta o problema, testa a condição, aplica a correção e verifica o resultado antes de registrar o que aconteceu. Pesquisas sobre lógica de autocorreção deixam claro que esses temas funcionam por meio de padrões de feedback e correção em vez de uma resposta isolada de um modelo de linguagem.

Se a primeira ação falhar, o sistema precisa avaliar o motivo para revisar a próxima etapa, mantendo-se sempre dentro dos limites definidos. Você pode imaginar isso claramente em alguns casos do Microsoft 365. Quando um usuário é bloqueado porque sua licença e escopo de política não correspondem, o agente detecta a incompatibilidade e verifica o perfil de função pretendido. Ele aplica a correção permitida. Confirma se o usuário tem acesso e registra a alteração sem que ninguém pergunte. Se um login arriscado aparecer no Entra, o agente verá o evento de risco e verificará suas regras de acesso condicional imediatamente. Ele solicita uma verificação mais forte ou bloqueia o acesso conforme sua política, registrando o resultado para a revisão humana posterior. Quando um link de compartilhamento obsoleto falha no SharePoint, o agente compara o caminho de permissão atual com as regras de compartilhamento.

Ele substitui a raiz quebrada pela aprovada e envia o link corrigido no contexto, o que fecha o ciclo antes que um analista de mesa precise ler um ticket intitulado Problema de Acesso Urgente. Suporte e reunião é outro ótimo exemplo. Se um dispositivo de sala falhar ou a conexão for interrompida instantes antes da chamada, o agente detecta a condição e valida a falha. Ele tenta uma recuperação de baixo risco e avisa o organizador no Teams atualizando o status onde o trabalho acontece. Essa camada de comunicação é uma parte importante do design. O suporte precisa estar onde a interrupção acontece. Se seu trabalho acontece no Teams, Outlook e no espaço de trabalho do M365, o suporte também deve responder você lá. Você não deve ter que arrastar o usuário para outro lugar quando pode atender o evento no contexto. Nada disso significa realizar todas as tarefas individualmente, porque isso seria imprudente.

Ações de baixo risco rodam automaticamente, mas mudanças de alto impacto ainda exigem aprovação humana. Esse caminho de aprovação precisa fazer parte da arquitetura desde o início em vez de ser adicionado posteriormente. A gente deve saber quando agir, quando perguntar e exatamente quando parar. E depois que você incorpora isso ao fluxo, a conversa deixa de ser sobre recursos de automação. Passa a ser sobre controle, governança, confiança e identidade do agente. Quando o suporte começa a agir por conta própria, uma pergunta difícil surge imediatamente. Quem está realmente fazendo o trabalho? Se essa resposta for vaga, todo modelo desmorona. Um agente não pode existir em seu ambiente como um auxiliar impreciso com amplo acesso e nenhum proprietário claro. Ele precisa de uma identidade real no ENTER. Precisa de um responsável definido, um escopo claro e um ciclo de vida que começa e termina por um motivo real.

Se esse agente pode ler dados, acionar fluxos de trabalho ou enviar mensagens aos seus usuários, você precisa governá-lo como um participante ativo no locatário. Você não pode tratá-lo como um recurso que alguém ativou e depois esqueceu. Por isso que a identidade do agente é tão crítica para o sistema. Você precisa saber exatamente o que é o agente, quais sistemas ele pode tocar e quem recebe a chamada quando as coisas começam a mudar. O privilégio mínimo deve ser a linha de base aqui. Você não pode se contentar com ampla conveniência ou dizer a si mesmo que restringirá as permissões mais tarde. Como o raio de ação de um agente de suporte depende inteiramente de suas permissões? Projetar essas permissões é uma parte essencial do design do suporte. O Aging 365 atua como uma camada de controle necessária nessa configuração porque coloca todo o patrimônio do agente em uma visão clara. Ele fornece o registro, os fluxos de trabalho e aprovação e os modelos de política e mantém tudo funcionando com segurança.

Embora essas peças possam soar como tarefas administrativas, elas resolvem uma norma estrutural. A maioria das organizações não tem dificuldades porque não têm recursos de ar, mas porque não conseguem ver ou controlar o que já está em execução em seu ambiente. A pesquisa sobre esse ponto é direta. Apenas uma pequena minoria de grandes empresas consegue inventariar completamente todos os agentes em execução no sistema. Antes de falar em escalar o suporte autônomo, os líderes precisam responder a uma pergunta bem mais simples. Sabemos mesmo quais agentes existem e o que estão fazendo agora? A supervisão também precisa corresponder ao nível de risco envolvido. Um agente de produtividade pessoal trabalhando em uma via estreita é uma coisa, mas um agente colaborativo lidando com conteúdo compartilhado com um tamanho diferente. Então você tem agentes corporativos agindo em fluxo de trabalho confidenciais, o que se enquadra em uma categoria diferente de risco.

Por isso que o modelo de zona de risco pessoal colaborativo e empresarial é tão importante. Seu modelo de controle deve crescer junto com o possível impacto. Se você tratar todos os agentes da mesma forma, o trabalho de baixo risco ficará travado em aprovações lentas e o de alto risco passará sem escutínio. No mínimo, sua pilha de controle no Microsoft 365 deve parecer familiar para sua equipe. Eu uso identidade no Entra, limites de dados por meio do Purview e monitoramento por meio do Defender. Você aplica condições de acesso por meio de acesso condicional e garante que a auditabilidade seja incorporada desde o início. Você precisa ser capaz de reconstruir exatamente o que aconteceu sem ter que adivinhar depois que um incidente ocorre. A supervisão humana precisa ser projetada na lógica em vez de improvisada durante uma crise. Ações de alto impacto devem sempre pausar para uma assinatura humana.

O raciocínio deve ser registrado em um formulário que as pessoas possam realmente inspecionar e entender. Você precisa que existam caminhos de reversão antes que a primeira ação autônoma entre em vigor. Se um agente atualizar o acesso ou mudar uma política de roteamento, alguém precisará rastrear essa decisão e desfazê-la, limpidamente. Há outro fator que líderes ignoram, pois as demonstrações iniciais parecem excelentes. O custo do retrabalho. Se um agente cria ciclos de limpeza para sua equipe, a economia projetada desaparece instantaneamente. Esse é o imposto de retrabalho. É o tempo gasto corrigindo resultados ruins, revertendo ações erradas ou perseguindo efeitos colaterais indesejados. Se sua equipe economiza 10 minutos na execução, mas gasta 8 minutos limpando a bagunça, você não automatizou o suporte de fato. Você apenas moveu o atrito para uma parte diferente do processo. A confiança não vem de um conjunto político expolido ou de um grande anúncio de lançamento.

Ela vem de evidências em tempo de execução. As pessoas precisam ver o que o agente viu, o que ele decidiu e o que realmente mudou no sistema. É assim que você constrói confiança no suporte autônomo. A prova tem que estar no comportamento da ferramenta e não na marca do projeto. Uma vez que essa base de governança esteja sólida, a conversa pode finalmente deixar de lado o jargão de segurança e passar para a linguagem executiva. O que isso realmente muda no resultado final? O novo ROI do suporte invisível. Uma vez que os líderes aceitam o modelo de controle, as questões financeiras começam a mudar. No modelo antigo, o valor do suporte é medido pelo trabalho visível, como tickets fechados, chamadas atendidas e desempenho do SLA. Esses números ainda importam, mas descrevem apenas uma reação ao problema. Eles não informam quanta interrupção não chegou à fila, quanto tempo o funcionário permaneceu intacto porque um problema foi resolvido precocemente.

Esse é o principal problema da contabilidade. O suporte invisível cria valor por meio da ausência. Você vê o valor quando no ticket não há escalonamento e nenhum analista gastando 20 minutos reconstruindo um problema a partir de notas incompletas. Se você medir apenas o esforço visível da equipe de suporte, não atingirá o resultado que realmente queria. Você cria um trabalho estável com menos interrupções. O volume de tickets é um sinal fraco quando se sustenta sozinho. Uma queda nos tickets pode indicar a demanda menor, mas também que o ambiente está mais saudável e a nossa camada de suporte mais inteligente. Essas são duas histórias muito diferentes. Os executivos precisam de um conjunto de KPIs que possam diferenciar entre eles. Você deve começar observando a taxa de resolução autônoma. Não se trata de quantas conversas o bot teve, mas de quantos eventos de suporte foram resolvidos de ponta a ponta sem que o humano sequer os tocasse.

Você também precisa monitorar a redução no tempo médio de resolução. Em ambientes orientados por IA, fluxos diagnósticos frequentemente apresentam melhorias na faixa de 40% a 60%. Em seguida, você pode analisar o custo por resolução e a produtividade do usuário recuperado. É fácil ignorar essa última métrica, pois ela não se encaixa bem em um relatório padrão da central. No entanto, é geralmente aí que reside o valor real. Uma pessoa que fica bloqueada por 15 minutos antes mesmo de abrir um ticket já criou um custo para a empresa. Quando você multiplica isso por interrupções de reunião e atrito de acesso em um grande inquilino, a peda oculta é muito maior do que a fila sugere. Por isso que o modelo de custo da inação é tão importante por causa de negócios. Você calcula as horas gastas em esforço manual antes mesmo de o suporte formal começar. Em seguida, adiciona o custo de erros e trabalha repetido.

De repente, o argumento para preempção deixa de soar como uma teoria. Você não está apenas financiando uma camada de suporte futurista. Você está removendo um imposto que está parado em seu trabalho diário há anos. A economia do caso específico deixa isso ainda mais claro. Estudo sobre suporte de TI agêntico citou um atendimento humano em US$8,75 por caso. Em contraste, o manuseio agêntico restrito pode custar menos de 50 centavos por caso após o sistema pronto. Isso não significa que todas as ações de suporte serão tão baratas, e os líderes devem ter cuidado com as médias amplas. A qualidade e a governança da telemetria sempre afetarão o custo final, mas a direção da tendência é inconfundível. Este é o momento em que a TI sai da velha história do centro de custo. Não é porque o suporte desaparece, mas porque o suporte se transforma em uma camada de confiabilidade que protege a produtividade dos funcionários em segundo plano.

Empresa sente isso como um trabalho mais tranquilo em vez de um evento de suporte dramático. Você obtém menos interrupção em restauração mais rápido e menos trabalho desperdiçado em roteamento e esclarecimento. Contudo, uma medição ruim pode facilmente forjar progresso. Se sua telemetria for fraca, a gente pode apenas resumir uma falha mais rápida em vez de realmente evitá-la. Se o retrabalho não for incluído no painel, o ROI parecerá muito mais limpo do que realmente é. Se o tempo recuperado simplesmente vazar para atividades de baixo valor, os líderes exagerarão o ganho. O caso financeiro deve permanecer fundamentado em evidências concretas como incidentes evitados e menos toxímono. Você precisa mensurar o tempo realmente devolvido ao trabalho útil. Depois de mensurar isso corretamente, a função de suporte deixa de parecer uma despesa indireta que precisa ser cortada. Começa a aparecer uma capacidade operacional que a empresa finalmente recupera.

O que isso faz com a equipe de suporte? Pense no que isso realmente faz com a equipe em campo, porque essa mudança não tem a ver com cortar pessoal, mas sim com mudar o que seu pessoal realmente faz com o dia. Na estrutura antiga, grande parte da capacidade de suporte é consumida por redefinições de senha, roteamento e ciclos de esclarecimento e ciclos de esclarecimento. Você tem pessoas buscando atualizações e movendo dados entre sistemas que nunca foram projetados para se comunicarem. Nenhum desses trabalhos torna o ambiente mais estável, apenas evita que a fila fique lotada. Quando os agentes assumem esse trabalho de rotina previsível, o esforço humano finalmente sobe um nível. Os engenheiros de suporte começam a dedicar seu tempo definindo como é um estado saudável e ajustando a lógica por trás das aprovações. Eles focam em melhorar fontes de conhecimento, testar comportamentos de políticas e garantir que o agente siga os limites que lhe foram dados.

Esse trabalho é bem diferente de encarar linhas de assunto o dia todo e tentar adivinhar o que um usuário deseja de verdade. É exatamente aqui que a maioria das implantações para. As organizações tentam manter seus antigos processos ineficazes colocando um agente no topo e esperando um resultado melhor. Mas o processo ainda é reativo, as transferências ainda são confusas e o conhecimento subjacente ainda é fraco. O agente se torna apenas mais uma camada de tinta em uma parede em ruínas. Pode responder mais rápido, mas não conserta um modelo de suporte que foi criado à base de atrasos. A melhor maneira é redesenhar o trabalho primeiro. Você precisa decidir quais tarefas permanecem humanas porque exigem julgamento ou comunicação sensível. Em seguida, você decide qual trabalho passa para fluxos autônomos porque o resultado é previsível e as ações são seguras. Essa divisão é vital porque as equipes de suporte não vão embora.

Elas estão apenas se tornando as pessoas que projetam os controles e lidam com as exceções. Isso significa que a forma como treinamos as pessoas também muda. As equipes precisam aprender a supervisionar um sistema em vez de apenas executar uma tarefa manual. Elas precisam entender a lógica de reversão, as revisões de auditoria e como testar um agente antes de ir ao ar. Elas precisam detectar quando o modelo falha, pois um fluxo de trabalho automatizado ruim continua sendo um fluxo ruim. Ele apenas interrompe as coisas mais raras. Se você está contratando para esse futuro, talvez não precise de outro generalista para ter atíquets. Você precisa de alguém que possa orquestrar fluxos em todo o conjunto Microsoft 365 e definir os controles que mantêm os agentes sob controle. Você quer pessoas que possam melhorar o ambiente para que a demanda de suporte realmente diminua, em vez de apenas se acumular.

Então, como você realmente começa isso sem que se transforme em um grande projeto de transformação de vários anos? A melhor opção é escolher um único fluxo que cause atrito constante dentro do seu ambiente do Microsoft 365. A correção de acesso geralmente é uma ótima opção, mas você também pode considerar a reunião de suporte ou transferências de conformidade de dispositivos. Não importa qual você escolher, desde que o padrão aconteça com frequência e você saiba exatamente como deve ser o resultado bem-sucedido. Depois de definir a meta, você precisa definir o básico com disciplina real. Você precisa saber o que é saudável e quais eventos específicos indicam que as coisas estão saindo dos trilhos. Decida quais ações são seguras para automatizar e exatamente onde a escalada humana precisa começar. Antes de colocar algo em produção, estabeleça uma base para contagens de tickets, toques manuais e o tempo que usuários aguardam por uma correção atual.

Você também precisa implementar sua governança no primeiro dia. Dê ao agente uma identidade específica, atribua um responsável humano a ela e defina regras de aprovação claras. Cada ação realizada pelo agente precisa ser registrada. Você também deve ter um plano para quando esse agente for aposentado ou realocado para que não se torne apenas uma automação fantasma. Quando esse primeiro fluxo começar a funcionar, todo o seu modelo operacional começará a mudar. O suporte para de agir como uma recepção que apenas reage aos problemas. Em vez disso, ele começa a se comportar como um mecanismo de confiabilidade integrado diretamente ao sistema. O suporte está mudando de uma reação visível para uma prevenção incorporada. O ticket nunca foi o serviço. Foi a prova de que o serviço apareceu tarde demais. Escolha um fluxo de suporte neste trimestre e redesenvolva-o para prevenção em vez de resposta.

Se quiser saber mais sobre o M365 Copilot, Azure Segurança e modelos operacionais de IA, inscreva-se no M360 FM e deixe uma avaliação. Conecte-se comigo, Mercopeter, no LinkedIn com o próximo tópico que você quer abordar. E aí