WEBVTT

00:00:00.000 --> 00:00:03.580
La gestión de TX parece un PPKP, no tiene los números, las colas, los paneles de control.

00:00:04.200 --> 00:00:07.760
Pero en realidad, ese modelo solo mide el daño una vez que el sistema ha fallado.

00:00:08.400 --> 00:00:10.700
La parte costosa del problema suele comenzar mucho antes.

00:00:11.120 --> 00:00:14.060
Empieza cuando el empleado pierde 10 minutos, luego 20 y finalmente se rinde.

00:00:14.560 --> 00:00:16.320
Lo intentó. Le pregunta a un compañero.

00:00:16.600 --> 00:00:19.680
¿Pierde la reunión o comparte el archivo equivocado porque el método correcto debe funcionar?

00:00:19.980 --> 00:00:22.100
Y esa es la parte que la mayoría de los equipos soportan en un V.

00:00:22.580 --> 00:00:25.460
El mejor modelo de soporte interno actual no se trata de una clasificación más rápida.

00:00:25.860 --> 00:00:27.960
Se trata de eliminar la necesidad de clasificar por completo.

00:00:27.960 --> 00:00:32.480
Imagina a un agente autónomo en Microsoft 365 que observe el contexto,

00:00:32.820 --> 00:00:36.320
detecte fricciones tempranas y actúe antes de que alguien piense en abrir un portal.

00:00:37.420 --> 00:00:40.300
En este episodio quiero mostrarte por qué el modelo de mesa de ayuda falla,

00:00:40.660 --> 00:00:43.540
qué lo reemplaza realmente y cómo puedes gobernarlo sin crear caos.

00:00:44.420 --> 00:00:48.920
Si este cambio es importante para tu trabajo, suscríbete a M365FM porque a un nivel más profundo.

00:00:49.200 --> 00:00:51.280
El verdadero problema no es la cola, es el modelo detrás de ella.

00:00:52.100 --> 00:00:52.980
La muerte del ticket.

00:00:53.400 --> 00:00:55.140
El antiguo flujo de soporte sigue en todas partes.

00:00:55.500 --> 00:00:56.980
Algo es error. Un usuario lo nota.

00:00:56.980 --> 00:00:58.540
El usuario intenta explicarla.

00:00:59.040 --> 00:01:03.660
Luego T.I. traduce esa explicación en una categoría, una prioridad y quizás un grupo de asignación.

00:01:04.180 --> 00:01:04.880
Prepranatránaco.

00:01:05.480 --> 00:01:06.200
Alguien lo clasifica.

00:01:06.560 --> 00:01:07.780
Alguien más pide más detalles.

00:01:08.180 --> 00:01:09.020
Otro equipo se involucra.

00:01:09.540 --> 00:01:11.640
El tiempo sigue pasando mientras el trabajo real permanece estando.

00:01:11.980 --> 00:01:16.060
Ese proceso parece normal porque es familiar, pero familiar y efectivo no son lo mismo.

00:01:16.760 --> 00:01:17.500
Un ticket no es soporte.

00:01:17.920 --> 00:01:19.620
Un ticket es evidencia de que el soporte llegó tarde.

00:01:19.620 --> 00:01:23.800
Para cuando existe un ticket, el empleado ya ha enfrentado fricciones y perdió su contexto.

00:01:24.640 --> 00:01:27.500
Ya han desviado su atención del trabajo que estaban tratando de hacer.

00:01:28.000 --> 00:01:28.740
La cola es el servicio.

00:01:29.200 --> 00:01:30.340
La cola es un registro de fallas.

00:01:30.800 --> 00:01:34.260
En entornos grandes de Microsoft 365, la clase manual se convierte en el verdadero cuidado.

00:01:34.680 --> 00:01:36.700
Esto no sucede porque los equipos de soporte enviriosos.

00:01:37.200 --> 00:01:40.740
Sucede porque se les pide a los humanos hacer algo que ya no encaja con la escala del entorno.

00:01:40.740 --> 00:01:43.760
Tienes más usuarios, más dispositivos, más aplicaciones, más políticas.

00:01:44.240 --> 00:01:46.360
Tienes más casos excepcionales que cruzan equipos.

00:01:46.480 --> 00:01:49.180
SharePoint, Exchange, Intune y entra al mismo tiempo.

00:01:49.820 --> 00:01:50.980
El volumen no solo crece.

00:01:51.400 --> 00:01:52.400
Las combinaciones crecen.

00:01:52.860 --> 00:01:53.760
Ahí es donde el antiguo modelo es error.

00:01:54.280 --> 00:01:56.160
La mayoría de los equipos responden añadiendo más eso.

00:01:56.640 --> 00:01:59.280
Construyen otro portal, otro bot o alguna otra regla enrutamiento.

00:01:59.760 --> 00:02:03.240
Pero en realidad, eso solo añade una capa más entre el empleado y la solución.

00:02:03.840 --> 00:02:09.020
El sistema sigue esperando a que el usuario note el problema, lo describa y pida ayuda de la manera correcta.

00:02:09.020 --> 00:02:11.520
El trabajo no comienza en un portal de soporte.

00:02:11.680 --> 00:02:17.180
Comienzan Teams en Outlook, en un documento que alguien necesita ahora mismo o en una reunión que empieza en 30 segundos.

00:02:17.700 --> 00:02:19.600
Ahí es donde realmente comienza la demanda de soporte.

00:02:19.780 --> 00:02:22.060
Y el modelo de tickets está totalmente desconectado de ese momento.

00:02:22.500 --> 00:02:24.820
El costo oculto es mucho mayor de lo que muestra su informe de cuenta.

00:02:25.300 --> 00:02:26.320
Gente cambia de contexto, cosa.

