WEBVTT

00:00:00.000 --> 00:00:01.320
A emissão de tickets parece limpa no palco.

00:00:01.620 --> 00:00:03.420
Você obtém os números, as filas, os painéis.

00:00:04.240 --> 00:00:07.680
Mas, na realidade, esse modelo só mede a dor depois que o sistema já falhou.

00:00:08.380 --> 00:00:10.580
A parte cara do problema geralmente começa muito antes.

00:00:11.100 --> 00:00:14.340
Começa quando o funcionário perde 10 minutos, depois 20 e eventualmente desiste.

00:00:14.660 --> 00:00:15.120
Ele tem novamente.

00:00:15.460 --> 00:00:16.140
Ele perde o trabalho.

00:00:16.540 --> 00:00:19.660
Ele perde a reunião ou compartilha o arquivo errado porque o caminho certo parou de funcionar.

00:00:20.060 --> 00:00:22.180
E essa é a parte que a maioria das equipes de suporte ainda não vê.

00:00:22.700 --> 00:00:25.460
O melhor modelo de suporte interno hoje não tem a ver com triagem mais rápida.

00:00:25.920 --> 00:00:27.800
Tem a ver com eliminar completamente necessidades de triagem.

00:00:27.800 --> 00:00:32.600
Imagine um agente autônomo dentro do Microsoft 365 que observa o contexto,

00:00:32.720 --> 00:00:36.000
identifica atritos precocemente e age antes que uma pessoa sequer pense em abrir um portal.

00:00:37.600 --> 00:00:40.300
Neste episódio, quero mostrar por que o modelo de Helpdesk falha.

00:00:40.580 --> 00:00:43.640
O que realmente o substitui e como você pode administrá-lo sem criar caos.

00:00:44.460 --> 00:00:47.600
Se essa mudança for importante para o seu trabalho, assine o M365-FM.

00:00:47.900 --> 00:00:51.100
Porque é um nível mais profundo, o problema real não é a fila, é o modelo por trás dela.

00:00:52.040 --> 00:00:52.860
A morte do ticket.

00:00:53.380 --> 00:00:55.160
O antigo fluxo de suporte ainda está em todo lugar.

00:00:55.480 --> 00:00:55.920
Algo quebra.

00:00:56.340 --> 00:00:57.180
Um usuário percebe.

00:00:57.180 --> 00:00:58.460
O usuário tenta explicar.

00:00:59.020 --> 00:01:03.480
Então, a TI traduz essa explicação em uma categoria, uma prioridade e talvez um grupo de atribuição.

00:01:04.200 --> 00:01:05.240
O problema entra em uma fila.

00:01:05.600 --> 00:01:06.240
Alguém o classifica.

00:01:06.800 --> 00:01:07.840
Outra pessoa pede mais detalhes.

00:01:08.220 --> 00:01:09.020
Outra equipe se envolve.

00:01:09.540 --> 00:01:11.500
O tempo segue passando enquanto o trabalho real continua a parar.

00:01:11.960 --> 00:01:16.000
Esse processo parece normal porque é familiar, mas familiar e eficaz não são a mesma coisa.

00:01:16.780 --> 00:01:17.520
Um ticket não é suporte.

00:01:17.940 --> 00:01:19.780
Um ticket é a evidência de que o suporte chegou a atrasar.

00:01:20.260 --> 00:01:23.820
No momento em que um ticket sequer existe, o funcionário já encontrou o atrito e perdeu o contexto.

00:01:23.820 --> 00:01:27.440
Ele já desviou sua atenção do trabalho que estava tentando fazer.

00:01:28.040 --> 00:01:28.840
A fila não é o serviço.

00:01:29.300 --> 00:01:30.220
A fila registra falhas.

00:01:30.220 --> 00:01:34.400
Em grandes ambientes, Microsoft 365, a triagem manual vira o real ponto crítico.

00:01:34.880 --> 00:01:36.740
Isso não acontece porque as equipes de suporte são preguiçosas.

00:01:37.180 --> 00:01:40.960
Acontece porque as pessoas estão sendo solicitadas a fazer algo que não se encaixa mais na escala do ambiente.

00:01:41.440 --> 00:01:43.860
Você tem mais usuários, mais dispositivos, mais aplicativos, mais políticas.

00:01:44.460 --> 00:01:46.600
Você tem mais casos extremos cruzando equipes.

00:01:46.700 --> 00:01:49.340
SharePoint, Exchange, Intune e entra ao mesmo tempo.

00:01:50.160 --> 00:01:51.160
O volume não cresce apenas.

00:01:51.440 --> 00:01:52.400
As combinações crescem.

00:01:52.880 --> 00:01:53.920
É aí que o modelo antigo falha.

00:01:54.460 --> 00:01:56.360
A maioria das equipes responde adicionando mais estruturas.

00:01:56.360 --> 00:01:59.220
Elas criam outro portal, outro bot ou outra regra de roteamento.

00:01:59.780 --> 00:02:03.240
Mas, na realidade, isso apenas adiciona mais uma camada entre o funcionário e a resolução.

00:02:03.940 --> 00:02:08.740
O sistema ainda está esperando o usuário perceber o problema, descrevê-lo e pedir ajuda da maneira certa.

00:02:09.560 --> 00:02:11.200
O trabalhão começa em um portal de suporte.

00:02:11.320 --> 00:02:14.780
Ele começa no Teams, no Outlook, em um documento de que alguém precisa agora.

00:02:15.020 --> 00:02:16.960
Ou em uma reunião que começa em 30 segundos.

