WEBVTT 00:00:00.000 --> 00:00:05.400 Un cliente envía un correo sobre un pedido dañado, luego llama al día siguiente, después abre un chat porque nadie parece saber qué pasó, 00:00:05.560 --> 00:00:10.400 y repiten la misma historia cada vez mientras su equipo de soporte busca entre bandejas de entrada, notas y herramientas separadas. 00:00:11.360 --> 00:00:14.140 Eso es exactamente lo que soluciona la gestión de casos de Dynamics 365. 00:00:14.980 --> 00:00:18.600 Piensa en un caso como una carpeta etiquetada dentro de un edificio de oficinas concurrido, 00:00:18.680 --> 00:00:22.280 donde cada parte del problema de un cliente entra en esa carpeta de la primera pregunta hasta la respuesta final. 00:00:22.440 --> 00:00:27.640 Usted es Mirko Peters de M365FM, y en esta cápsula de conocimiento verá cómo los casos, el enrutamiento, 00:00:27.640 --> 00:00:33.580 los plazos de respuesta, los artículos de soporte y el cierre encajan perfectamente, lo que es realmente un caso en 20 palabras. 00:00:34.340 --> 00:00:35.680 Entonces, ¿qué es exactamente un caso? 00:00:36.060 --> 00:00:39.240 Un caso es un registro para un problema de un cliente que necesita una respuesta o solución. 00:00:39.720 --> 00:00:45.060 El problema puede ser un producto dañado, una duda de facturación, un problema de inicio de sesión o una solicitud de ayuda con un servicio. 00:00:45.360 --> 00:00:48.320 Aquí está el detalle, un cliente puede tener varios casos a la vez. 00:00:49.100 --> 00:00:54.400 Un mismo cliente podría preguntar por una factura el lunes, reportar un dispositivo fallido el martes y necesitar ayuda para cambiar una dirección el viernes. 00:00:54.400 --> 00:01:01.320 Esos son problemas distintos, por lo que Dynamics 365 los mantiene en registros de casos separados en lugar de acumular toda conversación en un hilo confuso. 00:01:02.120 --> 00:01:04.640 Cuando un agente crea un caso, lo vincula directamente al cliente. 00:01:05.360 --> 00:01:10.000 Ese cliente puede ser un contacto, es decir, una persona individual o una cuenta, refiriéndose a la empresa para la que trabaja. 00:01:10.720 --> 00:01:14.920 Entonces, si Jamie de Northwind Traders reporta un problema, el caso puede señalar tanto a Jamie como a la empresa, 00:01:15.220 --> 00:01:19.300 y cualquiera que abra el registro puede ver quién necesita ayuda y a qué organización pertenece el problema. 00:01:19.300 --> 00:01:24.620 El caso también necesita una descripción clara del problema, normalmente empezando con un título como 00:01:24.620 --> 00:01:29.700 Nuestra impresora se detiene tras actualización de software, o Cliente cobrado dos veces por plan anual, 00:01:30.100 --> 00:01:35.440 y ese título ayuda a escanear una lista de casos abiertos sin abrir cada registro, sin abrir cada registro. 00:01:35.660 --> 00:01:37.460 Debajo de ese título, el agente añade los detalles. 00:01:37.720 --> 00:01:41.800 ¿Qué sucedió? ¿Cuándo empezó? ¿Qué ha intentado ya el cliente? ¿Qué producto involucró? 00:01:42.200 --> 00:01:44.400 Y si se trata de una pregunta o una solicitud o una falla. 00:01:45.000 --> 00:01:48.200 Estos detalles convierten un mensaje vago en trabajo que alguien puede asumir y resolver. 00:01:48.200 --> 00:01:49.880 Desglosémoslo aún más. 00:01:50.540 --> 00:01:53.340 Un caso puede contener un asunto, producto o prioridad del tipo de caso. 00:01:54.160 --> 00:01:57.200 El asunto agrupa el problema en un área como facturación o soporte técnico, 00:01:57.300 --> 00:02:00.080 el producto identifica qué usa el cliente, la prioridad indica al equipo, 00:02:00.540 --> 00:02:05.920 qué tan rápido es revisarlo, y el tipo de caso ofrece otra forma de clasificar el trabajo según su proceso de soporte. 00:02:07.320 --> 00:02:10.080 Ninguno de estos campos resuelve el problema de cliente por sí solo, 00:02:10.700 --> 00:02:12.960 pero ayudan al equipo de soporte a ver el trabajo con claridad, 00:02:13.260 --> 00:02:15.700 especialmente cuando llegan cientos de casos de distintos clientes. 00:02:15.700 --> 00:02:20.840 Un equipo que maneja un fallo grave del servicio no debería tener que buscar entre preguntas generales para encontrarlo. 00:02:21.480 --> 00:02:24.320 Ahora bien, un caso no es solo un formulario que alguien llena y olvida. 00:02:25.100 --> 00:02:27.180 Se convierte en el registro de trabajo para toda la conversación. 00:02:27.720 --> 00:02:29.020 Los correos se conectan al caso. 00:02:29.360 --> 00:02:32.840 Las llamadas telefónicas pueden aparecer ahí y un agente puede añadir notas tras un chat, 00:02:32.960 --> 00:02:35.080 configurar una tarea de seguimiento o registrar una cita. 00:02:35.080 --> 00:02:38.480 Cada actividad permanece ligada al mismo problema del cliente, 00:02:38.660 --> 00:02:41.660 por lo que la siguiente persona no tiene que reconstruir la historia desde cero. 00:02:42.300 --> 00:02:44.180 Imagina que un agente comienza a trabajar por la mañana, 00:02:44.520 --> 00:02:46.840 y luego transfiere el caso a un especialista de producto después del almuerzo. 00:02:47.460 --> 00:02:50.440 Si en un registro del caso, el especialista podría recibir un mensaje breve como, 00:02:50.720 --> 00:02:51.540 ¿podría revisar esto? 00:02:52.440 --> 00:02:53.580 Lo cual no es suficiente. 00:02:54.460 --> 00:02:56.500 Con el registro del caso, pueden ver el problema original, 00:02:56.700 --> 00:02:58.420 los detalles del cliente, lo ocurrido durante la llamada, 00:02:58.480 --> 00:02:59.800 y lo que el primer agente ya verificó. 00:03:00.600 --> 00:03:01.740 Eso ofrece una transferencia mucho más. 00:03:01.740 --> 00:03:06.660 Dynamics 365 mantiene el caso en un estado claro a medida que avanza por el proceso de soporte. 00:03:07.420 --> 00:03:09.440 Puede permanecer activo mientras el equipo investiga, 00:03:09.660 --> 00:03:12.780 y una vez que el equipo soluciona el problema o da la respuesta final, lo resuelve. 00:03:13.600 --> 00:03:15.080 Si la solicitud ya no requiere trabajo, 00:03:15.600 --> 00:03:17.480 quizá llegó por error o el cliente se retractó, 00:03:17.720 --> 00:03:18.960 el equipo puede cancelarla. 00:03:19.760 --> 00:03:21.140 Activo, resuelto y cancelado. 00:03:22.320 --> 00:03:25.580 Esos tres estados dan al equipo una visión compartida del estado de cada problema. 00:03:25.580 --> 00:03:28.960 Así, nadie debe adivinar si un caso aún requiere atención, 00:03:28.960 --> 00:03:34.720 y los gerentes no tienen que tratar trabajo antiguo y terminado como si fuera un problema nuevo. 00:03:35.840 --> 00:03:39.440 Un registro da control y el historial completo del cliente le da contexto a la gente. 00:03:41.200 --> 00:03:42.480 La historia del cliente detrás del caso. 00:03:43.440 --> 00:03:44.920 Un caso te dice que necesitas ser reparado. 00:03:45.380 --> 00:03:46.880 El registro del cliente te dice que llegó a este momento. 00:03:48.080 --> 00:03:50.880 Cuando un agente abre un caso en Dynamics 365 Customer Service, 00:03:51.000 --> 00:03:52.820 puede mirar más allá del último mensaje. 00:03:53.560 --> 00:03:55.460 Ven el panorama general, casos anteriores, 00:03:55.660 --> 00:03:58.780 correos pasados, los productos conectados al cliente y su historial de soporte. 00:03:59.540 --> 00:04:00.820 El contexto cambia la conversación. 00:04:01.560 --> 00:04:02.420 ¿Por qué importa el contexto? 00:04:03.000 --> 00:04:04.860 Imagina que un cliente reporta el fallo en dispositivo. 00:04:05.460 --> 00:04:06.920 Si el agente solo ve el mensaje de hoy, 00:04:06.980 --> 00:04:08.840 es posible que comience con preguntas básicas. 00:04:09.620 --> 00:04:10.140 ¿Qué modelo es? 00:04:10.400 --> 00:04:11.020 ¿Cuándo comenzó? 00:04:11.300 --> 00:04:11.940 ¿Lo reinició? 00:04:12.640 --> 00:04:15.260 Pero el cliente ya se ha puesto en contacto con soporte dos veces ese semana. 00:04:15.660 --> 00:04:17.000 El primer agente envió pasos de solución, 00:04:17.200 --> 00:04:18.560 el segundo gestiona una pieza de repuesto. 00:04:19.240 --> 00:04:22.320 Un tercer agente que ve ese historial no le pedirá al cliente que comience de cero. 00:04:22.540 --> 00:04:23.500 En cambio dirá, 00:04:23.960 --> 00:04:26.780 veo que ya intentó esos pasos y que el repuesto no solucione el problema. 00:04:27.300 --> 00:04:28.060 Probemos con lo siguiente. 00:04:28.780 --> 00:04:29.920 Eso se siente muy distinto a 00:04:29.920 --> 00:04:31.340 ¿Puedo explicarme el problema de nuevo? 00:04:32.180 --> 00:04:34.560 Esto a menudo se llama una vista del cliente de 360 grados. 00:04:35.220 --> 00:04:36.700 Nombre suena sofisticado, pero es sencillo. 00:04:36.980 --> 00:04:39.340 Significa que el agente ve al cliente desde más de un ángulo, 00:04:39.540 --> 00:04:40.980 no solo por un mensaje aislado. 00:04:41.500 --> 00:04:43.320 El agente ve a la persona, ve a la empresa, 00:04:43.640 --> 00:04:44.920 ve solicitudes de soporte anteriores, 00:04:45.120 --> 00:04:47.220 conversaciones previas y los productos conectados a ellos. 00:04:47.680 --> 00:04:50.520 Tal un equipo de soportes o reemplaza las suposiciones como punto de partida clara. 00:04:50.960 --> 00:04:51.300 Ahora bien, 00:04:51.360 --> 00:04:53.000 no todos los clientes reciben el mismo tipo de soporte. 00:04:53.000 --> 00:04:55.300 Un cliente puede haber comprado una garantía, 00:04:55.620 --> 00:04:57.820 su empresa puede pagar por un número fijo de horas de soporte, 00:04:58.340 --> 00:05:02.620 o puede tener un contrato que permita cierto número de casos o soporte premium con asistencia más rápida. 00:05:03.480 --> 00:05:06.060 Dynamics 365 rastrea todo esto mediante derechos. 00:05:06.960 --> 00:05:09.840 Un derecho es el acuerdo de soporte al cliente dentro del sistema. 00:05:10.860 --> 00:05:13.020 Piense en ello como los términos de servicio vinculados a su cuenta. 00:05:13.020 --> 00:05:16.960 Antes de que un agente prometa a un técnico o comience un trabajo con costo, 00:05:17.040 --> 00:05:18.300 verifica qué soporte aplica. 00:05:19.180 --> 00:05:20.340 Eso evita sorpresas incómodas. 00:05:20.560 --> 00:05:20.860 Por ejemplo, 00:05:21.380 --> 00:05:23.860 un cliente podría tener aún cobertura de garantía para un producto de efecto. 00:05:24.180 --> 00:05:25.280 El caso puede seguir ese camino. 00:05:25.840 --> 00:05:27.880 Otro cliente podría haber agotado todas sus horas de soporte. 00:05:28.380 --> 00:05:30.920 El agente lo ve antes de comprometerse a realizar trabajos fuera de la cuerda. 00:05:31.300 --> 00:05:33.640 También ayuda al equipo de soporte a tratar a los clientes de manera justa. 00:05:33.860 --> 00:05:36.860 El agente no necesita buscar en contratos antiguos ni preguntar a otro departamento. 00:05:36.980 --> 00:05:40.540 Los términos de soporte están junto a la información del cliente donde la gente puede encontrarlos. 00:05:40.860 --> 00:05:41.820 Luego está la base de conocimiento. 00:05:41.820 --> 00:05:44.280 Los equipos de soporte resuelven los mismos problemas una y otra. 00:05:44.780 --> 00:05:45.720 Reestablecimiento de contraseñas, 00:05:45.820 --> 00:05:46.840 instrucciones de configuración, 00:05:46.920 --> 00:05:48.240 un error conocido tras una actualización, 00:05:48.380 --> 00:05:49.640 una pregunta de facturación con una respuesta. 00:05:49.940 --> 00:05:52.080 Un artículo de conocimiento almacena esa respuesta en un solo blog. 00:05:52.520 --> 00:05:53.940 Dentro del espacio de trabajo de servicio, 00:05:54.040 --> 00:05:55.920 un agente puede buscar artículos mientras trabaja en un caso. 00:05:56.320 --> 00:05:58.220 Un artículo puede incluir una explicación sencilla, 00:05:58.480 --> 00:05:58.780 pasos, 00:05:58.940 --> 00:05:59.660 una captura de pantalla 00:05:59.660 --> 00:06:01.700 o las comprobaciones exactas que el equipo debe realizar. 00:06:02.080 --> 00:06:04.480 En lugar de que cada agente escriba su propia versión de memoria 00:06:04.480 --> 00:06:06.880 usando la respuesta compartida que el equipo ha revisado, 00:06:07.360 --> 00:06:08.600 eso mantiene la consistencia de su blog. 00:06:08.900 --> 00:06:09.960 También ayuda a los agentes nuevos. 00:06:09.960 --> 00:06:13.060 No necesitan años de experiencia para resolver problemas comunes bien, 00:06:13.340 --> 00:06:16.040 porque las soluciones conocidas del equipo están disponibles cuando las requieren. 00:06:16.560 --> 00:06:18.880 Los resúmenes de casos de Copilot ayudan con otro problema común, 00:06:18.980 --> 00:06:19.840 los historiales de casos lag. 00:06:20.100 --> 00:06:21.680 Un caso puede acumular muchos correos, 00:06:21.760 --> 00:06:23.140 notas y actualizaciones con el paso del día. 00:06:23.500 --> 00:06:24.380 Leerlos todos toma tiempo, 00:06:24.480 --> 00:06:25.700 especialmente después de una transferencia. 00:06:26.000 --> 00:06:28.320 Copilot crea un breve resumen del caso que reúne el título, 00:06:28.580 --> 00:06:29.060 el cliente, 00:06:29.220 --> 00:06:29.540 el asunto, 00:06:29.640 --> 00:06:29.980 el producto, 00:06:30.180 --> 00:06:30.640 la prioridad, 00:06:30.840 --> 00:06:31.440 el tipo de caso, 00:06:31.580 --> 00:06:32.140 la descripción, 00:06:32.280 --> 00:06:33.040 la actividad reciente. 00:06:33.640 --> 00:06:35.680 Es una sesión informativa rápida antes de que la gente cambie se atreva. 00:06:36.040 --> 00:06:38.140 La gente aún revisa el registro y usa su criterio, 00:06:38.640 --> 00:06:39.960 pero entiende la situación más rápido. 00:06:40.760 --> 00:06:42.160 Eso ayuda cuando el cliente está esperando 00:06:42.160 --> 00:06:43.840 y el caso ha pasado por varias manos. 00:06:44.780 --> 00:06:46.520 Una vez que la gente comprende el cliente y el problema, 00:06:46.640 --> 00:06:48.600 el caso debe llegar a la persona adecuada. 00:06:50.890 --> 00:06:52.310 Desde la recepción hasta la cola correcta. 00:06:52.730 --> 00:06:54.110 Un cliente puede pedir ayuda en muchas maneras, 00:06:54.230 --> 00:06:54.790 correo electrónico, 00:06:54.910 --> 00:06:55.570 llamada telefónica, 00:06:55.710 --> 00:06:55.910 chat, 00:06:56.050 --> 00:06:56.510 redes sociales 00:06:56.510 --> 00:06:57.550 o un portal de autoservicio. 00:06:58.050 --> 00:06:58.710 El canal cambia, 00:06:58.830 --> 00:07:01.530 pero el equipo de soporte aún necesita un lugar claro para gestionar la solicitud. 00:07:01.530 --> 00:07:05.130 Dynamics 365 puede crear casos a partir de esas conversaciones 00:07:05.130 --> 00:07:07.530 cuando la configuración incluye reglas de creación de registros. 00:07:08.290 --> 00:07:10.730 Piensa en un correo electrónico que llegue a una dirección de soporte compartida. 00:07:11.310 --> 00:07:13.070 En lugar de dejarlo en un buzón hasta que alguien lo vea, 00:07:13.170 --> 00:07:15.230 una regla convierte ese correo en un caso. 00:07:15.910 --> 00:07:18.130 El mensaje se convierte en el inicio del trabajo dentro del servicio. 00:07:18.350 --> 00:07:20.190 Eso reduce la necesidad de cober información manual. 00:07:20.510 --> 00:07:22.550 La misma idea se aplica a otros canales conectados. 00:07:22.810 --> 00:07:25.130 El equipo elige qué mensajes crea un caso nuevo 00:07:25.130 --> 00:07:26.730 y cuáles pertenecen a uno existente. 00:07:27.770 --> 00:07:29.570 Una respuesta a un problema abierto permanece problema. 00:07:29.810 --> 00:07:31.150 Una pregunta nueva obtiene su propio caso. 00:07:31.150 --> 00:07:32.710 Entonces, el caso necesita un lugar donde estar 00:07:32.710 --> 00:07:33.650 mientras alguien asuma la hermosa. 00:07:33.890 --> 00:07:34.830 Ese lugar suele ser una cola. 00:07:35.250 --> 00:07:37.150 Una cola es una bandeja de trabajo compartida por un equipo. 00:07:37.410 --> 00:07:39.070 No es la bandeja de entrada de un agente 00:07:39.070 --> 00:07:41.010 y no pertenece a la persona que vio la solicitud. 00:07:41.470 --> 00:07:43.090 En cambio, le da a todo el equipo un lugar 00:07:43.090 --> 00:07:44.330 para ver el trabajo que espera atención. 00:07:44.910 --> 00:07:46.470 Imagina una empresa con un equipo de facturación, 00:07:46.830 --> 00:07:48.370 uno de soporte técnico y uno de devoluciones. 00:07:49.070 --> 00:07:50.110 Cada equipo tiene su propia cola. 00:07:50.450 --> 00:07:51.970 Las dudas de facturación van a facturación, 00:07:52.170 --> 00:07:53.690 los fallos de producto del soporte técnico 00:07:53.690 --> 00:07:56.350 y las solicitudes de devolución a quienes conocen el proceso. 00:07:56.830 --> 00:07:57.930 Eso suena sencillo porque lo es. 00:07:57.930 --> 00:08:00.290 Una clasificación clara evita que las personas 00:08:00.290 --> 00:08:01.370 se pasen el trabajo a ciegas. 00:08:01.690 --> 00:08:03.230 Las reglas de enrutamiento ayudan con esa evaluación. 00:08:03.570 --> 00:08:05.830 Una regla de enrutamiento verifica los detalles de un caso 00:08:05.830 --> 00:08:07.310 y lo envía a la cola o persona correcta. 00:08:07.990 --> 00:08:10.250 Caso sobre un producto específico va al equipo de producto. 00:08:10.710 --> 00:08:12.770 Un caso de una región determinada va al soporte local. 00:08:13.310 --> 00:08:14.890 Un problema grave va a una cola urgente. 00:08:15.370 --> 00:08:16.890 Una pregunta general espera con equipo estándar. 00:08:17.590 --> 00:08:19.690 Algunas organizaciones distribuyen el trabajo según esa habilidad. 00:08:20.050 --> 00:08:21.390 Por ejemplo, un cliente que escribe en francés 00:08:21.390 --> 00:08:22.870 necesita a un agente que hable francés. 00:08:23.210 --> 00:08:24.830 Un problema técnico requiere a alguien capacitado 00:08:24.830 --> 00:08:26.110 en un producto específico. 00:08:26.110 --> 00:08:28.330 El enrutamiento acerca el caso a quien puede resolverlo 00:08:28.330 --> 00:08:30.190 en lugar de tratar todas las solicitudes por igual. 00:08:30.590 --> 00:08:32.630 La automatización ayuda, pero las personas siguen tomando decisión. 00:08:33.030 --> 00:08:34.750 Un líder de equipo podría ver un caso difícil 00:08:34.750 --> 00:08:36.410 y asignarlo directamente a un agente experto. 00:08:36.790 --> 00:08:38.250 Quizás alguien ya conoce al cliente. 00:08:38.830 --> 00:08:40.290 Tal vez el problema abarca varios productos 00:08:40.290 --> 00:08:42.270 y requiere una experiencia que una regla no puede evaluar. 00:08:42.690 --> 00:08:44.390 La asignación manual da al equipo espacio 00:08:44.390 --> 00:08:45.230 para ese criterio humano. 00:08:45.590 --> 00:08:46.830 La responsabilidad puede cambiar durante un caso. 00:08:47.330 --> 00:08:48.830 Un agente podría necesitar más información 00:08:48.830 --> 00:08:49.830 y devolver el caso a una cola. 00:08:50.450 --> 00:08:51.910 Un equipo podría descubrir que el problema 00:08:51.910 --> 00:08:53.130 pertenece a otro departamento 00:08:53.130 --> 00:08:54.130 o una solicitud urgente 00:08:54.130 --> 00:08:55.410 podría necesitar un escalamiento 00:08:55.410 --> 00:08:56.830 si el equipo habitual no puede resolverlo. 00:08:57.530 --> 00:08:59.590 La Dynamics 365 mantiene el trabajo en movimiento 00:08:59.590 --> 00:09:00.950 en lugar de dejarlo estancado con alguien. 00:09:01.710 --> 00:09:03.990 Ahora bien, a veces un problema genera muchos casos. 00:09:04.790 --> 00:09:05.790 Imagina una caída del sistema 00:09:05.790 --> 00:09:06.990 que afecta a docenas de clientes. 00:09:07.530 --> 00:09:09.190 Cada cliente contacta al soporte por separado, 00:09:09.270 --> 00:09:10.690 por lo que cada reporte necesita su propio caso. 00:09:11.150 --> 00:09:13.090 Pero todos los reportes se conectan a un problema mayor. 00:09:13.550 --> 00:09:15.470 Un caso principal rastrea ese problema general, 00:09:15.590 --> 00:09:16.690 mientras que los casos secundarios 00:09:16.690 --> 00:09:17.950 rastrean los reportes individuales 00:09:17.950 --> 00:09:18.910 de los clientes debajo de él. 00:09:19.050 --> 00:09:20.630 Eso le da el equipo de soporte de dos vistas a la vez. 00:09:20.630 --> 00:09:22.130 Trabajan en la caída subyacente 00:09:22.130 --> 00:09:23.170 a través del caso principal, 00:09:23.410 --> 00:09:24.570 mientras que cada caso secundario 00:09:24.570 --> 00:09:25.930 mantiene informado al cliente correspondiente. 00:09:26.250 --> 00:09:27.150 Cuando encuentran la solución, 00:09:27.250 --> 00:09:28.650 investigan la misma caída desde cero 00:09:28.650 --> 00:09:29.630 para cada persona que llama. 00:09:30.150 --> 00:09:30.930 Los casos duplicados 00:09:30.930 --> 00:09:32.350 crean un problema similar a menor escala. 00:09:32.910 --> 00:09:34.090 Un cliente puede enviar un correo 00:09:34.090 --> 00:09:35.130 y llamar por el mismo asunto, 00:09:35.490 --> 00:09:36.890 o dos agentes podrían abrir casos 00:09:36.890 --> 00:09:37.890 antes de anotar el otro. 00:09:38.490 --> 00:09:39.550 En lugar de dividir esfuerzos, 00:09:39.830 --> 00:09:41.270 el equipo puede fusionar casos similares. 00:09:42.050 --> 00:09:43.610 Un caso se convierte en el registro principal 00:09:43.610 --> 00:09:44.670 y el trabajo permanece unido. 00:09:45.090 --> 00:09:46.850 Nadie debería resolver el mismo problema dos veces. 00:09:47.750 --> 00:09:48.530 Llevar un caso a la cola 00:09:48.530 --> 00:09:49.970 y persona correcta se inicia el trabajo 00:09:49.970 --> 00:09:51.170 y el cliente espera una respuesta 00:09:51.170 --> 00:09:52.330 dentro del tiempo prometido. 00:09:53.850 --> 00:09:54.910 Implir promesas con acuerdos 00:09:54.910 --> 00:09:56.170 de nivel de servicio y trabajo guiado. 00:09:57.190 --> 00:09:58.290 Llevar un caso a la persona adecuada 00:09:58.290 --> 00:09:59.250 es solo la mitad del trabajo, 00:09:59.350 --> 00:10:00.510 porque el cliente también espera ayuda 00:10:00.510 --> 00:10:01.590 dentro del tiempo que usted prometió. 00:10:02.030 --> 00:10:02.930 Y ahí es donde entra en juego 00:10:02.930 --> 00:10:04.010 un acuerdo de nivel de servicio, 00:10:04.110 --> 00:10:05.210 lo llamaré SLA. 00:10:06.150 --> 00:10:07.850 Un SLA añade un reloj al caso, 00:10:08.070 --> 00:10:09.170 así el equipo sabe exactamente 00:10:09.170 --> 00:10:09.910 cuánto tiempo tiene 00:10:09.910 --> 00:10:11.110 para cumplir una promesa al cliente, 00:10:11.310 --> 00:10:12.370 ya sea responder por primera vez 00:10:12.370 --> 00:10:13.510 o resolver el problema por completo. 00:10:14.310 --> 00:10:15.450 Pero aquí es donde radica la clave. 00:10:16.030 --> 00:10:17.430 Esos no siempre son los mismos plazos. 00:10:17.430 --> 00:10:18.910 Tomemos a un cliente que espera 00:10:18.910 --> 00:10:20.310 una confirmación de una hora, 00:10:20.510 --> 00:10:21.530 incluso si el equipo técnico 00:10:21.530 --> 00:10:22.570 necesita dos días hábiles 00:10:22.570 --> 00:10:23.890 para encontrar y probar la solución. 00:10:24.670 --> 00:10:26.950 Dynamics 365 realiza un seguimiento 00:10:26.950 --> 00:10:27.870 por separado del objetivo 00:10:27.870 --> 00:10:28.650 de primera respuesta 00:10:28.650 --> 00:10:29.770 y del objetivo de resolución 00:10:29.770 --> 00:10:30.830 para que el equipo pueda actuar 00:10:30.830 --> 00:10:31.690 con rapidez sin fingir 00:10:31.690 --> 00:10:32.910 que todo problema se resolvió al instante. 00:10:33.230 --> 00:10:33.990 Ahora, imagina un cliente 00:10:33.990 --> 00:10:35.250 cuyo servicio ha dejado de funcionar. 00:10:35.910 --> 00:10:37.130 No espera una reparación completa 00:10:37.130 --> 00:10:37.730 en 10 minutos, 00:10:38.070 --> 00:10:39.190 pero sí espera que alguien confirme 00:10:39.190 --> 00:10:40.070 que el problema se conoce, 00:10:40.290 --> 00:10:41.330 explique los pasos a seguir 00:10:41.330 --> 00:10:42.530 y los mantenga informados. 00:10:42.530 --> 00:10:44.250 El objetivo de primera respuesta 00:10:44.250 --> 00:10:45.390 rastrea ese contacto inicial, 00:10:45.510 --> 00:10:46.570 mientras que el objetivo de resolución 00:10:46.570 --> 00:10:47.290 rastrea todo el camino 00:10:47.290 --> 00:10:48.510 hasta obtener una respuesta o solución. 00:10:48.970 --> 00:10:49.730 Y diferentes clientes 00:10:49.730 --> 00:10:50.770 pueden tener diferentes promesas. 00:10:51.150 --> 00:10:52.370 Una empresa con soporte premium 00:10:52.370 --> 00:10:53.490 obtiene objetivos de respuesta 00:10:53.490 --> 00:10:54.510 más rápidos que un cliente 00:10:54.510 --> 00:10:55.070 con un plan estable. 00:10:55.610 --> 00:10:56.830 Una interrupción de alta prioridad 00:10:56.830 --> 00:10:57.850 recibe un plazo menor 00:10:57.850 --> 00:10:58.750 que una pregunta de rutina 00:10:58.750 --> 00:10:59.650 sobre cómo hacer algo. 00:11:00.630 --> 00:11:01.470 Los acuerdos de soporte, 00:11:01.550 --> 00:11:02.610 la prioridad y el tipo de caso 00:11:02.610 --> 00:11:03.990 determinan las reglas de tiempo que se mueven. 00:11:04.270 --> 00:11:05.790 Eso mantiene las promesas justas y claras. 00:11:06.230 --> 00:11:06.810 Sin los SLA, 00:11:06.970 --> 00:11:07.830 un agente podría trabajar 00:11:07.830 --> 00:11:09.190 desde el elemento más antiguo de una lista 00:11:09.190 --> 00:11:10.010 mientras un caso urgente 00:11:10.010 --> 00:11:11.550 supera silenciosamente su fecha límite. 00:11:12.530 --> 00:11:13.570 La pantalla del caso 00:11:13.570 --> 00:11:14.830 muestra indicadores de tiempo 00:11:14.830 --> 00:11:15.550 que le dicen a la gente 00:11:15.550 --> 00:11:16.870 que promesa requiere atención primero. 00:11:17.570 --> 00:11:18.590 Se verá cómo aumenta la presión. 00:11:18.950 --> 00:11:19.970 Un caso con mucho tiempo restante 00:11:19.970 --> 00:11:20.570 necesita trabajo, 00:11:20.710 --> 00:11:21.510 pero un caso que se acerca 00:11:21.510 --> 00:11:22.470 a su fecha límite de respuesta 00:11:22.470 --> 00:11:23.670 necesita atención inmediata. 00:11:24.590 --> 00:11:26.030 Los equipos también pueden establecer 00:11:26.030 --> 00:11:27.050 alertas o pasos de escalada 00:11:27.050 --> 00:11:28.090 cuando un objetivo está cerca 00:11:28.090 --> 00:11:28.570 o haya pasado 00:11:28.570 --> 00:11:30.090 para que un supervisor pueda intervenir 00:11:30.090 --> 00:11:31.450 antes de que el cliente tenga que reclamar. 00:11:32.090 --> 00:11:33.690 Los objetivos de tiempo guían la urgencia 00:11:33.690 --> 00:11:35.110 y los flujos de procesos de negocio 00:11:35.110 --> 00:11:35.930 guían el trabajo en sí. 00:11:36.490 --> 00:11:37.610 Un flujo de proceso de negocio 00:11:37.610 --> 00:11:38.550 es un conjunto de etapas 00:11:38.550 --> 00:11:39.390 que se muestran dentro del caso. 00:11:40.010 --> 00:11:41.210 Le brinda a la gente un camino claro 00:11:41.210 --> 00:11:42.690 a seguir basado en cómo la organización 00:11:42.690 --> 00:11:43.750 desea que se manejen los casos. 00:11:44.450 --> 00:11:45.450 Las etapas pueden avanzar 00:11:45.450 --> 00:11:46.090 desde la recepción, 00:11:46.170 --> 00:11:47.370 la investigación y la resolución 00:11:47.370 --> 00:11:48.010 con las preguntas 00:11:48.010 --> 00:11:48.970 y comprobaciones correctas 00:11:48.970 --> 00:11:49.450 en cada punto. 00:11:49.830 --> 00:11:51.090 Piénselo como una lista de verificación 00:11:51.090 --> 00:11:52.050 con un lugar en el proceso. 00:11:52.410 --> 00:11:52.990 Un agente nuevo 00:11:52.990 --> 00:11:53.790 no tiene que adivinar 00:11:53.790 --> 00:11:54.790 qué detalles son importantes 00:11:54.790 --> 00:11:56.210 antes de enviar un caso a un especialista. 00:11:56.650 --> 00:11:57.930 El flujo puede solicitar el producto, 00:11:58.190 --> 00:11:58.750 el tipo de problema, 00:11:58.910 --> 00:11:59.290 el impacto 00:11:59.290 --> 00:11:59.950 y otra información 00:11:59.950 --> 00:12:01.030 que el siguiente equipo necesite. 00:12:01.550 --> 00:12:02.610 Un agente con más experiencia 00:12:02.610 --> 00:12:03.570 puede moverse más rápido, 00:12:03.690 --> 00:12:04.430 pero el camino compartido 00:12:04.430 --> 00:12:04.990 mantiene al equipo 00:12:04.990 --> 00:12:06.110 trabajando en la misma dirección. 00:12:06.490 --> 00:12:07.070 Aquí hay un escenario. 00:12:07.670 --> 00:12:08.270 Llega una interrupción 00:12:08.270 --> 00:12:09.230 de servicio de alta prioridad. 00:12:09.230 --> 00:12:10.930 El caso entra en la cola urgente 00:12:10.930 --> 00:12:11.930 y su SLA comienza 00:12:11.930 --> 00:12:12.710 la cuenta regresiva. 00:12:13.350 --> 00:12:14.070 El agente confirma 00:12:14.070 --> 00:12:15.050 los detalles del cliente, 00:12:15.430 --> 00:12:16.130 registra el impacto 00:12:16.130 --> 00:12:17.470 y envía la primera respuesta 00:12:17.470 --> 00:12:18.070 antes de que vence 00:12:18.070 --> 00:12:18.950 el objetivo de respuesta. 00:12:19.910 --> 00:12:20.130 Luego, 00:12:20.670 --> 00:12:21.370 el flujo de proceso 00:12:21.370 --> 00:12:21.930 mueve el caso 00:12:21.930 --> 00:12:22.790 a la etapa de diagnóstico, 00:12:23.090 --> 00:12:23.750 donde el equipo reúne 00:12:23.750 --> 00:12:24.370 detalles del error 00:12:24.370 --> 00:12:25.590 y verifica informes relacionados. 00:12:26.190 --> 00:12:27.070 El caso pasa entonces 00:12:27.070 --> 00:12:27.650 a la resolución 00:12:27.650 --> 00:12:28.510 cuando el equipo identifica 00:12:28.510 --> 00:12:28.850 la causa 00:12:28.850 --> 00:12:29.710 y prepara una actualización 00:12:29.710 --> 00:12:30.390 para el cliente. 00:12:31.010 --> 00:12:31.750 Esa secuencia también 00:12:31.750 --> 00:12:32.470 brinda a los gerentes 00:12:32.470 --> 00:12:33.430 una imagen más clara. 00:12:33.830 --> 00:12:34.350 Pueden ver dónde 00:12:34.350 --> 00:12:35.230 se ralentiza el caso 00:12:35.230 --> 00:12:36.010 durante la recepción, 00:12:36.230 --> 00:12:36.770 el diagnóstico 00:12:36.770 --> 00:12:37.990 o la respuesta final del cliente. 00:12:39.230 --> 00:12:40.070 Solver el problema del equipo, 00:12:40.230 --> 00:12:41.370 pero evita que los pasos básicos 00:12:41.370 --> 00:12:42.950 se pierdan durante un día ajetreado. 00:12:43.550 --> 00:12:44.410 Dynamics 365 00:12:44.410 --> 00:12:45.490 también puede controlar 00:12:45.490 --> 00:12:46.170 qué cambios de estado 00:12:46.170 --> 00:12:47.050 pueden elegir los agentes 00:12:47.050 --> 00:12:47.790 en diferentes puntos. 00:12:48.250 --> 00:12:48.690 Se denominan 00:12:48.690 --> 00:12:49.870 transiciones de motivo de estado. 00:12:50.110 --> 00:12:50.670 Suena técnico, 00:12:50.910 --> 00:12:51.710 pero la idea es sencilla, 00:12:51.950 --> 00:12:52.510 pero la es sencilla. 00:12:53.090 --> 00:12:53.810 Un caso debe avanzar 00:12:53.810 --> 00:12:54.670 a través de pasos lógicos. 00:12:55.230 --> 00:12:56.030 No querrá que alguien 00:12:56.030 --> 00:12:57.130 marque un caso como resuelto 00:12:57.130 --> 00:12:57.750 mientras espera 00:12:57.750 --> 00:12:59.030 una verificación interna requerida 00:12:59.030 --> 00:13:00.130 o que pase directamente 00:13:00.130 --> 00:13:01.130 de nuevo a cancelado 00:13:01.130 --> 00:13:02.070 sin registrar el motivo. 00:13:02.830 --> 00:13:03.650 Sus opciones permitidas 00:13:03.650 --> 00:13:04.110 pueden cambiar 00:13:04.110 --> 00:13:05.110 a medida que el caso evolucione. 00:13:05.570 --> 00:13:05.870 Por ejemplo, 00:13:05.950 --> 00:13:06.630 un caso bajo investigación 00:13:06.630 --> 00:13:07.210 puede permitir 00:13:07.210 --> 00:13:07.650 que un agente 00:13:07.650 --> 00:13:08.230 lo ponga en espera 00:13:08.230 --> 00:13:08.990 mientras se aguarda 00:13:08.990 --> 00:13:09.750 detalles del cliente. 00:13:10.530 --> 00:13:11.750 Después de que el cliente responde, 00:13:11.930 --> 00:13:12.770 el agente puede devolverlo 00:13:12.770 --> 00:13:13.430 al trabajo activo. 00:13:13.850 --> 00:13:14.270 Cuando el problema 00:13:14.270 --> 00:13:14.970 está solucionado, 00:13:15.030 --> 00:13:16.050 el caso puede pasar a resuelto. 00:13:16.390 --> 00:13:17.290 Eso crea en el caso más limpio. 00:13:17.890 --> 00:13:18.770 Una respuesta por sí sola 00:13:18.770 --> 00:13:19.470 no termina el trabajo. 00:13:19.710 --> 00:13:20.690 El equipo necesita registrar 00:13:20.690 --> 00:13:21.350 cómo termina el problema 00:13:21.350 --> 00:13:22.810 y luego cerrar el caso correctamente. 00:13:24.210 --> 00:13:24.570 Resolución, 00:13:24.670 --> 00:13:25.650 aprendizaje y mejor servicio. 00:13:26.870 --> 00:13:27.490 Viar una respuesta 00:13:27.490 --> 00:13:28.770 no cierra automáticamente un caso. 00:13:29.190 --> 00:13:30.010 El equipo debe registrar 00:13:30.010 --> 00:13:30.550 la resolución, 00:13:30.650 --> 00:13:31.410 lo que significa anotar 00:13:31.410 --> 00:13:32.290 qué solucionó el problema 00:13:32.290 --> 00:13:33.130 o qué respuesta final 00:13:33.130 --> 00:13:33.950 recibió el cliente. 00:13:34.610 --> 00:13:35.370 Eso podría ser 00:13:35.370 --> 00:13:36.670 dispositivo de reemplazo enviado, 00:13:36.790 --> 00:13:37.950 pago duplicado o reembolsado 00:13:37.950 --> 00:13:38.730 o el cliente actualizó 00:13:38.730 --> 00:13:39.510 el ajuste que bloqueaba 00:13:39.510 --> 00:13:39.930 el acceso. 00:13:40.930 --> 00:13:41.510 Esa nota pasa 00:13:41.510 --> 00:13:42.030 a formar parte 00:13:42.030 --> 00:13:42.950 del registro del cliente 00:13:42.950 --> 00:13:43.870 y brinda al siguiente agente 00:13:43.870 --> 00:13:44.790 un punto de partida útil. 00:13:45.010 --> 00:13:45.670 Si el mismo cliente 00:13:45.670 --> 00:13:46.370 contacta al soporte 00:13:46.370 --> 00:13:46.910 meses después 00:13:46.910 --> 00:13:48.030 con un problema relacionado, 00:13:48.710 --> 00:13:49.570 a veces la primera solución 00:13:49.570 --> 00:13:49.950 no funciona. 00:13:50.310 --> 00:13:50.990 Quizás el cliente 00:13:50.990 --> 00:13:51.830 sigue las instrucciones 00:13:51.830 --> 00:13:52.850 y el error vuelve a aparecer. 00:13:53.370 --> 00:13:54.070 Tal vez llegue una pieza 00:13:54.070 --> 00:13:54.510 de repuesto 00:13:54.510 --> 00:13:55.470 pero no resuelve la falla. 00:13:56.090 --> 00:13:56.690 En esa situación, 00:13:56.830 --> 00:13:58.070 el equipo puede reabrir el caso 00:13:58.070 --> 00:13:58.850 o volver a colocarlo 00:13:58.850 --> 00:13:59.190 en la cola 00:13:59.190 --> 00:13:59.990 para seguir trabajando 00:13:59.990 --> 00:14:00.990 en lugar de iniciar 00:14:00.990 --> 00:14:01.630 un registro nuevo 00:14:01.630 --> 00:14:02.270 sin historial. 00:14:03.310 --> 00:14:03.870 El caso continúa 00:14:03.870 --> 00:14:04.490 desde donde el equipo 00:14:04.490 --> 00:14:04.870 lo dejó. 00:14:05.310 --> 00:14:05.850 Eso es importante 00:14:05.850 --> 00:14:06.650 cuando cambia la propiedad. 00:14:06.870 --> 00:14:07.390 Un nuevo agente 00:14:07.390 --> 00:14:08.270 puede ver lo que intentó 00:14:08.270 --> 00:14:08.890 el agente anterior, 00:14:09.050 --> 00:14:09.930 lo que confirmó el cliente 00:14:09.930 --> 00:14:11.270 y lo que aún debe verificarse. 00:14:12.010 --> 00:14:12.470 El cliente 00:14:12.470 --> 00:14:13.390 no necesita explicar 00:14:13.390 --> 00:14:13.950 toda la historia 00:14:13.950 --> 00:14:14.550 desde el principio 00:14:14.550 --> 00:14:15.430 solo porque otra persona 00:14:15.430 --> 00:14:16.150 retomó el trabajo. 00:14:16.790 --> 00:14:17.270 Con el tiempo, 00:14:17.430 --> 00:14:18.030 todos esos casos 00:14:18.030 --> 00:14:18.590 también indican 00:14:18.590 --> 00:14:19.330 al equipo de soporte 00:14:19.330 --> 00:14:19.830 lo que sucede 00:14:19.830 --> 00:14:20.810 más allá de un solo problema 00:14:20.810 --> 00:14:21.330 de un cliente. 00:14:21.690 --> 00:14:22.110 Los gerentes 00:14:22.110 --> 00:14:22.810 pueden ver el tiempo 00:14:22.810 --> 00:14:23.430 de resolución 00:14:23.430 --> 00:14:24.150 que rastrea 00:14:24.150 --> 00:14:25.130 cuánto tardan los casos 00:14:25.130 --> 00:14:25.810 desde la apertura 00:14:25.810 --> 00:14:26.350 hasta el cierre. 00:14:26.990 --> 00:14:27.530 Pueden ver el tiempo 00:14:29.990 --> 00:14:30.870 también pueden observar 00:14:30.870 --> 00:14:31.370 la resolución 00:14:31.370 --> 00:14:32.190 en el primer contacto, 00:14:32.330 --> 00:14:32.790 lo que significa 00:14:32.790 --> 00:14:33.490 con qué frecuencia 00:14:33.490 --> 00:14:34.110 la primera persona 00:14:34.110 --> 00:14:34.830 que habla con el cliente 00:14:34.830 --> 00:14:35.210 puede resolver 00:14:35.210 --> 00:14:35.510 el problema 00:14:35.510 --> 00:14:36.150 sin transferencia. 00:14:36.730 --> 00:14:37.230 La carga del trabajo 00:14:37.230 --> 00:14:37.470 también. 00:14:37.930 --> 00:14:38.890 Si una cola se llena 00:14:38.890 --> 00:14:39.910 cada lunes por la mañana, 00:14:40.050 --> 00:14:40.810 el equipo puede verlo. 00:14:41.210 --> 00:14:42.110 Si los casos técnicos 00:14:42.110 --> 00:14:42.670 pasan días 00:14:42.670 --> 00:14:43.890 esperando una revisión interna, 00:14:44.110 --> 00:14:44.590 ese retraso 00:14:44.590 --> 00:14:45.190 aparece en los datos 00:14:45.190 --> 00:14:45.590 del caso. 00:14:46.090 --> 00:14:46.570 Si un equipo 00:14:46.570 --> 00:14:47.670 cierra casos rápidamente 00:14:47.670 --> 00:14:48.230 pero los clientes 00:14:48.230 --> 00:14:49.050 siguen reabriéndolos, 00:14:49.310 --> 00:14:50.190 el equipo tiene motivos 00:14:50.190 --> 00:14:50.830 para examinar mejor 00:14:50.830 --> 00:14:51.170 la calidad 00:14:51.170 --> 00:14:52.090 de esas primeras soluciones. 00:14:52.930 --> 00:14:53.290 Los números 00:14:53.290 --> 00:14:54.030 no explican todo 00:14:54.030 --> 00:14:54.630 por sí solos, 00:14:55.070 --> 00:14:55.570 guían al equipo 00:14:55.570 --> 00:14:56.250 sobre qué preguntas 00:14:56.250 --> 00:14:56.690 vale la pena. 00:14:56.690 --> 00:14:58.110 ¿Por qué aumentan 00:14:58.110 --> 00:14:58.430 los casos 00:14:58.430 --> 00:14:59.410 sobre un producto específico? 00:14:59.510 --> 00:15:00.270 ¿Por qué cierto tipo 00:15:00.270 --> 00:15:00.950 de caso tarda 00:15:00.950 --> 00:15:01.910 más de lo esperado? 00:15:02.490 --> 00:15:03.190 ¿Por qué los agentes 00:15:03.190 --> 00:15:04.030 buscan repetidamente 00:15:04.030 --> 00:15:04.830 la misma respuesta 00:15:04.830 --> 00:15:05.370 sin encontrar 00:15:05.370 --> 00:15:06.530 un artículo de ayuda útil? 00:15:07.170 --> 00:15:07.990 Los patrones convierten 00:15:07.990 --> 00:15:08.610 el trabajo diario 00:15:08.610 --> 00:15:09.010 de soporte 00:15:09.010 --> 00:15:09.770 en aprendizaje práctico. 00:15:10.190 --> 00:15:10.530 Un aumento 00:15:10.530 --> 00:15:11.190 en casos similares 00:15:11.190 --> 00:15:11.610 puede señalar 00:15:11.610 --> 00:15:12.410 un fallo del producto. 00:15:12.810 --> 00:15:13.190 Puede mostrar 00:15:13.190 --> 00:15:13.810 que una actualización 00:15:13.810 --> 00:15:14.530 reciente confundió 00:15:14.530 --> 00:15:14.950 a los clientes. 00:15:15.270 --> 00:15:15.750 Puede revelar 00:15:15.750 --> 00:15:16.130 que una guía 00:15:16.130 --> 00:15:16.630 de instrucciones 00:15:16.630 --> 00:15:17.690 necesita pasos más claros. 00:15:18.250 --> 00:15:18.770 En lugar de tratar 00:15:18.770 --> 00:15:19.450 cada solicitud 00:15:19.450 --> 00:15:20.130 como algo aislado, 00:15:20.250 --> 00:15:21.030 el equipo puede identificar 00:15:21.030 --> 00:15:21.630 la causa común 00:15:21.630 --> 00:15:22.290 y trabajar en ella. 00:15:22.630 --> 00:15:23.230 Eso puede reducir 00:15:23.230 --> 00:15:23.490 el volumen 00:15:23.490 --> 00:15:24.010 de casos futuros. 00:15:24.390 --> 00:15:24.810 Los comentarios 00:15:24.810 --> 00:15:25.290 de los clientes 00:15:25.290 --> 00:15:25.830 también fueron parte 00:15:25.830 --> 00:15:26.090 de ese problema. 00:15:26.390 --> 00:15:27.090 Un caso cerrado 00:15:27.090 --> 00:15:27.550 puede mostrar 00:15:27.550 --> 00:15:27.990 que el equipo 00:15:27.990 --> 00:15:28.890 cumplió con su objetivo 00:15:28.890 --> 00:15:29.410 de respuesta, 00:15:29.570 --> 00:15:29.950 pero el cliente 00:15:29.950 --> 00:15:30.910 puede sentirse frustrado 00:15:30.910 --> 00:15:31.710 si tuvo que contactar 00:15:31.710 --> 00:15:32.650 a soporte tres veces. 00:15:33.610 --> 00:15:34.130 Analizar tanto 00:15:34.130 --> 00:15:34.790 el historial del caso 00:15:34.790 --> 00:15:35.350 como los comentarios 00:15:35.350 --> 00:15:36.090 ofrece a los gerentes 00:15:36.090 --> 00:15:36.890 una visión más completa 00:15:36.890 --> 00:15:37.290 de la experiencia. 00:15:37.710 --> 00:15:38.270 Algunos clientes 00:15:38.270 --> 00:15:38.950 preferirían evitar 00:15:38.950 --> 00:15:39.890 crear un caso por completo. 00:15:40.150 --> 00:15:40.430 Ahí es donde 00:15:40.430 --> 00:15:41.190 un portal de autoservicio 00:15:41.190 --> 00:15:41.570 puede ayudar. 00:15:41.970 --> 00:15:42.770 A través de un portal, 00:15:42.930 --> 00:15:43.350 los clientes 00:15:43.350 --> 00:15:44.270 pueden crear una solicitud, 00:15:44.610 --> 00:15:45.390 verificar su estado, 00:15:45.670 --> 00:15:46.590 agregar información nueva 00:15:46.590 --> 00:15:47.410 o leer artículos 00:15:47.410 --> 00:15:48.150 de soporte aprobados 00:15:48.150 --> 00:15:48.750 sin llamar al equipo 00:15:48.750 --> 00:15:49.370 de asistencia. 00:15:50.150 --> 00:15:51.210 Para preguntas sencillas, 00:15:51.370 --> 00:15:51.870 eso puede ahorrar 00:15:51.870 --> 00:15:52.530 tiempo a todos. 00:15:53.070 --> 00:15:53.970 Un cliente puede consultar 00:15:53.970 --> 00:15:54.710 el estado del entregado 00:15:54.710 --> 00:15:55.170 o seguir una guía 00:15:55.170 --> 00:15:55.690 de configuración 00:15:55.690 --> 00:15:56.670 cuando le resulte conveniente. 00:15:57.550 --> 00:15:58.050 Mientras tanto, 00:15:58.110 --> 00:15:58.930 los agentes pueden dedicar 00:15:58.930 --> 00:15:59.710 más tiempo a problemas 00:15:59.710 --> 00:16:00.150 que requieren 00:16:00.150 --> 00:16:01.070 que una persona investigue, 00:16:01.190 --> 00:16:02.390 explique o tome una decisión. 00:16:02.930 --> 00:16:04.770 Dynamics 365 Customer Service 00:16:04.770 --> 00:16:05.650 también puede conectarse 00:16:05.650 --> 00:16:06.570 con herramientas familiares 00:16:06.570 --> 00:16:07.050 de Microsoft 00:16:07.050 --> 00:16:07.870 para el proceso de caso. 00:16:08.170 --> 00:16:08.930 Un agente puede trabajar 00:16:08.930 --> 00:16:09.690 con el correo electrónico 00:16:09.690 --> 00:16:10.170 a través de Apple. 00:16:10.410 --> 00:16:11.330 Un equipo puede debatir 00:16:11.330 --> 00:16:12.350 un problema difícil en Teams. 00:16:12.850 --> 00:16:13.370 Los documentos 00:16:13.370 --> 00:16:14.230 y la información compartida 00:16:14.230 --> 00:16:15.130 pueden anunciar sin share. 00:16:15.390 --> 00:16:16.530 Power BI puede convertir 00:16:16.530 --> 00:16:17.350 los datos de los casos 00:16:17.350 --> 00:16:18.330 en informes y paneles, 00:16:18.330 --> 00:16:19.330 mientras que las herramientas 00:16:19.330 --> 00:16:19.930 de Power Platform 00:16:19.930 --> 00:16:20.550 pueden respaldar 00:16:20.550 --> 00:16:21.430 formularios adicionales, 00:16:21.510 --> 00:16:22.590 alertas o pasos automatizados 00:16:22.590 --> 00:16:23.370 en todo el proceso del equipo. 00:16:23.710 --> 00:16:24.190 Cada herramienta 00:16:24.190 --> 00:16:24.830 tiene su propia función. 00:16:25.250 --> 00:16:26.010 El caso sigue siendo 00:16:26.010 --> 00:16:26.830 el lugar donde el problema 00:16:26.830 --> 00:16:27.810 de soporte y su historial 00:16:27.810 --> 00:16:28.710 se mantienen conectados, 00:16:28.770 --> 00:16:29.630 incluso cuando las personas 00:16:29.630 --> 00:16:30.490 usan otras herramientas 00:16:30.490 --> 00:16:31.110 para comunicarse, 00:16:31.190 --> 00:16:31.730 compartir archivos 00:16:31.730 --> 00:16:32.370 o revisar el trabajo. 00:16:32.750 --> 00:16:33.310 La gestión de casos 00:16:33.310 --> 00:16:33.930 no trata realmente 00:16:33.930 --> 00:16:34.710 de completar una pantalla 00:16:34.710 --> 00:16:35.030 de ticket. 00:16:35.570 --> 00:16:36.210 Se trata de darle 00:16:36.210 --> 00:16:37.110 a cada problema del cliente 00:16:37.110 --> 00:16:37.610 un camino claro 00:16:37.610 --> 00:16:38.590 a una respuesta registrada 00:16:38.590 --> 00:16:38.930 y un equipo 00:16:38.930 --> 00:16:39.390 que pueda aprender 00:16:39.390 --> 00:16:39.910 de lo sucedido. 00:16:41.030 --> 00:16:41.390 Conclusión 00:16:41.390 --> 00:16:42.710 Dan tenga toda la historia 00:16:42.710 --> 00:16:43.430 del cliente unificado. 00:16:44.130 --> 00:16:45.070 Esta es la conclusión real. 00:16:45.070 --> 00:16:46.830 La gestión de casos 00:16:46.830 --> 00:16:47.670 de Dynamics 365 00:16:47.670 --> 00:16:48.630 mantiene el problema, 00:16:48.950 --> 00:16:49.370 el trabajo, 00:16:49.470 --> 00:16:50.050 las promesas 00:16:50.050 --> 00:16:50.590 y el resultado 00:16:50.590 --> 00:16:51.650 en un solo registro. 00:16:52.330 --> 00:16:53.270 Se acabó el contexto perdido 00:16:53.270 --> 00:16:54.090 de las soluciones repetidas. 00:16:54.330 --> 00:16:55.270 Observe su propio proceso 00:16:55.270 --> 00:16:56.790 por donde desaparece 00:16:56.790 --> 00:16:57.710 la información del cliente. 00:16:58.350 --> 00:16:59.170 Ahí es donde reunir 00:16:59.170 --> 00:17:00.250 todo lo cambia por completo. 00:17:01.010 --> 00:17:01.990 Suscríbase en su plataforma 00:17:01.990 --> 00:17:02.790 de podcast favorita 00:17:02.790 --> 00:17:03.830 para obtener más información 00:17:03.830 --> 00:17:04.450 sobre Microsoft. 00:17:04.530 --> 00:17:04.910 De mi parte, 00:17:05.130 --> 00:17:06.990 Mirko Peters en M365.fm 00:17:06.990 --> 00:17:07.690 donde explicamos 00:17:07.690 --> 00:17:08.590 las herramientas de Microsoft 00:17:08.590 --> 00:17:09.550 detrás del trabajo diario 00:17:09.550 --> 00:17:10.330 en lenguaje sencillo.