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ó, y repiten la misma historia cada vez mientras su equipo de soporte busca entre bandejas de entrada, notas y herramientas separadas. Eso es exactamente lo que soluciona la gestión de casos de Dynamics 365. Piensa en un caso como una carpeta etiquetada dentro de un edificio de oficinas concurrido, donde cada parte del problema de un cliente entra en esa carpeta de la primera pregunta hasta la respuesta final. Usted es Mirko Peters de M365FM, y en esta cápsula de conocimiento verá cómo los casos, el enrutamiento, los plazos de respuesta, los artículos de soporte y el cierre encajan perfectamente, lo que es realmente un caso en 20 palabras. Entonces, ¿qué es exactamente un caso? Un caso es un registro para un problema de un cliente que necesita una respuesta o solución.

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. Aquí está el detalle, un cliente puede tener varios casos a la vez. 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. 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. Cuando un agente crea un caso, lo vincula directamente al cliente. Ese cliente puede ser un contacto, es decir, una persona individual o una cuenta, refiriéndose a la empresa para la que trabaja. Entonces, si Jamie de Northwind Traders reporta un problema, el caso puede señalar tanto a Jamie como a la empresa, y cualquiera que abra el registro puede ver quién necesita ayuda y a qué organización pertenece el problema.

El caso también necesita una descripción clara del problema, normalmente empezando con un título como Nuestra impresora se detiene tras actualización de software, o Cliente cobrado dos veces por plan anual, y ese título ayuda a escanear una lista de casos abiertos sin abrir cada registro, sin abrir cada registro. Debajo de ese título, el agente añade los detalles. ¿Qué sucedió? ¿Cuándo empezó? ¿Qué ha intentado ya el cliente? ¿Qué producto involucró? Y si se trata de una pregunta o una solicitud o una falla. Estos detalles convierten un mensaje vago en trabajo que alguien puede asumir y resolver. Desglosémoslo aún más. Un caso puede contener un asunto, producto o prioridad del tipo de caso. El asunto agrupa el problema en un área como facturación o soporte técnico, el producto identifica qué usa el cliente, la prioridad indica al equipo, qué tan rápido es revisarlo, y el tipo de caso ofrece otra forma de clasificar el trabajo según su proceso de soporte.

Ninguno de estos campos resuelve el problema de cliente por sí solo, pero ayudan al equipo de soporte a ver el trabajo con claridad, especialmente cuando llegan cientos de casos de distintos clientes. Un equipo que maneja un fallo grave del servicio no debería tener que buscar entre preguntas generales para encontrarlo. Ahora bien, un caso no es solo un formulario que alguien llena y olvida. Se convierte en el registro de trabajo para toda la conversación. Los correos se conectan al caso. Las llamadas telefónicas pueden aparecer ahí y un agente puede añadir notas tras un chat, configurar una tarea de seguimiento o registrar una cita. Cada actividad permanece ligada al mismo problema del cliente, por lo que la siguiente persona no tiene que reconstruir la historia desde cero. Imagina que un agente comienza a trabajar por la mañana, y luego transfiere el caso a un especialista de producto después del almuerzo.

Si en un registro del caso, el especialista podría recibir un mensaje breve como, ¿podría revisar esto? Lo cual no es suficiente. Con el registro del caso, pueden ver el problema original, los detalles del cliente, lo ocurrido durante la llamada, y lo que el primer agente ya verificó. Eso ofrece una transferencia mucho más. Dynamics 365 mantiene el caso en un estado claro a medida que avanza por el proceso de soporte. Puede permanecer activo mientras el equipo investiga, y una vez que el equipo soluciona el problema o da la respuesta final, lo resuelve. Si la solicitud ya no requiere trabajo, quizá llegó por error o el cliente se retractó, el equipo puede cancelarla. Activo, resuelto y cancelado. Esos tres estados dan al equipo una visión compartida del estado de cada problema. Así, nadie debe adivinar si un caso aún requiere atención, y los gerentes no tienen que tratar trabajo antiguo y terminado como si fuera un problema nuevo.