00:02:17.740 --> 00:02:19.340
É aí que a demanda de suporte realmente começa.

00:02:19.620 --> 00:02:21.980
O modelo de emissão de tíquetes é completamente desvinculado desse momento.

00:02:22.540 --> 00:02:24.880
O custo oculto é muito maior do que se o relatório de fila mostra.

00:02:24.880 --> 00:02:26.220
As pessoas entram acentram.

00:02:26.720 --> 00:02:28.620
Incidentes duplicados se acumulam em um sub-roll diferente.

00:02:29.060 --> 00:02:30.600
Artigos de conhecimento ficam absurdos.

00:02:30.840 --> 00:02:34.600
Analistas passam o dia inteiro classificando, roteando, esclarecendo em vez de realmente consertar as coisas.

00:02:35.400 --> 00:02:38.900
O tempo para a resolução se estende, porque cada transferência adiciona um atraso.

00:02:39.080 --> 00:02:41.040
E cada atraso elimina o contexto original.

00:02:41.640 --> 00:02:44.760
Pesquisas sobre ar de agente e operações de TI apontam para o mesmo programa estrutural.

00:02:45.360 --> 00:02:48.640
Pelo menos 80% do esforço ainda está preso em trabalho reativo no estilo etio.

00:02:49.180 --> 00:02:51.720
Esse número é importante porque informa exatamente para onde o trabalho está.

00:02:51.720 --> 00:02:54.980
Não está indo para resiliência ou prevenção, está indo para reação.

00:02:55.480 --> 00:02:59.440
Depois que você vê isso, o tíquetes começa a se parecer menos com o modelo operacional e mais com sintoma.

00:02:59.540 --> 00:03:02.220
É um sintoma de um sistema que só responde depois que o dano é visível.

00:03:02.900 --> 00:03:05.140
Portanto, a próxima pergunta não é como processar tíquetes mais rápido.

00:03:05.200 --> 00:03:07.280
É o que o sistema deve fazer antes que um tíquetes seja necessário.

00:03:08.280 --> 00:03:09.400
O modelo de funcionário invisível.

00:03:09.840 --> 00:03:11.060
Então o que realmente substitui o tíquet?

00:03:11.500 --> 00:03:14.020
Não é apenas mais um chatbot em cima da mesma bagunça.

00:03:14.220 --> 00:03:16.700
E certamente não é uma porta de entrada mais bonita para mesmo haver a fila.

00:03:16.700 --> 00:03:21.000
A mudança é muito mais profunda do que isso porque o funcionário invisível é um trabalhador operacional

00:03:21.000 --> 00:03:23.240
que vive dentro do seu ambiente Microsoft 365.

00:03:23.640 --> 00:03:26.940
E se a gente tem identidade própria, escopo de trabalho definido, memória do que fez ontem

00:03:26.940 --> 00:03:31.060
e regras rígidas sobre o que pode ou não tocar e regras rígidas sobre o que pode ou não tocar.

00:03:31.340 --> 00:03:32.180
Essa distinção é importante.

00:03:32.760 --> 00:03:36.660
Um chatbot espera que você digite um prompt, mas um funcionário invisível observe as condições mudarem.

00:03:37.080 --> 00:03:39.660
Ele começa pelo contexto, em vez de começar por uma conversa.

00:03:40.300 --> 00:03:44.660
Por conseguir ver estados de login, integridade do dispositivo, status da licença e o compartilhamento de arquivos,

00:03:44.660 --> 00:03:46.060
não precisa esperar o atrito surgir.

00:03:46.700 --> 00:03:49.020
Em vez de perguntar como pode ajudar depois que algo quebra,

00:03:49.280 --> 00:03:51.480
ele faz constantemente uma pergunta diferente em segundo plano.

00:03:51.920 --> 00:03:55.300
O que está se afastando do estado de que esse funcionário precisa para fazer seu trabalho agora?

00:03:56.040 --> 00:03:57.040
É aí que as coisas mudam.

00:03:57.480 --> 00:03:59.520
O modelo é incorporado diretamente no próprio trabalho.

00:04:00.400 --> 00:04:02.620
Quando alguém entra em uma reunião e o áudio falha,

00:04:02.760 --> 00:04:05.540
ou um convidado não consegue abrir um arquivo recém-enviado,

00:04:05.840 --> 00:04:07.900
o velho mundo cria um relatório e transfere.

00:04:08.660 --> 00:04:10.800
No novo modelo, a gente vê o padrão imediatamente,

00:04:10.940 --> 00:04:13.100
verifica se a condição corresponde a um problema conhecido

00:04:13.100 --> 00:04:15.200
e se executa a próxima ação segura para corrigi-lo.

00:04:15.840 --> 00:04:18.460
Talvez ele redefine um caminho, acione uma verificação de política

00:04:18.460 --> 00:04:21.580
ou redirecione uma solicitação e peça a MFA antes de documentar o ajuste.

00:04:22.200 --> 00:04:22.840
O ponto é simples.

00:04:23.320 --> 00:04:26.280
A primeira resposta não requer mais que um humano leia uma descrição vaga

00:04:26.280 --> 00:04:27.480
e adivinha o que aconteceu.

00:04:27.860 --> 00:04:29.480
Isso parece invisível quando funciona bem,

00:04:29.540 --> 00:04:30.900
porque não há sala de espera nem formulário.

00:04:31.000 --> 00:04:32.880
Selecione uma categoria para preencher, para preencher.

00:04:33.180 --> 00:04:34.680
O suporte aparece como fluxo a restaurar.

