Atención al cliente
¿Cliente equivocado en un ticket de correo? Corrige el solicitante sin perder el hilo
Los reenvíos de colegas y las bandejas compartidas suelen dejar a la persona equivocada como solicitante. Vuelve a vincular al cliente en el ticket de correo, mantén la conversación completa y deja plugins y portal alineados.
Un compañero reenvía el correo de un cliente al soporte. La dirección de la bandeja compartida se convierte en el “cliente.” Otra persona del hilo queda vinculada como titular en el triaje inicial. Los mensajes están bien—la identidad está mal.
El solicitante es el cliente al que pertenece el ticket ahora: la persona que sigue el Para de la respuesta, la clave de plugins e historial reciente y (con self-service activo) quien puede abrir el hilo en el portal. Mientras el vínculo esté mal, todo eso sigue a la persona equivocada. Recrear el ticket tira el contexto. Cambiar el solicitante mantiene el hilo y corrige la propiedad.
Por qué el ticket termina asociado al cliente equivocado
Los tickets de correo heredan la identidad de cómo llegó el mensaje o de quién se seleccionó al crear el ticket. Fallos habituales:
- Un colega reenvía el mensaje del cliente y el colega (o una dirección genérica) pasa a ser el solicitante.
- Una dirección de bandeja compartida se trata como el cliente en lugar de quien necesita ayuda.
- Se elige el contacto equivocado al componer o en los primeros minutos de triaje.
Ese vínculo es estable a propósito—los tickets necesitan un cliente consistente. El coste es que un error de enrutado puntual puede atribuir mal toda la conversación hasta que alguien lo corrija.
Qué hace Cambiar solicitante
En un ticket de correo, los agentes con acceso a la bandeja del ticket pueden abrir ⋯ Actions (esquina superior derecha de la pantalla del ticket) y elegir Cambiar solicitante.
Qué ocurre:
- El solicitante en vivo del ticket se vuelve a vincular a otro cliente (existente, resuelto por correo, o nuevo con correo + nombre).
- La conversación completa se conserva—no clonas ni cierras el ticket.
- Una nota interna del sistema documenta el cambio para auditoría.
- La UI que depende del cliente actual se actualiza: sidebar, plugins, tickets recientes y la dirección Para de la respuesta.
- Si la organización tiene enrutado de CC activo, puedes opcionalmente mantener al solicitante anterior en Cc (desmarcado por defecto).
Piensa en quién posee este ticket ahora, no en cabeceras From congeladas en la creación.
Cómo corregirlo
- Abre un ticket de correo.
- Abre el menú ⋯ Actions en la esquina superior derecha de la pantalla del ticket.
- Elige Cambiar solicitante.
- Revisa el resumen del solicitante actual.
- Introduce el correo del nuevo solicitante (escríbelo o elige entre sugerencias de clientes).
- Si el correo es un cliente nuevo, completa el campo Nombre obligatorio.
- Si el enrutado de CC está activo, decide si marcas Mantener al solicitante anterior en Cc.
- Lee las advertencias en pantalla y confirma Cambiar solicitante.
Tras el éxito, el ticket se actualiza con el nuevo cliente, aparece la nota de auditoría en la línea de tiempo, plugins y tickets recientes siguen la nueva identidad, y el compositor vuelve a configurar el Para / Cc desde los destinatarios actualizados.
Antes de confirmar: tres precauciones
| Atención | Qué esperar |
|---|---|
| Plugins | Los sidebars ligados al correo del cliente actual (facturación, CRM, datos custom) se refrescan para la nueva identidad—los datos de la dirección antigua pueden desaparecer del panel. |
| Portal de self-service | El nuevo solicitante obtiene acceso al portal al hilo completo; el anterior lo pierde. Avisa al equipo antes de sorprender a cualquiera de las partes. |
| Canal | La acción es solo correo. Está oculta en Telegram y otros canales. |
También: si solo necesitas corregir un error de escritura en el nombre visible sin cambiar la identidad, edita el registro del cliente en lugar de cambiar el solicitante.
Identidad correcta, historia intacta
Los tickets de correo mal atribuidos son fricción operativa habitual, no un motivo para reconstruir el historial. Cambia el solicitante cuando la persona equivocada esté pegada al ticket, mantén el hilo y trata plugins y acceso al portal como parte de la decisión—no como un detalle de última hora.
Para flujos relacionados, ver Traspasa un hilo de soporte sin perder al cliente (propiedad del agente) y Autoservicio que de verdad se usa (hábitos de portal). Más notas de producto en Updates.