00:02:26.700 --> 00:02:28.740
Los incidentes duplicados se acumulan bajo diferentes etiquetas.

00:02:29.060 --> 00:02:30.420
Los artículos de conocimiento quedan obsoletos.

00:02:30.740 --> 00:02:34.600
Los analistas pasan todo el día clasificando, dirigiendo y aclarando en lugar de resolver las cosas realmente.

00:02:35.080 --> 00:02:38.720
El tiempo de resolución se alarga porque cada transferencia añade retraso.

00:02:38.720 --> 00:02:40.920
Y cada retraso elimina el contexto original.

00:02:41.540 --> 00:02:44.720
La investigación sobre IA gente de ATO se apunta al mismo problema estructural.

00:02:45.380 --> 00:02:48.580
Al menos el 80% del esfuerzo sigue atrapado en un trabajo reactivo al estilo ETL.

00:02:49.220 --> 00:02:51.800
Esa cifra importa porque le dice exactamente a dónde va la mano de O.

00:02:52.060 --> 00:02:54.860
No se destina a la resiliencia ni a la prevención, se destina a la reacción.

00:02:55.380 --> 00:02:59.100
Una vez que ves eso, el ticket empieza a parecer menos un modelo operativo y más un síntoma.

00:02:59.500 --> 00:03:02.220
Es el síntoma de un sistema que solo responde una vez que el daño es visible.

00:03:02.860 --> 00:03:05.040
Entonces la siguiente pregunta no es cómo procesar tickets más rápido,

00:03:05.120 --> 00:03:07.260
sino qué debería hacer el sistema antes de que se necesite un ticket.

00:03:07.260 --> 00:03:09.260
El modelo de empleado invisible.

00:03:09.720 --> 00:03:11.040
Entonces, ¿qué reemplaza realmente el ticket?

00:03:11.440 --> 00:03:16.720
No es solo otro chatbot encima del mismo desorden y ciertamente no es una puerta de entrada más bonita a la misma vieja cola.

00:03:17.460 --> 00:03:20.900
El cambio es mucho más profundo porque el empleado invisible es un trabajador operativo

00:03:20.900 --> 00:03:23.120
que vive dentro de su entorno de Microsoft 365.

00:03:24.460 --> 00:03:27.340
Este agente tiene su propia identidad, un alcance de trabajo definido,

00:03:27.460 --> 00:03:30.560
memoria de lo que hizo ayer y reglas estrictas sobre lo que puede y no puede tocar.

00:03:31.260 --> 00:03:32.140
Esa distinción importa.

00:03:32.140 --> 00:03:36.760
Un chatbot espera a que escribas una instrucción, pero un empleado invisible vigila que las condiciones cambien.

00:03:37.060 --> 00:03:39.720
Comienza desde el contexto en lugar de comenzar desde una conversación.

00:03:40.340 --> 00:03:44.440
Como por los estados de inicio de sesión, la salud del dispositivo, el estado de las licencias y cómo se comparten los archivos,

00:03:44.600 --> 00:03:45.840
no tiene que esperar a que aparezca fricción.

00:03:46.700 --> 00:03:49.060
En lugar de preguntar cómo puede ayudar después de que algo se rompe,

00:03:49.360 --> 00:03:51.320
constantemente hace una pregunta diferente en segundo plano.

00:03:51.900 --> 00:03:55.140
¿Qué se está alejando del estado que este empleado necesita para hacer su trabajo ahora mismo?

00:03:55.920 --> 00:03:57.040
Ahí es donde cambian las cosas.

00:03:57.040 --> 00:03:59.600
El modelo está integrado directamente dentro del trabajo mismo.

00:04:00.140 --> 00:04:02.580
Cuando alguien se une a una reunión y el audio falla,

00:04:02.700 --> 00:04:05.160
o un invitado no puede abrir un archivo que acaba de recibir,

00:04:05.800 --> 00:04:07.920
el viejo mundo crea un reporte y una transferencia.

00:04:15.860 --> 00:04:18.380
Tal vez restablece una ruta o activa una verificación de políticas,

00:04:18.460 --> 00:04:21.600
o quizá redirige una solicitud y solicita MFE antes de documentar la solución.

00:04:22.100 --> 00:04:23.000
El punto es sencillo.

00:04:23.360 --> 00:04:27.300
La primera respuesta ya no requiere que un humano lea una descripción vaga y adivine qué sucedió.

00:04:27.840 --> 00:04:31.040
Esto parece invisible cuando funciona bien porque no hay salida de espera ni formularios de

00:04:31.040 --> 00:04:32.740
por favor seleccione una categoría que completar.

00:04:32.740 --> 00:04:34.840
¿Soporte se manifiesta como un flujo restaurante?

00:04:35.240 --> 00:04:36.700
El empleado simplemente vuelve al trabajo,

00:04:36.920 --> 00:04:39.760
y en muchos casos ni siquiera ve la maquinaria funcionando detrás de escena.

00:04:40.360 --> 00:04:42.600
Ya puede ver cómo esto cambia su lógica de personal.

00:04:43.560 --> 00:04:45.480
El modelo antiguo contrata personas para absorber el volumen,

00:04:45.600 --> 00:04:48.520
clasificar solicitudes y corregir contextos rotos entre diferentes equipos.

00:04:49.100 --> 00:04:52.980
El nuevo modelo necesita menos personas haciendo triaje y más personas diseñando protecciones,

00:04:53.120 --> 00:04:56.380
definiendo estados deseados y supervisando cómo se comportan estos agentes con el tiempo.

00:04:56.900 --> 00:04:58.400
Los humanos permanecen en el sistema,

00:04:58.680 --> 00:05:00.500
pero toda la forma de su trabajo diario cambia.