00:04:35.240 --> 00:04:37.500
O funcionário simplesmente volta ao trabalho,

00:04:37.620 --> 00:04:39.680
em muitos casos nem vê o maquinário funcionando nos bastidores.

00:04:39.680 --> 00:04:42.760
Você já pode ver como isso muda a sua lógica de equipe.

00:04:43.580 --> 00:04:45.600
O modelo antigo contrata pessoas para absorver o volume,

00:04:45.700 --> 00:04:48.720
classificar solicitações e limpar contextos quebrados entre diferentes equipes.

00:04:49.160 --> 00:04:51.600
O novo modelo precisa de menos pessoas fazendo triagem

00:04:51.600 --> 00:04:53.240
e mais pessoas projetando proteções,

00:04:53.360 --> 00:04:56.580
definindo estados desejados e supervisionando como esses agentes se comportam ao longo do tempo.

00:04:56.920 --> 00:04:58.320
Os humanos permanecem no sistema,

00:04:58.600 --> 00:05:00.500
mas todo o formato de seu trabalho diário muda.

00:05:01.100 --> 00:05:03.900
Pesquisa sobre a de agente no suporte continua apontando nessa direção.

00:05:04.640 --> 00:05:07.680
O suporte de rotina pode avançar para o tratamento baseado em exceções,

00:05:07.680 --> 00:05:11.260
o que cria ganhos de eficiência enormes quando o ambiente e as políticas são bem delimitados.

00:05:11.960 --> 00:05:14.060
Essa última parte é vital porque não é mágica.

00:05:14.580 --> 00:05:16.800
Se seus dados forem fracos ou seu processo for confuso,

00:05:16.880 --> 00:05:19.900
o agente não se tornará inteligente só porque você decidiu chamá-lo de autônomo.

00:05:20.540 --> 00:05:23.620
Tudo isso fez sentido para mim quando parei de pensar no agente como um recurso de software

00:05:23.620 --> 00:05:26.220
e comecei a vê-lo como um funcionário não humano com um crachá.

00:05:26.980 --> 00:05:30.900
Um trabalhador real precisa de uma identidade, descrição de cargo, permissões e um gestor a reportar.

00:05:31.400 --> 00:05:33.100
O agente precisa exatamente dessas mesmas coisas

00:05:33.100 --> 00:05:35.300
porque o valor vem de uma ação confiável dentro de um sistema,

00:05:35.300 --> 00:05:37.360
não de uma linguagem inteligente e uma janela bate-papo.

00:05:37.680 --> 00:05:39.800
O funcionário invisível não é truque de interface.

00:05:40.300 --> 00:05:44.400
É uma nova camada de suporte que observa o atrito em todo o conjunto do Microsoft 365,

00:05:45.060 --> 00:05:49.280
age de acordo com a política e direciona a atenção humana para as exceções que realmente precisam de julgamento.

00:05:49.880 --> 00:05:52.420
Depois que esse modelo ficar claro, a próxima pergunta se torna muito prática.

00:05:52.820 --> 00:05:54.000
Como a preempção realmente funciona?

00:05:54.500 --> 00:05:55.600
A arquitetura da preempção.

00:05:56.280 --> 00:05:58.900
Então, como a preempção realmente funciona dentro do Microsoft 365?

00:05:59.420 --> 00:06:02.720
A mudança passa de solicitação e resposta para raciocínio e orquestração de eventos.

00:06:03.020 --> 00:06:05.660
Isso parece técnico, mas o modelo é simples depois que você o desmembra.

00:06:05.660 --> 00:06:10.640
Primeiro, algo no ambiente muda, depois o sistema interpreta se essa mudança significa risco ou desvio.

00:06:10.880 --> 00:06:14.320
E por fim, toma a ação aprovada usando as ferramentas já existentes em sua pilha.

00:06:15.220 --> 00:06:16.080
Comece com a camada de eventos.

00:06:16.480 --> 00:06:19.180
O Microsoft 365 já produz sinais em toda parte.

00:06:19.540 --> 00:06:23.620
O Enter observa o comportamento de login enquanto o Intune rastreia a postura e conformidade do dispositivo.

00:06:24.280 --> 00:06:29.140
O Defender observa atividades suspeitas e o Teams mostra exatamente quando uma reunião falha ou a qualidade da chamada cai.

00:06:29.140 --> 00:06:32.860
O SharePoint e o Exchange expõem padrões de acesso e atividade de conteúdo,

00:06:33.060 --> 00:06:36.000
enquanto sinais de integridade do serviço informam quando a plataforma isso é o problema.

00:06:36.520 --> 00:06:39.700
Quando você adiciona ações do usuário a isso, tem um fluxo constante de contexto.

00:06:40.220 --> 00:06:44.160
A maioria das organizações coleta sinais, mas muito poucas realmente os usam como sistema de suporte.

00:06:44.880 --> 00:06:48.680
Eventos brutos por si só não ajudam porque precisam de uma camada de raciocínio para dar sentido ao ruído.

00:06:49.540 --> 00:06:53.300
É aqui que o funcionário invisível deixa de ser um teatro de automação e começa a agir como operador real.

00:06:53.300 --> 00:06:58.780
O agente analisa o sinal, compara o estado atual com o estado desejado e decide qual classe de ação é segura a tomar.

00:06:59.480 --> 00:07:04.620
Um problema de áudio não é o mesmo que um login arriscado e um link quebrado é diferente de uma incompatibilidade de licença.