Un registro da control y el historial completo del cliente le da contexto a la gente. La historia del cliente detrás del caso. Un caso te dice que necesitas ser reparado. El registro del cliente te dice que llegó a este momento. Cuando un agente abre un caso en Dynamics 365 Customer Service, puede mirar más allá del último mensaje. Ven el panorama general, casos anteriores, correos pasados, los productos conectados al cliente y su historial de soporte. El contexto cambia la conversación. ¿Por qué importa el contexto? Imagina que un cliente reporta el fallo en dispositivo. Si el agente solo ve el mensaje de hoy, es posible que comience con preguntas básicas. ¿Qué modelo es? ¿Cuándo comenzó? ¿Lo reinició? Pero el cliente ya se ha puesto en contacto con soporte dos veces ese semana. El primer agente envió pasos de solución, el segundo gestiona una pieza de repuesto. Un tercer agente que ve ese historial no le pedirá al cliente que comience de cero.

En cambio dirá, veo que ya intentó esos pasos y que el repuesto no solucione el problema. Probemos con lo siguiente. Eso se siente muy distinto a ¿Puedo explicarme el problema de nuevo? Esto a menudo se llama una vista del cliente de 360 grados. Nombre suena sofisticado, pero es sencillo. Significa que el agente ve al cliente desde más de un ángulo, no solo por un mensaje aislado. El agente ve a la persona, ve a la empresa, ve solicitudes de soporte anteriores, conversaciones previas y los productos conectados a ellos. Tal un equipo de soportes o reemplaza las suposiciones como punto de partida clara. Ahora bien, no todos los clientes reciben el mismo tipo de soporte. Un cliente puede haber comprado una garantía, su empresa puede pagar por un número fijo de horas de soporte, o puede tener un contrato que permita cierto número de casos o soporte premium con asistencia más rápida. Dynamics 365 rastrea todo esto mediante derechos.

Un derecho es el acuerdo de soporte al cliente dentro del sistema. Piense en ello como los términos de servicio vinculados a su cuenta. Antes de que un agente prometa a un técnico o comience un trabajo con costo, verifica qué soporte aplica. Eso evita sorpresas incómodas. Por ejemplo, un cliente podría tener aún cobertura de garantía para un producto de efecto. El caso puede seguir ese camino. Otro cliente podría haber agotado todas sus horas de soporte. El agente lo ve antes de comprometerse a realizar trabajos fuera de la cuerda. También ayuda al equipo de soporte a tratar a los clientes de manera justa. El agente no necesita buscar en contratos antiguos ni preguntar a otro departamento. Los términos de soporte están junto a la información del cliente donde la gente puede encontrarlos. Luego está la base de conocimiento. Los equipos de soporte resuelven los mismos problemas una y otra.

Reestablecimiento de contraseñas, instrucciones de configuración, un error conocido tras una actualización, una pregunta de facturación con una respuesta. Un artículo de conocimiento almacena esa respuesta en un solo blog. Dentro del espacio de trabajo de servicio, un agente puede buscar artículos mientras trabaja en un caso. Un artículo puede incluir una explicación sencilla, pasos, una captura de pantalla o las comprobaciones exactas que el equipo debe realizar. En lugar de que cada agente escriba su propia versión de memoria usando la respuesta compartida que el equipo ha revisado, eso mantiene la consistencia de su blog. También ayuda a los agentes nuevos. No necesitan años de experiencia para resolver problemas comunes bien, porque las soluciones conocidas del equipo están disponibles cuando las requieren. Los resúmenes de casos de Copilot ayudan con otro problema común, los historiales de casos lag.

Un caso puede acumular muchos correos, notas y actualizaciones con el paso del día. Leerlos todos toma tiempo, especialmente después de una transferencia. Copilot crea un breve resumen del caso que reúne el título, el cliente, el asunto, el producto, la prioridad, el tipo de caso, la descripción, la actividad reciente. Es una sesión informativa rápida antes de que la gente cambie se atreva. La gente aún revisa el registro y usa su criterio, pero entiende la situación más rápido. Eso ayuda cuando el cliente está esperando y el caso ha pasado por varias manos. Una vez que la gente comprende el cliente y el problema, el caso debe llegar a la persona adecuada.

Desde la recepción hasta la cola correcta. Un cliente puede pedir ayuda en muchas maneras, correo electrónico, llamada telefónica, chat, redes sociales o un portal de autoservicio. El canal cambia, pero el equipo de soporte aún necesita un lugar claro para gestionar la solicitud. Dynamics 365 puede crear casos a partir de esas conversaciones cuando la configuración incluye reglas de creación de registros. Piensa en un correo electrónico que llegue a una dirección de soporte compartida. En lugar de dejarlo en un buzón hasta que alguien lo vea, una regla convierte ese correo en un caso. El mensaje se convierte en el inicio del trabajo dentro del servicio. Eso reduce la necesidad de cober información manual. La misma idea se aplica a otros canales conectados. El equipo elige qué mensajes crea un caso nuevo y cuáles pertenecen a uno existente. Una respuesta a un problema abierto permanece problema.