00:05:00.500 --> 00:05:03.860
La investigación sobre el agente en soporte sigue apuntando en esta dirección.

00:05:04.520 --> 00:05:07.500
El soporte rutinario puede avanzar hacia un manejo basado en excepciones,

00:05:07.620 --> 00:05:11.620
lo que crea enormes ganancias de eficiencia cuando el entorno y las políticas están bien delimitados.

00:05:12.180 --> 00:05:14.020
¿Esa última parte es vital porque esto no es magia?

00:05:14.480 --> 00:05:16.760
Si sus datos son débiles o su proceso es desordenado,

00:05:16.940 --> 00:05:19.960
el agente no se volverá inteligente solo porque usted decidió llamarlo autónomo.

00:05:20.500 --> 00:05:23.660
Todo esto cobró sentido para mí cuando dejé de pensar en el agente como una función de software

00:05:23.660 --> 00:05:26.300
y comencé a verlo como un empleado no humano con una credencial.

00:05:27.020 --> 00:05:30.940
Un trabajador real necesita una identidad, una descripción de puesto, permisos y un gerente a quien reportar.

00:05:31.340 --> 00:05:35.340
El agente necesita exactamente lo mismo porque el valor proviene de una acción confiable dentro de un sistema,

00:05:35.680 --> 00:05:37.340
no de un lenguaje ingenioso en una ventana de chat.

00:05:37.900 --> 00:05:39.900
El empleado invisible no es un truco de interfaz de usuario.

00:05:40.340 --> 00:05:44.440
Es una nueva capa de soporte que vigila la afección en todo el entorno de Microsoft 365,

00:05:44.980 --> 00:05:49.020
actúa dentro de las políticas y dirige la atención humana hacia las excepciones que realmente requieren juicio.

00:05:49.020 --> 00:05:52.360
Una vez que ese modelo queda claro, la siguiente pregunta se vuelve muy práctica.

00:05:52.780 --> 00:05:54.020
¿Cómo funciona realmente la premoción?

00:05:54.440 --> 00:05:55.520
La arquitectura de la premoción.

00:05:56.160 --> 00:05:59.080
Entonces, ¿cómo funciona realmente la premoción dentro de Microsoft 365?

00:05:59.500 --> 00:06:02.840
El cambio se desplaza de la solicitud y respuesta al razonamiento de eventos y la orquestación.

00:06:03.300 --> 00:06:05.760
Eso suena técnico, pero el modelo es simple una vez que lo desglosas.

00:06:06.180 --> 00:06:10.500
Primero, algo en el entorno cambia, luego el sistema interpreta si ese cambio significa riesgo o desviación.

00:06:11.020 --> 00:06:14.540
Y finalmente, toma la acción aprobada usando las herramientas que ya tiene en su stack.

00:06:15.040 --> 00:06:16.200
Comienza con la capa de eventos.

00:06:16.460 --> 00:06:18.820
Microsoft 365 ya genera señales en todas partes,

00:06:18.820 --> 00:06:21.480
lo que significa que entra, observa el comportamiento de inicio de sesión

00:06:21.480 --> 00:06:23.700
mientras siente un rastreo el estado de cumplimiento de los dispositivos.

00:06:24.500 --> 00:06:28.080
Defender vigila la actividad sospechosa y Teams le muestra exactamente cuando falla una reunión

00:06:28.080 --> 00:06:29.260
o cae la calidad de una llamada.

00:06:29.960 --> 00:06:32.440
SharePoint y Exchange ponen patrones de acceso y actividad de contenido,

00:06:32.600 --> 00:06:35.840
mientras que las señales de estado de servicio le indican cuando la propia plataforma es el problema.

00:06:36.460 --> 00:06:39.680
Cuando añade las acciones del usuario a esto, obtiene un flujo constante de contexto.

00:06:40.180 --> 00:06:42.080
La mayoría de las organizaciones recopilan esas señales,

00:06:42.280 --> 00:06:44.420
pero muy pocas las usan realmente como un sistema de soporte.

00:06:44.800 --> 00:06:46.420
Su evento sin procesar por sí solos no ayuda,

00:06:46.420 --> 00:06:48.900
porque necesita una capa de razonamiento para darle sentido real.

00:06:49.340 --> 00:06:51.960
Aquí es donde el empleado invisible deja de ser una automatización de fachada

00:06:51.960 --> 00:06:53.340
y comienza a actuar como un operador real.

00:06:53.780 --> 00:06:56.800
El agente analiza la señal, compara el estado actual con el estado deseado

00:06:56.800 --> 00:06:58.740
y decide qué tipo de acción es segura de realizar.

00:06:59.080 --> 00:07:02.200
Un problema de audio en una reunión no es igual a un inicio de sesión de riesgo

00:07:02.200 --> 00:07:05.040
y un enlace para compartir roto es diferente a una falta de coincidencia de licencia.

00:07:05.340 --> 00:07:06.900
El agente debe clasificar el problema primero,

00:07:07.040 --> 00:07:09.440
porque actuar sin clasificar solo genera errores más rápido.

00:07:10.420 --> 00:07:11.340
Luego viene la orquestación.

00:07:11.340 --> 00:07:13.440
Una vez que el agente comprende el problema,

00:07:13.720 --> 00:07:15.420
puede utilizar el mecanismo adecuado para responder.

00:07:15.740 --> 00:07:17.620
Eso podría ser Power Automate para flujos de trabajo,

00:07:17.740 --> 00:07:20.700
Copilot Studio para lógica o Microsoft Graph para acciones y contexto del sistema.

00:07:21.160 --> 00:07:23.880
Las herramientas importan, pero lo más importante es cómo se conectan entre sí.