00:07:05.380 --> 00:07:09.580
O agente precisa classificar o problema primeiro, pois agir sem classificação só cria erros mais rápido.

00:07:10.380 --> 00:07:11.400
Em seguida vem a orquestração.

00:07:12.160 --> 00:07:15.140
Depois que o agente entende o problema, ele pode usar o mecanismo certo para responder.

00:07:15.820 --> 00:07:20.840
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.

00:07:20.840 --> 00:07:23.960
As ferramentas importam, mas o que conta é como elas se conectam entre si.

00:07:24.540 --> 00:07:29.180
Você não está criando um prompt inteligente, mas sim uma cadeia que pode detectar, decidir, agir e verificar.

00:07:29.780 --> 00:07:31.080
Essa última parte é perdida o tempo.

00:07:31.480 --> 00:07:34.240
Um sistema de autocorreção não para depois que a ação é tomada.

00:07:35.000 --> 00:07:41.120
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.

00:07:41.780 --> 00:07:48.800
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.

00:07:48.800 --> 00:07:55.580
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.

00:07:56.380 --> 00:07:59.240
Você pode imaginar isso claramente em alguns casos do Microsoft 365.

00:07:59.440 --> 00:08:05.460
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.

00:08:06.320 --> 00:08:07.580
Ele aplica a correção permitida.

00:08:07.940 --> 00:08:11.260
Confirma se o usuário tem acesso e registra a alteração sem que ninguém pergunte.

00:08:11.260 --> 00:08:17.260
Se um login arriscado aparecer no Entra, o agente verá o evento de risco e verificará suas regras de acesso condicional imediatamente.

00:08:17.960 --> 00:08:23.420
Ele solicita uma verificação mais forte ou bloqueia o acesso conforme sua política, registrando o resultado para a revisão humana posterior.

00:08:24.260 --> 00:08:29.880
Quando um link de compartilhamento obsoleto falha no SharePoint, o agente compara o caminho de permissão atual com as regras de compartilhamento.

00:08:30.840 --> 00:08:34.520
Ele substitui a raiz quebrada pela aprovada e envia o link corrigido no contexto,

00:08:34.780 --> 00:08:39.260
o que fecha o ciclo antes que um analista de mesa precise ler um ticket intitulado Problema de Acesso Urgente.

00:08:39.260 --> 00:08:42.140
Suporte e reunião é outro ótimo exemplo.

00:08:42.740 --> 00:08:46.460
Se um dispositivo de sala falhar ou a conexão for interrompida instantes antes da chamada,

00:08:46.720 --> 00:08:48.540
o agente detecta a condição e valida a falha.

00:08:49.120 --> 00:08:53.740
Ele tenta uma recuperação de baixo risco e avisa o organizador no Teams atualizando o status onde o trabalho acontece.

00:08:54.640 --> 00:08:56.780
Essa camada de comunicação é uma parte importante do design.

00:08:57.460 --> 00:08:59.160
O suporte precisa estar onde a interrupção acontece.

00:08:59.760 --> 00:09:03.440
Se seu trabalho acontece no Teams, Outlook e no espaço de trabalho do M365,

00:09:03.440 --> 00:09:05.280
o suporte também deve responder você lá.

00:09:05.840 --> 00:09:09.180
Você não deve ter que arrastar o usuário para outro lugar quando pode atender o evento no contexto.

00:09:10.000 --> 00:09:13.820
Nada disso significa realizar todas as tarefas individualmente, porque isso seria imprudente.

00:09:14.400 --> 00:09:18.820
Ações de baixo risco rodam automaticamente, mas mudanças de alto impacto ainda exigem aprovação humana.

00:09:18.900 --> 00:09:23.620
Esse caminho de aprovação precisa fazer parte da arquitetura desde o início em vez de ser adicionado posteriormente.

00:09:24.220 --> 00:09:27.320
A gente deve saber quando agir, quando perguntar e exatamente quando parar.

00:09:28.080 --> 00:09:31.800
E depois que você incorpora isso ao fluxo, a conversa deixa de ser sobre recursos de automação.

00:09:32.040 --> 00:09:35.820
Passa a ser sobre controle, governança, confiança e identidade do agente.

00:09:35.820 --> 00:09:39.940
Quando o suporte começa a agir por conta própria, uma pergunta difícil surge imediatamente.

00:09:40.540 --> 00:09:41.660
Quem está realmente fazendo o trabalho?

00:09:42.440 --> 00:09:44.700
Se essa resposta for vaga, todo modelo desmorona.

00:09:45.340 --> 00:09:49.360
Um agente não pode existir em seu ambiente como um auxiliar impreciso com amplo acesso e nenhum proprietário claro.

00:09:49.720 --> 00:09:51.220
Ele precisa de uma identidade real no ENTER.

00:09:51.660 --> 00:09:56.060
Precisa de um responsável definido, um escopo claro e um ciclo de vida que começa e termina por um motivo real.

00:09:56.060 --> 00:10:00.800
Se esse agente pode ler dados, acionar fluxos de trabalho ou enviar mensagens aos seus usuários,

00:10:00.880 --> 00:10:02.920
você precisa governá-lo como um participante ativo no locatário.

00:10:03.400 --> 00:10:06.100
Você não pode tratá-lo como um recurso que alguém ativou e depois esqueceu.

00:10:06.680 --> 00:10:08.980
Por isso que a identidade do agente é tão crítica para o sistema.

00:10:09.640 --> 00:10:14.460
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.

00:10:14.960 --> 00:10:16.400
O privilégio mínimo deve ser a linha de base aqui.

