Cuándo debe soporte fusionar dos casos

Un cliente escribe por un paquete dañado y vuelve a contactar porque la primera respuesta no llega. La cola muestra ahora dos casos, aunque el cliente sigue teniendo un solo problema sin resolver.

Fusione los casos únicamente cuando describan el mismo resultado pendiente y el registro que queda pueda conservar todas las pruebas. No los una solo porque coinciden el cliente, el producto o el asunto. La fusión es una decisión sobre el trabajo, no una forma rápida de reducir la cola.

Fusione solo un resultado pendiente

Empiece por el resultado que espera el cliente. Si ambos casos terminan cuando se sustituye el mismo paquete dañado, probablemente son duplicados. Si uno trata del daño y otro de un reembolso que no ha llegado, están relacionados, pero exigen acciones y pruebas de finalización distintas.

Microsoft explica la fusión de casos sobre el mismo problema, incluso cuando se abrieron por canales diferentes. Las actividades, los correos y los adjuntos pasan a relacionarse con el caso que permanece. La función es útil, pero no sustituye el criterio. Dos mensajes parecidos pueden requerir responsables, fechas o permisos distintos.

Pregunte si una sola solución verificable cumplirá todas las promesas abiertas de ambos registros. Si no puede asegurarlo, manténgalos separados y relaciónelos para que la conexión sea visible.

Revise las pruebas antes de cambiar nada

Use la misma revisión tanto si una persona detectó el duplicado como si lo señaló una automatización. Confirme la identidad, el pedido o activo afectado, el resultado solicitado, el estado, el responsable, la próxima actualización, los adjuntos y cualquier restricción de privacidad. Lea toda la cronología, no solo el último mensaje.

Un proceso de soporte visible y un inbox compartido permiten comprobar si dos agentes ya están actuando, si el cliente recibió promesas contradictorias y si un caso contiene datos que faltan en el otro. Un correo coincidente no basta cuando una familia comparte cuenta o varias personas escriben en nombre de la misma empresa.

Elija con cuidado el caso que queda

No conserve simplemente el registro más fácil de seleccionar. Prefiera el que tenga la identidad más clara, la promesa válida más antigua, el responsable correcto, la cronología más completa y el compromiso de servicio adecuado. Antes de fusionar, copie o concilie cualquier campo que su sistema no mueva.

Microsoft describe los casos principales y secundarios como una relación distinta para seguir varios problemas de un cliente o un problema que afecta a varias personas. El administrador puede cerrar los secundarios con el principal o impedir el cierre del principal hasta terminarlos. No es lo mismo que convertir registros en un solo caso. Decida de antemano si debe fusionar, relacionar o mantener separado.

Registre los identificadores de origen, el caso de destino, la razón, quién aprobó, qué se conservó y qué necesitó corrección manual. Mantenga la identidad en el registro del cliente, pero el resultado dentro del caso. Ambos registros se relacionan, aunque cumplen funciones distintas.

Explique al cliente lo que cambió

Después de la fusión, el cliente no debería seguir con dos agentes, dos referencias y dos promesas. Envíe una actualización sencilla desde el caso que permanece. Diga que los dos contactos se refieren a la misma solicitud, indique la siguiente acción, la fecha del próximo avance y qué conversación debe utilizar.

No culpe al cliente por el duplicado. Tal vez escribió de nuevo porque el primer canal guardó silencio. Si los casos contenían promesas diferentes, reconozca la diferencia y aclare cuál se aplicará. Sin ese mensaje, la base puede quedar ordenada mientras la experiencia continúa confusa.

La automatización de procesos puede reunir evidencias y detener respuestas paralelas, pero no debería ejecutar una fusión irreversible por una coincidencia débil del asunto. Deje los casos ambiguos a una persona y limite la facultad de fusionar con controles de seguridad, sobre todo si existen datos sensibles o solicitantes distintos.

Mida el resultado y no el cierre

Un mayor número de fusiones no es un éxito por sí solo. Revise si se detuvo el trabajo duplicado, se conservaron las pruebas, el responsable correcto completó el resultado, el cliente evitó repetir información y no abrió otro contacto porque el caso principal quedó en silencio.

Separe en los informes los cierres por fusión de las soluciones reales. Microsoft marca el caso de origen como cancelado y fusionado, mientras el caso de destino continúa. Su plataforma puede usar otro campo. El principio no cambia, reunir dos registros no resuelve la necesidad del cliente.

Use informes del inbox para revisar muestras por canal, equipo y origen del duplicado. Si un formulario, buzón o regla produce copias de manera constante, corrija ese punto de entrada. El mejor proceso de fusión se necesita cada vez menos.

Preguntas frecuentes

Cuándo son dos casos duplicados de verdad?

Cuando corresponden al mismo cliente o cuenta, al mismo problema de fondo y al mismo resultado pendiente. Una acción completada debe cumplir todas las promesas abiertas en ambos registros.

Se pueden fusionar casos de canales diferentes?

Sí, si coinciden la identidad y el resultado y la plataforma conserva el historial necesario. Los canales distintos no obligan a separar, pero tampoco prueban por sí solos que exista un duplicado.

Qué caso debe permanecer después de la fusión?

Conserve el de identidad más fiable, responsable correcto, compromiso vigente, cronología completa y promesa activa más antigua. Concilie campos y adjuntos antes de la acción definitiva.

Debe la detección automática fusionar por sí sola?

Puede crear una cola de revisión, pero la fusión final necesita pruebas sólidas o confirmación humana. Los asuntos y datos de cliente parecidos producen coincidencias falsas con frecuencia.