00:07:24.580 --> 00:07:26.240
Usted no está creando un solo prompt inteligente,

00:07:26.400 --> 00:07:29.240
sino una cadena que puede detectar, decidir, actuar y verificar.

00:07:29.740 --> 00:07:31.360
Esa última parte se pasa por alto todo el tiempo.

00:07:31.640 --> 00:07:34.240
Un sistema de autocorrección no se detiene una vez que se toma la acción.

00:07:35.040 --> 00:07:36.780
Ejecuta un bucle donde detecta el problema,

00:07:37.160 --> 00:07:38.640
prueba la condición, aplica la solución

00:07:38.640 --> 00:07:41.200
y verifica el resultado antes de registrar lo sucedido.

00:07:41.740 --> 00:07:43.540
La investigación sobre lógica de autocorrección

00:07:43.540 --> 00:07:44.940
deja claro que estos sistemas funcionan

00:07:44.940 --> 00:07:46.740
mediante patrones de retroalimentación y corrección

00:07:46.740 --> 00:07:48.980
en lugar de una respuesta aislada de un modelo de lenguaje.

00:07:49.620 --> 00:07:50.700
Si la primera acción falla,

00:07:50.920 --> 00:07:52.560
el sistema necesita una forma de evaluar por qué

00:07:52.560 --> 00:07:53.920
para poder revisar el siguiente paso

00:07:53.920 --> 00:07:55.880
mientras se mantiene dentro de los límites definidos.

00:07:56.380 --> 00:07:58.640
Puede visualizar esto claramente en algunos casos de Microsoft 365.

00:07:59.240 --> 00:08:00.520
Cuando un usuario es bloqueado

00:08:00.520 --> 00:08:02.680
porque su licencia y el alcance de la política no coinciden,

00:08:02.680 --> 00:08:05.480
el agente detecta la discrepancia y verifica el perfil de rol previsto.

00:08:06.280 --> 00:08:07.360
Aplica la corrección permitida.

00:08:07.360 --> 00:08:09.040
Confirma que el usuario tiene acceso

00:08:09.040 --> 00:08:10.960
y registra el cambio sin tener que preguntar a nadie.

00:08:11.920 --> 00:08:13.780
Si aparece un inicio de sesión de riesgo en Entra,

00:08:13.880 --> 00:08:15.300
el agente detecta el evento de riesgo

00:08:15.300 --> 00:08:17.360
y verifica sus reglas de acceso condicional de inmediato.

00:08:18.000 --> 00:08:19.480
Solicita una verificación más estricta

00:08:19.480 --> 00:08:20.960
o bloquea el acceso según su política

00:08:20.960 --> 00:08:23.660
y luego registra el resultado para que un humano lo revise después.

00:08:24.220 --> 00:08:25.700
Cuando un enlace compartido obsoleto

00:08:25.700 --> 00:08:26.640
sigue fallando en SharePoint,

00:08:26.820 --> 00:08:28.480
el agente compara la ruta de permisos actual

00:08:28.480 --> 00:08:30.060
con las reglas de uso compartido esperada.

00:08:30.880 --> 00:08:32.640
Reemplaza la raíz dañada por la probada

00:08:32.640 --> 00:08:34.700
y envía el enlace corregido en contexto,

00:08:34.700 --> 00:08:38.300
lo que cierre el ciclo antes de que un analista tenga que leer un ticket titulado

00:08:38.300 --> 00:08:39.560
problema de acceso urgente.

00:08:40.740 --> 00:08:42.280
El soporte para reuniones es otro gran ejemplo.

00:08:42.700 --> 00:08:44.020
Si un dispositivo desa la falla

00:08:44.020 --> 00:08:46.760
o una ruta de unión se interrumpe segundos antes de iniciar una llamada,

00:08:46.880 --> 00:08:48.820
el agente puede detectar la condición y validar la falla.

00:08:49.080 --> 00:08:50.680
Intenta un paso de recuperación de bajo riesgo

00:08:50.680 --> 00:08:53.080
y notifica al organizador en Teams con una actualización de estado

00:08:53.080 --> 00:08:54.140
justo donde ocurre el trabajo.

00:08:54.640 --> 00:08:56.860
Esa capa de comunicación es una parte fundamental del diseño.

00:08:57.340 --> 00:08:59.120
El soporte debe existir donde ocurra interrupción.

00:08:59.120 --> 00:09:03.180
Si su trabajo ocurre en Teams, Outlook y el espacio de trabajo de M365,

00:09:03.480 --> 00:09:05.160
el soporte también debería responderle allí.

00:09:05.880 --> 00:09:07.560
No debería tener que llevar al usuario a otro lugar

00:09:07.560 --> 00:09:09.160
cuando pueda atender el evento en el contexto.

00:09:09.980 --> 00:09:12.540
Nada de esto significa automatización total en cada tarea

00:09:12.540 --> 00:09:13.720
porque eso sería imprudente.

00:09:14.260 --> 00:09:16.280
Las acciones de bajo riesgo pueden ejecutarse automáticamente,

00:09:16.440 --> 00:09:18.620
pero los cambios de alto impacto aún necesitan la aprobación de una persona.

00:09:18.880 --> 00:09:22.120
Esa ruta de aprobación debe ser parte de la arquitectura desde el principio

00:09:22.120 --> 00:09:23.680
en lugar de añadirse después.

00:09:24.120 --> 00:09:26.140
El agente debe saber cuándo actuar, cuándo preguntar

00:09:26.140 --> 00:09:27.520
y exactamente cuándo detenerse.

00:09:27.520 --> 00:09:29.280
Y una vez que integra eso en el flujo,

00:09:29.360 --> 00:09:31.900
la conversación deja de tratarse sobre funciones de automatización.