00:10:16.860 --> 00:10:20.800
Você não pode se contentar com ampla conveniência ou dizer a si mesmo que restringirá as permissões mais tarde.

00:10:21.440 --> 00:10:24.600
Como o raio de ação de um agente de suporte depende inteiramente de suas permissões?

00:10:24.600 --> 00:10:27.420
Projetar essas permissões é uma parte essencial do design do suporte.

00:10:28.520 --> 00:10:32.100
O Aging 365 atua como uma camada de controle necessária nessa configuração

00:10:32.100 --> 00:10:34.240
porque coloca todo o patrimônio do agente em uma visão clara.

00:10:35.200 --> 00:10:38.140
Ele fornece o registro, os fluxos de trabalho e aprovação e os modelos de política

00:10:38.140 --> 00:10:39.640
e mantém tudo funcionando com segurança.

00:10:40.420 --> 00:10:44.300
Embora essas peças possam soar como tarefas administrativas, elas resolvem uma norma estrutural.

00:10:44.920 --> 00:10:47.700
A maioria das organizações não tem dificuldades porque não têm recursos de ar,

00:10:47.960 --> 00:10:50.820
mas porque não conseguem ver ou controlar o que já está em execução em seu ambiente.

00:10:51.500 --> 00:10:52.800
A pesquisa sobre esse ponto é direta.

00:10:52.800 --> 00:10:56.680
Apenas uma pequena minoria de grandes empresas consegue inventariar completamente

00:10:56.680 --> 00:10:58.360
todos os agentes em execução no sistema.

00:10:59.020 --> 00:11:00.940
Antes de falar em escalar o suporte autônomo,

00:11:01.060 --> 00:11:03.320
os líderes precisam responder a uma pergunta bem mais simples.

00:11:04.000 --> 00:11:06.820
Sabemos mesmo quais agentes existem e o que estão fazendo agora?

00:11:07.300 --> 00:11:09.680
A supervisão também precisa corresponder ao nível de risco envolvido.

00:11:10.080 --> 00:11:12.720
Um agente de produtividade pessoal trabalhando em uma via estreita é uma coisa,

00:11:12.800 --> 00:11:15.980
mas um agente colaborativo lidando com conteúdo compartilhado com um tamanho diferente.

00:11:16.620 --> 00:11:19.260
Então você tem agentes corporativos agindo em fluxo de trabalho confidenciais,

00:11:19.260 --> 00:11:21.020
o que se enquadra em uma categoria diferente de risco.

00:11:21.020 --> 00:11:24.800
Por isso que o modelo de zona de risco pessoal colaborativo e empresarial é tão importante.

00:11:25.640 --> 00:11:27.780
Seu modelo de controle deve crescer junto com o possível impacto.

00:11:28.800 --> 00:11:30.780
Se você tratar todos os agentes da mesma forma,

00:11:30.840 --> 00:11:33.100
o trabalho de baixo risco ficará travado em aprovações lentas

00:11:33.100 --> 00:11:35.120
e o de alto risco passará sem escutínio.

00:11:35.560 --> 00:11:39.400
No mínimo, sua pilha de controle no Microsoft 365 deve parecer familiar para sua equipe.

00:11:39.840 --> 00:11:40.920
Eu uso identidade no Entra,

00:11:41.160 --> 00:11:43.680
limites de dados por meio do Purview e monitoramento por meio do Defender.

00:11:44.340 --> 00:11:46.840
Você aplica condições de acesso por meio de acesso condicional

00:11:46.840 --> 00:11:49.420
e garante que a auditabilidade seja incorporada desde o início.

00:11:49.940 --> 00:11:52.220
Você precisa ser capaz de reconstruir exatamente o que aconteceu

00:11:52.220 --> 00:11:54.100
sem ter que adivinhar depois que um incidente ocorre.

00:11:54.840 --> 00:11:58.480
A supervisão humana precisa ser projetada na lógica em vez de improvisada durante uma crise.

00:11:59.280 --> 00:12:02.020
Ações de alto impacto devem sempre pausar para uma assinatura humana.

00:12:02.540 --> 00:12:05.540
O raciocínio deve ser registrado em um formulário que as pessoas possam realmente inspecionar e entender.

00:12:05.960 --> 00:12:07.620
Você precisa que existam caminhos de reversão

00:12:07.620 --> 00:12:09.720
antes que a primeira ação autônoma entre em vigor.

00:12:09.720 --> 00:12:13.040
Se um agente atualizar o acesso ou mudar uma política de roteamento,

00:12:13.140 --> 00:12:15.940
alguém precisará rastrear essa decisão e desfazê-la, limpidamente.

00:12:16.520 --> 00:12:19.620
Há outro fator que líderes ignoram, pois as demonstrações iniciais parecem excelentes.

00:12:20.180 --> 00:12:21.100
O custo do retrabalho.

00:12:21.800 --> 00:12:23.740
Se um agente cria ciclos de limpeza para sua equipe,

00:12:23.840 --> 00:12:25.560
a economia projetada desaparece instantaneamente.

00:12:26.160 --> 00:12:27.080
Esse é o imposto de retrabalho.

00:12:27.400 --> 00:12:29.240
É o tempo gasto corrigindo resultados ruins,

00:12:29.560 --> 00:12:32.420
revertendo ações erradas ou perseguindo efeitos colaterais indesejados.

00:12:32.720 --> 00:12:34.820
Se sua equipe economiza 10 minutos na execução,