Una pregunta nueva obtiene su propio caso. Entonces, el caso necesita un lugar donde estar mientras alguien asuma la hermosa. Ese lugar suele ser una cola. Una cola es una bandeja de trabajo compartida por un equipo. No es la bandeja de entrada de un agente y no pertenece a la persona que vio la solicitud. En cambio, le da a todo el equipo un lugar para ver el trabajo que espera atención. Imagina una empresa con un equipo de facturación, uno de soporte técnico y uno de devoluciones. Cada equipo tiene su propia cola. Las dudas de facturación van a facturación, los fallos de producto del soporte técnico y las solicitudes de devolución a quienes conocen el proceso. Eso suena sencillo porque lo es. Una clasificación clara evita que las personas se pasen el trabajo a ciegas. Las reglas de enrutamiento ayudan con esa evaluación. Una regla de enrutamiento verifica los detalles de un caso y lo envía a la cola o persona correcta.

Caso sobre un producto específico va al equipo de producto. Un caso de una región determinada va al soporte local. Un problema grave va a una cola urgente. Una pregunta general espera con equipo estándar. Algunas organizaciones distribuyen el trabajo según esa habilidad. Por ejemplo, un cliente que escribe en francés necesita a un agente que hable francés. Un problema técnico requiere a alguien capacitado en un producto específico. El enrutamiento acerca el caso a quien puede resolverlo en lugar de tratar todas las solicitudes por igual. La automatización ayuda, pero las personas siguen tomando decisión. Un líder de equipo podría ver un caso difícil y asignarlo directamente a un agente experto. Quizás alguien ya conoce al cliente. Tal vez el problema abarca varios productos y requiere una experiencia que una regla no puede evaluar. La asignación manual da al equipo espacio para ese criterio humano.

La responsabilidad puede cambiar durante un caso. Un agente podría necesitar más información y devolver el caso a una cola. Un equipo podría descubrir que el problema pertenece a otro departamento o una solicitud urgente podría necesitar un escalamiento si el equipo habitual no puede resolverlo. La Dynamics 365 mantiene el trabajo en movimiento en lugar de dejarlo estancado con alguien. Ahora bien, a veces un problema genera muchos casos. Imagina una caída del sistema que afecta a docenas de clientes. Cada cliente contacta al soporte por separado, por lo que cada reporte necesita su propio caso. Pero todos los reportes se conectan a un problema mayor. Un caso principal rastrea ese problema general, mientras que los casos secundarios rastrean los reportes individuales de los clientes debajo de él. Eso le da el equipo de soporte de dos vistas a la vez. Trabajan en la caída subyacente a través del caso principal, mientras que cada caso secundario mantiene informado al cliente correspondiente.

Cuando encuentran la solución, investigan la misma caída desde cero para cada persona que llama. Los casos duplicados crean un problema similar a menor escala. Un cliente puede enviar un correo y llamar por el mismo asunto, o dos agentes podrían abrir casos antes de anotar el otro. En lugar de dividir esfuerzos, el equipo puede fusionar casos similares. Un caso se convierte en el registro principal y el trabajo permanece unido. Nadie debería resolver el mismo problema dos veces. Llevar un caso a la cola y persona correcta se inicia el trabajo y el cliente espera una respuesta dentro del tiempo prometido. Implir promesas con acuerdos de nivel de servicio y trabajo guiado. Llevar un caso a la persona adecuada es solo la mitad del trabajo, porque el cliente también espera ayuda dentro del tiempo que usted prometió. Y ahí es donde entra en juego un acuerdo de nivel de servicio, lo llamaré SLA.

Un SLA añade un reloj al caso, así el equipo sabe exactamente cuánto tiempo tiene para cumplir una promesa al cliente, ya sea responder por primera vez o resolver el problema por completo. Pero aquí es donde radica la clave. Esos no siempre son los mismos plazos. Tomemos a un cliente que espera una confirmación de una hora, incluso si el equipo técnico necesita dos días hábiles para encontrar y probar la solución. Dynamics 365 realiza un seguimiento por separado del objetivo de primera respuesta y del objetivo de resolución para que el equipo pueda actuar con rapidez sin fingir que todo problema se resolvió al instante. Ahora, imagina un cliente cuyo servicio ha dejado de funcionar. No espera una reparación completa en 10 minutos, pero sí espera que alguien confirme que el problema se conoce, explique los pasos a seguir y los mantenga informados. El objetivo de primera respuesta rastrea ese contacto inicial, mientras que el objetivo de resolución rastrea todo el camino hasta obtener una respuesta o solución.