00:09:32.340 --> 00:09:35.920
Se vuelve sobre control, gobernanza, confianza, identidad de la gente.

00:09:36.660 --> 00:09:38.400
Cuando el soporte comienza a actuar por su cuenta,

00:09:38.540 --> 00:09:39.960
surge inmediatamente una pregunta difícil.

00:09:40.540 --> 00:09:41.660
¿Quién está haciendo realmente el trabajo?

00:09:42.320 --> 00:09:44.660
Si esa respuesta es vaga, todo el modelo se desmorona.

00:09:45.300 --> 00:09:47.580
Un agente no puede existir en su entorno como un acceso amplio,

00:09:47.680 --> 00:09:49.300
con acceso amplio y sin un propietario claro.

00:09:49.720 --> 00:09:51.240
Necesita una identidad real en entra.

00:09:51.660 --> 00:09:53.800
Necesita un propietario designado, un alcance definido

00:09:53.800 --> 00:09:56.400
y un ciclo de vida que comience y termine por una razón específica.

00:09:56.400 --> 00:10:00.460
Si ese agente puede leer datos, activar flujos de trabajo o enviar mensajes a sus usuarios,

00:10:00.680 --> 00:10:02.860
debe gobernarlo como un participante activo en el inquilino.

00:10:03.460 --> 00:10:06.040
No puede tratarlo como una función que alguien activó y luego olvidó.

00:10:06.660 --> 00:10:09.120
Es por esto que la identidad del agente está en crítica para el sistema.

00:10:09.680 --> 00:10:11.200
Necesita saber exactamente qué es el agente,

00:10:11.320 --> 00:10:14.500
qué sistemas puede tocar y quién recibe la llamada cuando las cosas empiezan a fallar.

00:10:14.940 --> 00:10:16.440
El privilegio mínimo debe ser la base aquí.

00:10:16.880 --> 00:10:18.600
No puede conformarse con una conveniencia general

00:10:18.600 --> 00:10:20.740
o decirse a sí mismo que restringirá los permisos más adelante.

00:10:20.740 --> 00:10:24.720
Debido a que el radio de impacto de un agente de soporte depende totalmente de sus permisos,

00:10:25.100 --> 00:10:27.520
diseñar esos permisos es una parte esencial de diseñar el soporte.

00:10:28.460 --> 00:10:32.160
Agent 365 funciona como una capa de control necesaria en esta configuración,

00:10:32.420 --> 00:10:34.400
ya que permite visualizar claramente todos los agentes.

00:10:35.140 --> 00:10:38.420
Proporciona el registro, los flujos de trabajo, de aprobación y las plantillas de políticas

00:10:38.420 --> 00:10:40.060
que mantienen todo funcionando de forma segura.

00:10:40.360 --> 00:10:42.580
Aunque estos elementos puedan parecer tareas administrativas,

00:10:42.760 --> 00:10:44.320
resuelven un problema estructural masivo.

00:10:44.320 --> 00:10:47.940
La mayoría de las organizaciones no tienen dificultades por falta de funciones de guía,

00:10:48.100 --> 00:10:50.780
sino porque no pueden ver ni controlar lo que ya se ejecuta en su entorno.

00:10:51.500 --> 00:10:52.740
La investigación al respecto es contenta.

00:10:53.420 --> 00:10:55.060
Solo una pequeña minoría de las grandes empresas

00:10:55.060 --> 00:10:58.180
puede inventariar completamente cada agente que se ejecuta actualmente en su sistema.

00:10:59.060 --> 00:11:01.280
Antes de que los líderes hablen de escalar el soporte autónomo,

00:11:01.460 --> 00:11:03.220
deben responder una pregunta mucho más sencilla.

00:11:03.980 --> 00:11:06.780
Sabemos siquiera qué agentes existen y qué están haciendo en este momento.

00:11:07.360 --> 00:11:09.580
Supervisión también debe ajustarse al nivel de riesgo involucrado.

00:11:10.140 --> 00:11:12.760
Un agente de productividad personal que trabaja en un área limitada es una cosa,

00:11:12.760 --> 00:11:15.900
pero un agente colaborativo que acceda a contenido compartido es algo totalmente distinto.

00:11:16.580 --> 00:11:19.560
Luego están los agentes empresariales que actúan en flujos de trabajo confidenciales,

00:11:19.600 --> 00:11:21.200
lo cual pertenece a una categoría de riesgo diferente.

00:11:21.440 --> 00:11:25.120
Es por esto que el modelo de zonas de riesgo personal, colaborativo y empresarial es tan importante.

00:11:25.600 --> 00:11:27.800
Su modelo de control debe aumentar a la par del posible impacto.

00:11:28.720 --> 00:11:30.240
Si trata a todos los agentes por igual,

00:11:30.440 --> 00:11:32.600
el trabajo de bajo riesgo se atasca en aprobaciones lentas,

00:11:32.660 --> 00:11:34.900
mientras que el de alto riesgo se filtra con un escrutinio débil.

00:11:35.540 --> 00:11:39.260
Como mínimo, su pila de control en Microsoft 365 debería resultar familiar para su equipo.

00:11:39.260 --> 00:11:43.720
Usa la identidad en entra, los límites de datos mediante Purview y la supervisión a través de Fender.

00:11:44.320 --> 00:11:46.820
Aplica condiciones de acceso mediante acceso condicional

00:11:46.820 --> 00:11:49.460
y garantiza que la auditabilidad esté integrada desde el principio.

00:11:49.940 --> 00:11:54.080
Debe ser capaz de reconstruir exactamente lo que sucedió sin tener que adivinar después de que ocurra un incidente.