00:12:34.920 --> 00:12:38.480
mas gasta 8 minutos limpando a bagunça, você não automatizou o suporte de fato.

00:12:38.480 --> 00:12:41.420
Você apenas moveu o atrito para uma parte diferente do processo.

00:12:41.940 --> 00:12:44.660
A confiança não vem de um conjunto político expolido ou de um grande anúncio de lançamento.

00:12:44.940 --> 00:12:46.220
Ela vem de evidências em tempo de execução.

00:12:46.600 --> 00:12:49.860
As pessoas precisam ver o que o agente viu, o que ele decidiu e o que realmente mudou no sistema.

00:12:50.220 --> 00:12:52.100
É assim que você constrói confiança no suporte autônomo.

00:12:52.440 --> 00:12:55.860
A prova tem que estar no comportamento da ferramenta e não na marca do projeto.

00:12:56.340 --> 00:12:58.300
Uma vez que essa base de governança esteja sólida,

00:12:58.360 --> 00:13:02.120
a conversa pode finalmente deixar de lado o jargão de segurança e passar para a linguagem executiva.

00:13:02.640 --> 00:13:04.160
O que isso realmente muda no resultado final?

00:13:04.820 --> 00:13:06.620
O novo ROI do suporte invisível.

00:13:06.620 --> 00:13:10.340
Uma vez que os líderes aceitam o modelo de controle, as questões financeiras começam a mudar.

00:13:10.760 --> 00:13:13.340
No modelo antigo, o valor do suporte é medido pelo trabalho visível,

00:13:13.420 --> 00:13:15.700
como tickets fechados, chamadas atendidas e desempenho do SLA.

00:13:16.340 --> 00:13:19.360
Esses números ainda importam, mas descrevem apenas uma reação ao problema.

00:13:19.980 --> 00:13:22.100
Eles não informam quanta interrupção não chegou à fila,

00:13:22.180 --> 00:13:25.280
quanto tempo o funcionário permaneceu intacto porque um problema foi resolvido precocemente.

00:13:25.660 --> 00:13:27.020
Esse é o principal problema da contabilidade.

00:13:27.540 --> 00:13:29.520
O suporte invisível cria valor por meio da ausência.

00:13:29.520 --> 00:13:33.800
Você vê o valor quando no ticket não há escalonamento e nenhum analista gastando 20 minutos

00:13:33.800 --> 00:13:36.320
reconstruindo um problema a partir de notas incompletas.

00:13:37.660 --> 00:13:41.920
Se você medir apenas o esforço visível da equipe de suporte, não atingirá o resultado que realmente queria.

00:13:42.540 --> 00:13:44.340
Você cria um trabalho estável com menos interrupções.

00:13:44.820 --> 00:13:47.380
O volume de tickets é um sinal fraco quando se sustenta sozinho.

00:13:48.060 --> 00:13:49.760
Uma queda nos tickets pode indicar a demanda menor,

00:13:49.980 --> 00:13:52.720
mas também que o ambiente está mais saudável e a nossa camada de suporte mais inteligente.

00:13:53.200 --> 00:13:54.340
Essas são duas histórias muito diferentes.

00:13:54.340 --> 00:13:58.080
Os executivos precisam de um conjunto de KPIs que possam diferenciar entre eles.

00:13:58.660 --> 00:14:00.860
Você deve começar observando a taxa de resolução autônoma.

00:14:01.720 --> 00:14:03.460
Não se trata de quantas conversas o bot teve,

00:14:03.740 --> 00:14:07.180
mas de quantos eventos de suporte foram resolvidos de ponta a ponta sem que o humano sequer os tocasse.

00:14:07.840 --> 00:14:10.200
Você também precisa monitorar a redução no tempo médio de resolução.

00:14:10.680 --> 00:14:15.300
Em ambientes orientados por IA, fluxos diagnósticos frequentemente apresentam melhorias na faixa de 40% a 60%.

00:14:15.300 --> 00:14:19.300
Em seguida, você pode analisar o custo por resolução e a produtividade do usuário recuperado.

00:14:19.480 --> 00:14:24.020
É fácil ignorar essa última métrica, pois ela não se encaixa bem em um relatório padrão da central.

00:14:24.600 --> 00:14:26.260
No entanto, é geralmente aí que reside o valor real.

00:14:26.860 --> 00:14:31.240
Uma pessoa que fica bloqueada por 15 minutos antes mesmo de abrir um ticket já criou um custo para a empresa.

00:14:32.260 --> 00:14:36.060
Quando você multiplica isso por interrupções de reunião e atrito de acesso em um grande inquilino,

00:14:36.120 --> 00:14:37.900
a peda oculta é muito maior do que a fila sugere.

00:14:38.940 --> 00:14:41.500
Por isso que o modelo de custo da inação é tão importante por causa de negócios.

00:14:42.200 --> 00:14:45.600
Você calcula as horas gastas em esforço manual antes mesmo de o suporte formal começar.

00:14:46.140 --> 00:14:48.040
Em seguida, adiciona o custo de erros e trabalha repetido.

00:14:48.200 --> 00:14:51.180
De repente, o argumento para preempção deixa de soar como uma teoria.

00:14:51.840 --> 00:14:53.760
Você não está apenas financiando uma camada de suporte futurista.

00:14:54.340 --> 00:14:57.340
Você está removendo um imposto que está parado em seu trabalho diário há anos.

00:14:57.880 --> 00:14:59.840
A economia do caso específico deixa isso ainda mais claro.