Y diferentes clientes pueden tener diferentes promesas. Una empresa con soporte premium obtiene objetivos de respuesta más rápidos que un cliente con un plan estable. Una interrupción de alta prioridad recibe un plazo menor que una pregunta de rutina sobre cómo hacer algo. Los acuerdos de soporte, la prioridad y el tipo de caso determinan las reglas de tiempo que se mueven. Eso mantiene las promesas justas y claras. Sin los SLA, un agente podría trabajar desde el elemento más antiguo de una lista mientras un caso urgente supera silenciosamente su fecha límite. La pantalla del caso muestra indicadores de tiempo que le dicen a la gente que promesa requiere atención primero. Se verá cómo aumenta la presión. Un caso con mucho tiempo restante necesita trabajo, pero un caso que se acerca a su fecha límite de respuesta necesita atención inmediata. Los equipos también pueden establecer alertas o pasos de escalada cuando un objetivo está cerca o haya pasado para que un supervisor pueda intervenir antes de que el cliente tenga que reclamar.

Los objetivos de tiempo guían la urgencia y los flujos de procesos de negocio guían el trabajo en sí. Un flujo de proceso de negocio es un conjunto de etapas que se muestran dentro del caso. Le brinda a la gente un camino claro a seguir basado en cómo la organización desea que se manejen los casos. Las etapas pueden avanzar desde la recepción, la investigación y la resolución con las preguntas y comprobaciones correctas en cada punto. Piénselo como una lista de verificación con un lugar en el proceso. Un agente nuevo no tiene que adivinar qué detalles son importantes antes de enviar un caso a un especialista. El flujo puede solicitar el producto, el tipo de problema, el impacto y otra información que el siguiente equipo necesite. Un agente con más experiencia puede moverse más rápido, pero el camino compartido mantiene al equipo trabajando en la misma dirección. Aquí hay un escenario. Llega una interrupción de servicio de alta prioridad.

El caso entra en la cola urgente y su SLA comienza la cuenta regresiva. El agente confirma los detalles del cliente, registra el impacto y envía la primera respuesta antes de que vence el objetivo de respuesta. Luego, el flujo de proceso mueve el caso a la etapa de diagnóstico, donde el equipo reúne detalles del error y verifica informes relacionados. El caso pasa entonces a la resolución cuando el equipo identifica la causa y prepara una actualización para el cliente. Esa secuencia también brinda a los gerentes una imagen más clara. Pueden ver dónde se ralentiza el caso durante la recepción, el diagnóstico o la respuesta final del cliente. Solver el problema del equipo, pero evita que los pasos básicos se pierdan durante un día ajetreado. Dynamics 365 también puede controlar qué cambios de estado pueden elegir los agentes en diferentes puntos. Se denominan transiciones de motivo de estado.

Suena técnico, pero la idea es sencilla, pero la es sencilla. Un caso debe avanzar a través de pasos lógicos. No querrá que alguien marque un caso como resuelto mientras espera una verificación interna requerida o que pase directamente de nuevo a cancelado sin registrar el motivo. Sus opciones permitidas pueden cambiar a medida que el caso evolucione. Por ejemplo, un caso bajo investigación puede permitir que un agente lo ponga en espera mientras se aguarda detalles del cliente. Después de que el cliente responde, el agente puede devolverlo al trabajo activo. Cuando el problema está solucionado, el caso puede pasar a resuelto. Eso crea en el caso más limpio. Una respuesta por sí sola no termina el trabajo. El equipo necesita registrar cómo termina el problema y luego cerrar el caso correctamente. Resolución, aprendizaje y mejor servicio. Viar una respuesta no cierra automáticamente un caso.

El equipo debe registrar la resolución, lo que significa anotar qué solucionó el problema o qué respuesta final recibió el cliente. Eso podría ser dispositivo de reemplazo enviado, pago duplicado o reembolsado o el cliente actualizó el ajuste que bloqueaba el acceso. Esa nota pasa a formar parte del registro del cliente y brinda al siguiente agente un punto de partida útil. Si el mismo cliente contacta al soporte meses después con un problema relacionado, a veces la primera solución no funciona. Quizás el cliente sigue las instrucciones y el error vuelve a aparecer. Tal vez llegue una pieza de repuesto pero no resuelve la falla. En esa situación, el equipo puede reabrir el caso o volver a colocarlo en la cola para seguir trabajando en lugar de iniciar un registro nuevo sin historial. El caso continúa desde donde el equipo lo dejó. Eso es importante cuando cambia la propiedad. Un nuevo agente puede ver lo que intentó el agente anterior, lo que confirmó el cliente y lo que aún debe verificarse.