00:11:54.640 --> 00:11:58.540
La supervisión humana debe diseñarse dentro de la lógica en lugar de improvisarse durante una crisis.

00:11:59.120 --> 00:12:02.040
Las acciones de alto impacto siempre deben hacer una pausa para obtener un afirmón.

00:12:02.500 --> 00:12:05.680
El razonamiento debe registrarse de una forma que las personas puedan inspeccionar y comprender el elemento.

00:12:05.680 --> 00:12:09.800
Necesita que existan rutas de reversión antes de que la primera acción autónoma entre en funcionamiento.

00:12:10.460 --> 00:12:13.140
Si un agente actualiza el acceso o cambia una política de enrutamiento,

00:12:13.280 --> 00:12:16.100
alguien debe tener una forma de rastrear esa decisión y deshacerla impiamente.

00:12:16.520 --> 00:12:19.700
Hay otro factor que los líderes suelen pasar por alto, porque las primeras demostraciones se ven muy bien.

00:12:20.180 --> 00:12:20.920
El costo del retrabajo

00:12:20.920 --> 00:12:25.540
Si un agente crea ciclos de limpieza para su equipo, los arros proyectados desaparecen instantáneamente.

00:12:26.080 --> 00:12:27.140
Esto es el impuesto del retrabajo.

00:12:27.400 --> 00:12:29.460
Es el tiempo dedicado a corregir resultados erróneos,

00:12:29.700 --> 00:12:32.640
revertir acciones incorrectas o perseguir efectos secundarios no deseados.

00:12:32.640 --> 00:12:36.660
Si su equipo ahorra 10 minutos en la ejecución, pero desperdicia 8 minutos limpiando el desorden,

00:12:36.840 --> 00:12:38.460
en realidad no automatizó el soporte.

00:12:38.900 --> 00:12:41.500
Solo trasladó la fricción a una parte diferente del proceso.

00:12:41.840 --> 00:12:44.660
La confianza no proviene de una presentación de políticas políticas pulidas ni de un verano.

00:12:44.980 --> 00:12:46.240
Proviene de la evidencia en tiempo de ejecución.

00:12:46.600 --> 00:12:49.800
La gente necesita ver lo que vio la gente, lo que decidió y lo que realmente cambió en el sistema.

00:12:50.220 --> 00:12:52.100
Así es como se construye la confianza en el soporte autónomo.

00:12:52.340 --> 00:12:55.960
La prueba debe residir en el comportamiento de la herramienta y no en la marca del proyecto.

00:12:56.420 --> 00:12:58.660
Una vez que los fundamentos de la gobernanza son sólidos,

00:12:58.660 --> 00:13:02.100
la conversación finalmente puede dejar la jerga de seguridad pasar al lenguaje ejecutivo.

00:13:02.520 --> 00:13:04.220
¿Qué cambia esto realmente para los resultados financieros?

00:13:04.780 --> 00:13:06.720
El nuevo retorno de inversión no hay de soporte invisible.

00:13:07.080 --> 00:13:10.360
Una vez que los líderes aceptan el modelo de control, las cuestiones financieras comienzan a cambiar.

00:13:10.700 --> 00:13:14.320
En el modelo antiguo, el valor del soporte se mide mediante trabajo visible como tickets cerrados,

00:13:14.440 --> 00:13:15.900
llamadas atendidas y cumplimiento de SLA.

00:13:16.340 --> 00:13:19.400
Esas cifras siguen siendo importantes, pero solo describen una reacción ante un problema.

00:13:20.040 --> 00:13:22.140
No dicen cuántas interrupciones nunca llegaron a la cola,

00:13:22.220 --> 00:13:25.260
ni cuánto tiempo del empleado se mantuvo intacto porque un problema se eliminó temprano.

00:13:25.660 --> 00:13:26.840
Ese es el problema contable fundamental.

00:13:26.840 --> 00:13:29.520
El soporte invisible crea valor a través de la ausencia.

00:13:30.060 --> 00:13:32.660
Ves el valor cuando no hay un ticket, no hay escalamiento y no hay escalamiento,

00:13:32.920 --> 00:13:36.860
y no hay un analista pasando 20 minutos reconstruyendo un problema a partir de notas incompletas.

00:13:37.820 --> 00:13:40.040
Si solo mides el esfuerzo visible del equipo de soporte,

00:13:40.180 --> 00:13:42.040
pierdes de vista el resultado que realmente querías.

00:13:42.440 --> 00:13:43.840
¿Irías un trabajo estable con menos interrupción?

00:13:44.540 --> 00:13:47.440
El volumen de tickets es una señal débil cuando se analiza por sí solo.

00:13:47.840 --> 00:13:50.420
Una caída en los tickets podría significar que la demanda disminuyó,

00:13:50.480 --> 00:13:53.240
pero también podría significar que el entorno mejoró y la capa de soporte se vuelve más inteligente.

00:13:53.360 --> 00:13:54.500
Esas son dos historias muy diferentes.

00:13:54.500 --> 00:13:58.100
Los ejecutivos necesitan un conjunto de KPI que pueda distinguir la diferencia entre ellas.

00:13:58.760 --> 00:14:00.920
Deberías empezar por observar la tasa de resolución autónoma.

00:14:01.560 --> 00:14:03.360
No se trata de cuántas conversaciones tuvo el bot,

00:14:03.460 --> 00:14:07.100
sino de cuántos eventos de soporte se resolvieron de principio a fin sin que un humano los tocara.

00:14:07.640 --> 00:14:10.380
También debes realizar un seguimiento de la reducción en el tiempo medio de resolver.

00:14:10.640 --> 00:14:11.940
En entornos impulsados por IA,

00:14:12.040 --> 00:14:15.500
los flujos con mucha carga de diagnóstico suelen ver mejoras en el rango de 40 al 60%.