00:15:00.500 --> 00:15:04.900
Estudo sobre suporte de TI agêntico citou um atendimento humano em US$8,75 por caso.

00:15:05.560 --> 00:15:10.420
Em contraste, o manuseio agêntico restrito pode custar menos de 50 centavos por caso após o sistema pronto.

00:15:10.960 --> 00:15:13.460
Isso não significa que todas as ações de suporte serão tão baratas,

00:15:13.540 --> 00:15:15.260
e os líderes devem ter cuidado com as médias amplas.

00:15:15.260 --> 00:15:19.040
A qualidade e a governança da telemetria sempre afetarão o custo final,

00:15:19.340 --> 00:15:21.120
mas a direção da tendência é inconfundível.

00:15:21.700 --> 00:15:24.400
Este é o momento em que a TI sai da velha história do centro de custo.

00:15:25.080 --> 00:15:29.020
Não é porque o suporte desaparece, mas porque o suporte se transforma em uma camada de confiabilidade

00:15:29.020 --> 00:15:31.160
que protege a produtividade dos funcionários em segundo plano.

00:15:31.800 --> 00:15:35.240
Empresa sente isso como um trabalho mais tranquilo em vez de um evento de suporte dramático.

00:15:35.700 --> 00:15:39.840
Você obtém menos interrupção em restauração mais rápido e menos trabalho desperdiçado em roteamento e esclarecimento.

00:15:39.840 --> 00:15:42.780
Contudo, uma medição ruim pode facilmente forjar progresso.

00:15:43.720 --> 00:15:48.120
Se sua telemetria for fraca, a gente pode apenas resumir uma falha mais rápida em vez de realmente evitá-la.

00:15:48.460 --> 00:15:51.620
Se o retrabalho não for incluído no painel, o ROI parecerá muito mais limpo do que realmente é.

00:15:52.000 --> 00:15:56.700
Se o tempo recuperado simplesmente vazar para atividades de baixo valor, os líderes exagerarão o ganho.

00:15:57.280 --> 00:16:01.440
O caso financeiro deve permanecer fundamentado em evidências concretas como incidentes evitados e menos toxímono.

00:16:02.020 --> 00:16:04.500
Você precisa mensurar o tempo realmente devolvido ao trabalho útil.

00:16:05.080 --> 00:16:09.040
Depois de mensurar isso corretamente, a função de suporte deixa de parecer uma despesa indireta que precisa ser cortada.

00:16:09.040 --> 00:16:12.360
Começa a aparecer uma capacidade operacional que a empresa finalmente recupera.

00:16:13.360 --> 00:16:14.400
O que isso faz com a equipe de suporte?

00:16:15.200 --> 00:16:18.980
Pense no que isso realmente faz com a equipe em campo, porque essa mudança não tem a ver com cortar pessoal,

00:16:19.060 --> 00:16:21.360
mas sim com mudar o que seu pessoal realmente faz com o dia.

00:16:22.640 --> 00:16:26.020
Na estrutura antiga, grande parte da capacidade de suporte é consumida por redefinições de senha,

00:16:26.100 --> 00:16:28.340
roteamento e ciclos de esclarecimento e ciclos de esclarecimento.

00:16:28.640 --> 00:16:32.940
Você tem pessoas buscando atualizações e movendo dados entre sistemas que nunca foram projetados para se comunicarem.

00:16:33.400 --> 00:16:37.020
Nenhum desses trabalhos torna o ambiente mais estável, apenas evita que a fila fique lotada.

00:16:37.020 --> 00:16:41.820
Quando os agentes assumem esse trabalho de rotina previsível, o esforço humano finalmente sobe um nível.

00:16:42.440 --> 00:16:45.640
Os engenheiros de suporte começam a dedicar seu tempo definindo como é um estado saudável

00:16:45.640 --> 00:16:47.720
e ajustando a lógica por trás das aprovações.

00:16:48.220 --> 00:16:51.300
Eles focam em melhorar fontes de conhecimento, testar comportamentos de políticas

00:16:51.300 --> 00:16:53.440
e garantir que o agente siga os limites que lhe foram dados.

00:16:54.200 --> 00:16:56.960
Esse trabalho é bem diferente de encarar linhas de assunto o dia todo

00:16:56.960 --> 00:16:59.040
e tentar adivinhar o que um usuário deseja de verdade.

00:16:59.960 --> 00:17:01.700
É exatamente aqui que a maioria das implantações para.

00:17:01.700 --> 00:17:05.280
As organizações tentam manter seus antigos processos ineficazes

00:17:05.280 --> 00:17:07.420
colocando um agente no topo e esperando um resultado melhor.

00:17:07.960 --> 00:17:10.880
Mas o processo ainda é reativo, as transferências ainda são confusas

00:17:10.880 --> 00:17:12.420
e o conhecimento subjacente ainda é fraco.

00:17:13.000 --> 00:17:15.620
O agente se torna apenas mais uma camada de tinta em uma parede em ruínas.

00:17:15.960 --> 00:17:19.600
Pode responder mais rápido, mas não conserta um modelo de suporte que foi criado à base de atrasos.

00:17:20.120 --> 00:17:21.660
A melhor maneira é redesenhar o trabalho primeiro.

00:17:22.140 --> 00:17:24.600
Você precisa decidir quais tarefas permanecem humanas

00:17:24.600 --> 00:17:26.560
porque exigem julgamento ou comunicação sensível.

00:17:26.980 --> 00:17:29.380
Em seguida, você decide qual trabalho passa para fluxos autônomos

00:17:29.380 --> 00:17:31.280
porque o resultado é previsível e as ações são seguras.

