¿Te ayudamos a aplicar esta guía?Pregunta al equipo de DripTell
Imagina que una persona escribe sobre una entrega de muebles: una silla tiene una pata agrietada y a la otra le falta el cojín. Hay un solo mensaje, pero dos resultados pendientes. Separa el trabajo en casos vinculados cuando cada problema necesite responsable, pruebas, plazo o verificación de cierre propios. Conserva la conversación inicial para que la persona no tenga que volver a contar lo ocurrido.
No abras dos casos solo porque el mensaje tiene dos frases. La pregunta útil es si un problema puede resolverse mientras el otro sigue abierto. Autorizar una pata de reemplazo y localizar un cojín en almacén pueden depender de equipos distintos. Si el registro único se marca como resuelto tras la primera gestión, la segunda desaparece de la lista de trabajo.
Define qué resultado espera la persona
Pregunta qué consideraría una solución para cada parte. ¿La silla vuelve a ser segura? ¿Recibió realmente el cojín correcto? Compartir el número del pedido aporta contexto, pero no demuestra una causa ni un propietario común. El ejemplo de las sillas es hipotético; no es una historia de clientes de DripTell.
Si los dos detalles son síntomas de una misma avería, mantenlos en un solo caso con sus pruebas. Si el agente solo requiere la opinión de un especialista y la promesa al cliente sigue siendo una, utiliza una ruta de escalado clara sin trasladar toda la conversación. Separar no debe servir para inflar el número de tickets cerrados.
La decisión inversa tampoco se toma por apariencia. Fusionar dos casos tiene sentido cuando representan el mismo resultado sin resolver. Coincidir en cliente o pedido no basta. Una conversación puede contener dos trabajos y dos conversaciones pueden referirse al mismo.
Lleva el contexto necesario al nuevo caso
El contacto original debe seguir siendo una referencia comprensible. Describe cada tarea con precisión, enlázala con el mensaje de origen y copia únicamente las pruebas pertinentes. Una foto de la pata dañada sirve al equipo de reemplazos; tal vez no haga falta para localizar el cojín. Comprueba identidad y permisos antes de mover datos personales a otra cola.
- 1Define los resultadosPregunta qué prueba que cada asunto está resuelto.
- 2Conserva el origenVincula el nuevo trabajo y traslada solo pruebas pertinentes.
- 3Asigna responsablesCada resultado necesita persona, próximo paso y fecha de noticia.
- 4Coordina una respuestaExplica ambos trabajos sin enviar promesas duplicadas.
- 5Comprueba el cierreVerifica cada resultado y deja abierto el compromiso restante.
La guía de Microsoft sobre casos principales y secundarios muestra un modelo concreto: el pedido común puede permanecer en el caso principal mientras equipos diferentes atienden casos secundarios. Se puede crear un secundario o vincular uno ya existente. Son funciones de Microsoft, no una afirmación de que todos los sistemas tengan ese botón. Sin una relación nativa, crea manualmente otro caso vinculado y registra la razón.
Cada resultado necesita una persona responsable y un siguiente paso. Quien responda al cliente puede coordinar ambos trabajos sin ejecutarlos personalmente. En la transferencia debe constar el estado, la evidencia, la promesa, el bloqueo y la fecha de la próxima noticia. Si cambia el turno, la guía de relevo de casos ayuda a mantener vivos esos compromisos.
| Situación | Decisión sobre casos | Prueba que conservar | Comprobación de cierre |
|---|---|---|---|
| Dos señales de un mismo defecto | Un caso | Ambas observaciones y un responsable | La reparación resuelve las dos señales |
| Dos resultados pueden acabar en momentos distintos | Trabajos separados y vinculados | Mensaje inicial y prueba de cada resultado | Confirmar cada resultado por separado |
| Dos equipos contribuyen a una promesa | Tareas hijas vinculadas si el sistema lo permite | Compromiso y dependencias de cada equipo | No cerrar antes de terminar todo |
| No está claro lo que se pide | Aclarar primero | Las palabras del cliente y la pregunta pendiente | No cerrar por suposición |
Explica el plan sin hablar de tickets
La persona no necesita entender la arquitectura interna. Dile qué ocurrirá con la pata y el cojín, quién coordina la respuesta y cuándo recibirá una actualización útil. Por ejemplo: «Estamos revisando la pata con reemplazos y el cojín con envíos. Mañana le informaré sobre ambos». No prometas una fecha exacta de entrega sin confirmación del almacén y la logística.
Revisa las notificaciones automáticas de tu sistema antes de crear otro caso. Establece qué registro puede enviar la actualización conjunta y deja que los especialistas se coordinen internamente. Dos mensajes contradictorios perjudican más que una organización imperfecta.
Una bandeja de entrada compartida puede dejar visibles historia y responsabilidad, pero la regla para separar resultados la define el equipo. Si el contacto llegó por WhatsApp, el resumen de la bandeja compartida para WhatsApp ayuda a decidir quién responde. Un hilo del canal y un caso de trabajo no son necesariamente lo mismo.
No cierres la promesa común antes de tiempo
Las opciones de Microsoft para casos principales y secundarios permiten seguir varios problemas de un cliente. Una configuración impide cerrar el principal mientras quedan secundarios abiertos; otra cierra los secundarios al cerrar el principal. Comprueba cuál se aplica realmente antes de confiar en un estado. Una acción de cierre rápida puede esconder una tarea pendiente.
Si aprobaron la pata nueva pero el cojín aún no ha llegado, completa solo el primer resultado. Mantén visibles el responsable, el plazo y el impedimento del segundo. Di claramente al cliente qué está hecho y qué falta. Si más adelante reaparece la misma avería, usa la decisión entre reabrir o iniciar otro caso para no falsear su historial.
Revisa algunas conversaciones recientes con varios problemas. ¿Hubo divisiones innecesarias, enlaces de origen perdidos, cierres prematuros o promesas incompatibles? Contar más tickets no significa ayudar mejor. La prueba es que cada preocupación llegue a un resultado comprobado sin perder el contexto.
Preguntas frecuentes
¿Siempre hay que crear dos tickets si un cliente plantea dos asuntos?
No. Sepáralos si requieren resultados que se puedan asignar y verificar independientemente. Mantén un caso cuando ambos detalles pertenecen al mismo problema.
¿Puede seguir abierto el caso original después de resolver una parte?
Sí, si aún queda un compromiso pendiente. Comprueba cómo afecta el cierre del principal a sus trabajos vinculados.
¿Qué hago si mi herramienta no permite dividir un ticket?
Crea otro caso vinculado manualmente, traslada solo el contexto necesario y anota el responsable, la siguiente acción y la regla de comunicación con el cliente.
DripTell Editorial
Guías prácticas revisadas por el equipo de producto y flujos de cliente de DripTell.
Consulta cómo DripTell verifica el producto, utiliza fuentes primarias y corrige errores.
Política editorial y de fuentes