00:14:15.500 --> 00:14:19.280
Luego puedes observar el costo por resolución y la productividad del usuario que has recuperado.

00:14:19.880 --> 00:14:24.180
Esa última métrica es fácil de omitir porque no encaja perfectamente en un informe estándar de Service Desk.

00:14:24.620 --> 00:14:26.340
Sin embargo, es ahí donde a menudo reside el valor real.

00:14:26.800 --> 00:14:31.360
Una persona que está bloqueada durante 15 minutos antes y quiere abrir un ticket ya ha generado un costo para la empresa.

00:14:31.360 --> 00:14:35.940
Cuando multiplicas eso por las interrupciones en reuniones y la fricción de acceso en un entorno grande,

00:14:36.060 --> 00:14:38.040
la pérdida oculta es mucho mayor de lo que sugiere la cola.

00:14:38.840 --> 00:14:41.780
Esta es la razón por la cual el modelo de costo de la inacción es tan importante para el caso de negocio.

00:14:42.240 --> 00:14:45.680
Calculas las horas dedicadas al esfuerzo manual antes de que comience el soporte formal.

00:14:46.160 --> 00:14:48.140
Luego sumas el costo de los errores y el trabajo repetido.

00:14:48.460 --> 00:14:51.300
De repente el argumento a favor de la prevención deja de sonar como una teoría.

00:14:51.840 --> 00:14:53.760
No solo estás financiando una capa de soporte futurista.

00:14:54.340 --> 00:14:57.440
Estás eliminando un impuesto que ha estado presente en tu trabajo diario durante años.

00:14:57.900 --> 00:14:59.860
La economía del caso específico lo deja más claro.

00:15:02.540 --> 00:15:02.780
Invisible.

00:15:05.320 --> 00:15:10.440
En cambio, la gestión mediante agentes específicos puede bajar de los 50 centavos por incidente una vez desarrollado el sistema.

00:15:10.940 --> 00:15:15.440
Esto no significa que cada acción de soporte será así de barata y los líderes deben tener cuidado con los promedios generales.

00:15:15.840 --> 00:15:21.100
La calidad de la telemetría y la gobernanza siempre afectarán el costo final, pero la dirección de la tendencia es inconfundible.

00:15:21.640 --> 00:15:24.440
Este es el momento en que TI deja atrás la vieja historia del centro de costos.

00:15:25.140 --> 00:15:30.820
No es porque el soporte desaparezca, sino porque se convierte en una capa de confiabilidad que protege el rendimiento del empleado en segundo plano.

00:15:31.680 --> 00:15:35.200
El negocio lo percibe como un flujo de trabajo más fluido en lugar de un evento dramático de soporte.

00:15:35.640 --> 00:15:40.020
Obtienes menos interrupciones, una restauración más rápida y menos mano de obra desperdiciada en enrutamiento y declaraciones.

00:15:40.440 --> 00:15:42.680
Aún así, una mala medición puede fingir progreso fácilmente.

00:15:43.480 --> 00:15:47.900
Si tu telemetría es débil, el agente podría simplemente resumir una falla más rápida en lugar de prevenirla realmente.

00:15:48.500 --> 00:15:51.400
Si el retrabajo se mantiene fuera del tablero, el retorno de inversión parece una realidad.

00:15:52.040 --> 00:15:56.660
Si el tiempo recuperado se filtra de nuevo en actividades de bajo valor, los líderes exagerarán las ganancias.

00:15:57.220 --> 00:16:01.660
El caso financiero debe basarse en evidencia sólida, como incidentes prevenidos y menos intervenciones manuales.

00:16:02.040 --> 00:16:04.480
Tienes que medir el tiempo que realmente regresa al trabajo útil.

00:16:05.060 --> 00:16:09.040
Una vez que mires eso correctamente, la función de soporte deja de parecer un gasto general que debe recortarse.

00:16:09.440 --> 00:16:12.320
Empieza a verse como una capacidad operativa que el negocio finalmente recupera.

00:16:13.220 --> 00:16:14.320
¿Qué hace esto con el equipo de soporte?

00:16:14.320 --> 00:16:21.620
Piensa en lo que esto le hace realmente al equipo en terreno, porque este cambio no se trata de reducir personal, sino de cambiar lo que tu gente hace durante su día.

00:16:22.580 --> 00:16:28.220
En la configuración anterior, la mayor parte de tu capacidad de soporte se consume en restablecimientos de contraseñas, enrutamiento de etiquetas y bucles interminables de creación.

00:16:28.580 --> 00:16:33.120
Tienes personas persiguiendo actualizaciones y moviendo datos entre sistemas que nunca fueron diseñados para comunicarse entre sí.

00:16:33.320 --> 00:16:37.100
Nada de ese trabajo hace que el entorno sea más estable, solo evita que la cola se desborde.

00:16:37.340 --> 00:16:41.920
Cuando los agentes se hacen cargo de ese trabajo rutinario y predecible, el esfuerzo humano finalmente sube de nivel.

00:16:41.920 --> 00:16:47.520
Los ingenieros de soporte empiezan a dedicar su tiempo a definir cómo es un estado saludable y ajustar la lógica detrás de las aprobaciones.

00:16:48.100 --> 00:16:53.620
Se enfocan en mejorar las fuentes de conocimiento, probar cómo se comportan las políticas y asegurar que la gente se mantenga dentro de los límites establecidos.

00:16:54.160 --> 00:16:59.180
Ese es un trabajo completamente diferente, a mirar asuntos de correos todo el día e intentar adivinar qué es lo que el usuario realmente quiere.

00:16:59.640 --> 00:17:01.800
Aquí es exactamente donde la mayoría de las implementaciones están.