00:17:31.840 --> 00:17:34.100
Essa divisão é vital porque as equipes de suporte não vão embora.

00:17:34.620 --> 00:17:37.340
Elas estão apenas se tornando as pessoas que projetam os controles e lidam com as exceções.

00:17:37.700 --> 00:17:39.880
Isso significa que a forma como treinamos as pessoas também muda.

00:17:40.340 --> 00:17:42.340
As equipes precisam aprender a supervisionar um sistema

00:17:42.340 --> 00:17:44.020
em vez de apenas executar uma tarefa manual.

00:17:44.600 --> 00:17:46.200
Elas precisam entender a lógica de reversão,

00:17:46.420 --> 00:17:49.000
as revisões de auditoria e como testar um agente antes de ir ao ar.

00:17:49.660 --> 00:17:51.680
Elas precisam detectar quando o modelo falha,

00:17:51.760 --> 00:17:54.560
pois um fluxo de trabalho automatizado ruim continua sendo um fluxo ruim.

00:17:55.000 --> 00:17:56.240
Ele apenas interrompe as coisas mais raras.

00:17:56.240 --> 00:17:59.800
Se você está contratando para esse futuro, talvez não precise de outro generalista para ter atíquets.

00:18:00.320 --> 00:18:03.560
Você precisa de alguém que possa orquestrar fluxos em todo o conjunto Microsoft 365

00:18:03.560 --> 00:18:06.020
e definir os controles que mantêm os agentes sob controle.

00:18:06.480 --> 00:18:08.340
Você quer pessoas que possam melhorar o ambiente

00:18:08.340 --> 00:18:11.420
para que a demanda de suporte realmente diminua, em vez de apenas se acumular.

00:18:12.100 --> 00:18:13.560
Então, como você realmente começa isso

00:18:13.560 --> 00:18:15.920
sem que se transforme em um grande projeto de transformação de vários anos?

00:18:16.320 --> 00:18:19.240
A melhor opção é escolher um único fluxo que cause atrito constante

00:18:19.240 --> 00:18:21.160
dentro do seu ambiente do Microsoft 365.

00:18:21.660 --> 00:18:23.500
A correção de acesso geralmente é uma ótima opção,

00:18:23.500 --> 00:18:27.040
mas você também pode considerar a reunião de suporte ou transferências de conformidade de dispositivos.

00:18:27.280 --> 00:18:28.480
Não importa qual você escolher,

00:18:28.800 --> 00:18:30.340
desde que o padrão aconteça com frequência

00:18:30.340 --> 00:18:33.040
e você saiba exatamente como deve ser o resultado bem-sucedido.

00:18:33.480 --> 00:18:36.480
Depois de definir a meta, você precisa definir o básico com disciplina real.

00:18:37.260 --> 00:18:38.620
Você precisa saber o que é saudável

00:18:38.620 --> 00:18:41.580
e quais eventos específicos indicam que as coisas estão saindo dos trilhos.

00:18:42.320 --> 00:18:44.320
Decida quais ações são seguras para automatizar

00:18:44.320 --> 00:18:46.320
e exatamente onde a escalada humana precisa começar.

00:18:47.000 --> 00:18:48.280
Antes de colocar algo em produção,

00:18:48.460 --> 00:18:50.200
estabeleça uma base para contagens de tickets,

00:18:50.200 --> 00:18:53.020
toques manuais e o tempo que usuários aguardam por uma correção atual.

00:18:53.020 --> 00:18:55.420
Você também precisa implementar sua governança no primeiro dia.

00:18:55.880 --> 00:18:57.420
Dê ao agente uma identidade específica,

00:18:57.500 --> 00:19:00.220
atribua um responsável humano a ela e defina regras de aprovação claras.

00:19:00.840 --> 00:19:02.960
Cada ação realizada pelo agente precisa ser registrada.

00:19:03.460 --> 00:19:06.520
Você também deve ter um plano para quando esse agente for aposentado ou realocado

00:19:06.520 --> 00:19:08.700
para que não se torne apenas uma automação fantasma.

00:19:09.400 --> 00:19:11.040
Quando esse primeiro fluxo começar a funcionar,

00:19:11.140 --> 00:19:12.640
todo o seu modelo operacional começará a mudar.

00:19:13.100 --> 00:19:15.900
O suporte para de agir como uma recepção que apenas reage aos problemas.

00:19:16.220 --> 00:19:19.360
Em vez disso, ele começa a se comportar como um mecanismo de confiabilidade

00:19:19.360 --> 00:19:20.640
integrado diretamente ao sistema.

00:19:20.640 --> 00:19:24.320
O suporte está mudando de uma reação visível para uma prevenção incorporada.

00:19:24.740 --> 00:19:25.760
O ticket nunca foi o serviço.

00:19:26.100 --> 00:19:27.660
Foi a prova de que o serviço apareceu tarde demais.

00:19:28.220 --> 00:19:31.800
Escolha um fluxo de suporte neste trimestre e redesenvolva-o para prevenção em vez de resposta.

00:19:32.460 --> 00:19:37.180
Se quiser saber mais sobre o M365 Copilot, Azure Segurança e modelos operacionais de IA,

00:19:37.560 --> 00:19:39.740
inscreva-se no M360 FM e deixe uma avaliação.

00:19:40.340 --> 00:19:43.600
Conecte-se comigo, Mercopeter, no LinkedIn com o próximo tópico que você quer abordar.

00:19:43.600 --> 00:19:48.720
E aí