El cliente no necesita explicar toda la historia desde el principio solo porque otra persona retomó el trabajo. Con el tiempo, todos esos casos también indican al equipo de soporte lo que sucede más allá de un solo problema de un cliente. Los gerentes pueden ver el tiempo de resolución que rastrea cuánto tardan los casos desde la apertura hasta el cierre. Pueden ver el tiempo

también pueden observar la resolución en el primer contacto, lo que significa con qué frecuencia la primera persona que habla con el cliente puede resolver el problema sin transferencia. La carga del trabajo también. Si una cola se llena cada lunes por la mañana, el equipo puede verlo. Si los casos técnicos pasan días esperando una revisión interna, ese retraso aparece en los datos del caso. Si un equipo cierra casos rápidamente pero los clientes siguen reabriéndolos, el equipo tiene motivos para examinar mejor la calidad de esas primeras soluciones. Los números no explican todo por sí solos, guían al equipo sobre qué preguntas vale la pena. ¿Por qué aumentan los casos sobre un producto específico? ¿Por qué cierto tipo de caso tarda más de lo esperado? ¿Por qué los agentes buscan repetidamente la misma respuesta sin encontrar un artículo de ayuda útil? Los patrones convierten el trabajo diario de soporte en aprendizaje práctico.

Un aumento en casos similares puede señalar un fallo del producto. Puede mostrar que una actualización reciente confundió a los clientes. Puede revelar que una guía de instrucciones necesita pasos más claros. En lugar de tratar cada solicitud como algo aislado, el equipo puede identificar la causa común y trabajar en ella. Eso puede reducir el volumen de casos futuros. Los comentarios de los clientes también fueron parte de ese problema. Un caso cerrado puede mostrar que el equipo cumplió con su objetivo de respuesta, pero el cliente puede sentirse frustrado si tuvo que contactar a soporte tres veces. Analizar tanto el historial del caso como los comentarios ofrece a los gerentes una visión más completa de la experiencia. Algunos clientes preferirían evitar crear un caso por completo. Ahí es donde un portal de autoservicio puede ayudar. A través de un portal, los clientes pueden crear una solicitud, verificar su estado, agregar información nueva o leer artículos de soporte aprobados sin llamar al equipo de asistencia.

Para preguntas sencillas, eso puede ahorrar tiempo a todos. Un cliente puede consultar el estado del entregado o seguir una guía de configuración cuando le resulte conveniente. Mientras tanto, los agentes pueden dedicar más tiempo a problemas que requieren que una persona investigue, explique o tome una decisión. Dynamics 365 Customer Service también puede conectarse con herramientas familiares de Microsoft para el proceso de caso. Un agente puede trabajar con el correo electrónico a través de Apple. Un equipo puede debatir un problema difícil en Teams. Los documentos y la información compartida pueden anunciar sin share. Power BI puede convertir los datos de los casos en informes y paneles, mientras que las herramientas de Power Platform pueden respaldar formularios adicionales, alertas o pasos automatizados en todo el proceso del equipo. Cada herramienta tiene su propia función. El caso sigue siendo el lugar donde el problema de soporte y su historial se mantienen conectados, incluso cuando las personas usan otras herramientas para comunicarse, compartir archivos o revisar el trabajo.

La gestión de casos no trata realmente de completar una pantalla de ticket. Se trata de darle a cada problema del cliente un camino claro a una respuesta registrada y un equipo que pueda aprender de lo sucedido. Conclusión Dan tenga toda la historia del cliente unificado. Esta es la conclusión real. La gestión de casos de Dynamics 365 mantiene el problema, el trabajo, las promesas y el resultado en un solo registro. Se acabó el contexto perdido de las soluciones repetidas. Observe su propio proceso por donde desaparece la información del cliente. Ahí es donde reunir todo lo cambia por completo. Suscríbase en su plataforma de podcast favorita para obtener más información sobre Microsoft. De mi parte, Mirko Peters en M365.fm donde explicamos las herramientas de Microsoft detrás del trabajo diario en lenguaje sencillo.