00:17:02.420 --> 00:17:07.440
Las organizaciones intentan mantener sus viejos procesos defectuosos y simplemente colocar a un agente encima esperando un mejor resultado.

00:17:07.440 --> 00:17:12.400
Pero el proceso sigue siendo reactivo, las transferencias siguen siendo confusas y el conocimiento subyacente sigue siendo débil.

00:17:12.820 --> 00:17:15.640
El agente se convierte solo en otra capa de pintura sobre una pared que se demora.

00:17:15.940 --> 00:17:19.720
Puede responder una pregunta más rápido, pero no puede arreglar un modelo de soporte diseñado en torno a la demora.

00:17:20.040 --> 00:17:21.660
La mejor manera es rediseñar el trabajo primero.

00:17:22.180 --> 00:17:26.460
Debes decidir qué tareas permanecen en manos humanas porque requieren criterio o una comunicación delicada.

00:17:27.020 --> 00:17:31.060
Luego decides qué trabajo pasa a flujos autónomos porque el resultado es predecible y las acciones son seguras.

00:17:31.840 --> 00:17:34.300
Esta división es vital porque los equipos de soporte no van a desaparecer.

00:17:34.300 --> 00:17:37.260
Solo se están convirtiendo en las personas que diseñan los controles y manejan las excepciones.

00:17:37.600 --> 00:17:39.880
Eso significa que la forma en que capacitamos a las personas también tiene que acabar.

00:17:40.320 --> 00:17:43.980
Los equipos necesitan aprender a supervisar un sistema en lugar de solo ejecutar una tarea manual.

00:17:44.600 --> 00:17:49.200
Necesitan entender la lógica de reversión, las revisiones de auditoría y cómo probar un agente antes de que entre en funcionamiento.

00:17:49.620 --> 00:17:54.960
También deben ser capaces de detectar cuándo un modelo falla porque un flujo de trabajo malo automatizado sigue siendo un flujo de trabajo malo.

00:17:55.040 --> 00:17:56.040
Siempre interrompe las cosas más raras.

00:17:56.520 --> 00:18:00.060
Si estás contratando para este futuro, probablemente no necesites otro generalista para clasificar ticket.

00:18:00.060 --> 00:18:05.740
Necesitas a alguien que pueda gastar flujos a través de la pila de Microsoft 365 y definir los controles que mantienen a los agentes bajo control.

00:18:06.460 --> 00:18:11.620
Quieres personas que puedan mejorar el entorno para que la demanda de soporte realmente disminuya en lugar de simplemente acumularse.

00:18:12.040 --> 00:18:16.040
Entonces, ¿cómo comienzas esto realmente sin que se convierta en un proyecto masivo de transformación de varios años?

00:18:16.300 --> 00:18:20.900
El mejor movimiento es elegir un solo flujo que cause fricción constante dentro de tu entorno de Microsoft 365.

00:18:20.900 --> 00:18:27.100
La colección de acceso suele ser una gran candidata, pero también podrías considerar el soporte para reuniones o las transferencias de cumplimiento de dispositivos.

00:18:27.240 --> 00:18:32.860
No importa cuál elijas, siempre que el patrón ocurra a menudo y sepas exactamente cómo debería verse un resultado exitoso.

00:18:33.320 --> 00:18:36.720
Una vez que tengas el objetivo, debes definir los conceptos básicos con verdadera disciplina.

00:18:37.220 --> 00:18:41.780
Necesitas saber cómo se ve un estado saludable y qué eventos específicos te indican que las cosas están desviando el camino.

00:18:42.280 --> 00:18:46.900
Decide qué acciones son seguras para automatizar y exactamente dónde debe comenzar la escalada humana.

00:18:46.900 --> 00:18:53.200
Antes de poner algo en marcha, asegúrate de tener una base de referencia para tu cantidad de tickets e intervenciones manuales y cuánto tiempo esperan actualmente los usuarios por una solución.

00:18:53.420 --> 00:18:55.280
También debes establecer tu gobernanza desde el primer día.

00:18:55.840 --> 00:19:00.300
Dale a la gente una identidad específica, asígnale a un responsable humano y establece reglas de aprobación claras.

00:19:00.840 --> 00:19:02.860
Cada acción que realice la gente debe quedar registrada.

00:19:03.440 --> 00:19:08.640
También debes tener un plan para cuando la gente sea retirado o reasignado, para que no se convierta en automatización fantasma.

00:19:09.480 --> 00:19:12.640
Cuando ese primer flujo empieza a funcionar, todo tu modelo operativo comienza a cambiar.

00:19:12.740 --> 00:19:15.720
El soporte deja de actuar como una recepción que solo reacciona a los problemas.

00:19:15.720 --> 00:19:20.540
En cambio, empieza a comportarse como un motor de confiabilidad integrado directamente en el sistema.

00:19:21.500 --> 00:19:24.220
El soporte está pasando de una reacción visible a una prevención incorporada.

00:19:24.620 --> 00:19:25.600
El ticket nunca fue el servicio.

00:19:26.080 --> 00:19:27.760
Era la prueba de que el servicio llegó demasiado tarde.

00:19:28.200 --> 00:19:31.880
Elige un flujo de soporte este trimestre y rediseñalo para la prevención en lugar de la respuesta.

00:19:32.420 --> 00:19:38.900
Si quieres más sobre M365 Copilot, haz tu seguridad y modelos operativos de IA, suscríbete a M365 FM y deja una reseña.

00:19:39.140 --> 00:19:39.760
Y deja una reseña.

00:19:40.220 --> 00:19:43.700
Conecta conmigo, Melko Peter, en LinkedIn con el próximo tema que quieras que analicemos.