Operaciones de clientes

Qué decirle al cliente cuando su problema sigue abierto

Redacta una actualización clara con el estado confirmado, responsable, siguiente acción y próximo contacto sin hacer promesas falsas.

Por DripTell EditorialPublicado 9 de septiembre de 2026Tiempo de lectura 6 min read
Coordinador explica una reparación de guitarra abierta mientras el Context Keeper revisa el puente retirado
¿Te ayudamos a aplicar esta guía?Pregunta al equipo de DripTell
+34

Tu solicitud llega a una persona, no a una lista de correo.

Al enviar, aceptas recibir una confirmación y seguimientos de tu solicitud de DripTell por WhatsApp o correo, incluidos mensajes automáticos. Puedes pedir que se detengan en cualquier momento. Consulta nuestra política de privacidad.

El lunes, un cliente supo que el equipo investigaba un reembolso ausente. El jueves, el caso seguía abierto, pero nadie había explicado qué cambió, quién actuaba ni cuándo habría noticias. El equipo tenía un estado interno. El cliente tenía silencio.

Cuando un problema sigue sin resolverse, envía una actualización breve con cinco elementos. Explica el impacto para el cliente, el estado confirmado en ese momento, la siguiente acción, quién la asume y la hora de la próxima actualización. No inventes una causa ni prometas una fecha de solución que no controlas. Una buena actualización no elimina el problema, pero sí reduce la incertidumbre.

Un cambio de estado no es una actualización

Los estados internos organizan el trabajo, pero no siempre dicen algo útil al cliente. La documentación actual de Microsoft sobre estados de casos muestra que un caso activo puede estar en curso, en espera, pendiente de detalles o en investigación.

“Pendiente”, “escalado” o “con ingeniería” puede ser preciso dentro de la empresa y no significar nada fuera. Traduce el estado a la situación del cliente. Explica qué está afectado, qué se ha confirmado y si debe actuar.

El modelo operativo de soporte debe definir tanto el estado interno como la explicación pública. Así cada agente no tendrá que improvisar cuando haya presión.

Di lo que sabes ahora

Empieza por el último hecho confirmado. “El reembolso todavía no aparece en tu tarjeta” es más claro que “Tu caso está avanzando”. Si se desconoce la causa, di que el equipo aún la comprueba. Una incertidumbre precisa es mejor que una explicación que cambia después.

Recorrido sin palabras en cinco etapas desde el impacto hasta el responsable y el próximo contacto
Explica el impacto, confirma el estado, asigna responsable y acción, y fija la próxima actualización.
Una actualización clara para un caso abiertoPasa del impacto para el cliente a una acción asignada y una hora fiable para el próximo contacto.
  1. 1Explica el impactoNombra lo que el problema impide o cambia para el cliente.
  2. 2Confirma el estadoSepara los hechos verificados de las causas y fechas desconocidas.
  3. 3Asigna responsableIdentifica el equipo o función responsable del paso y contacto siguientes.
  4. 4Indica la acciónExplica la comprobación, petición o decisión concreta que ocurrirá ahora.
  5. 5Fija la actualizaciónPromete una hora concreta aunque el caso pueda seguir abierto.

Separa el hecho de la acción. El procesador quizá no haya confirmado la reversión y facturación puede haber pedido su rastreo. Conserva ambos en la bandeja de entrada compartida para que el siguiente agente no reconstruya la historia de memoria.

Aclara si el cliente debe actuar. Escribe de forma directa “Hoy no necesitamos nada más de ti”. No pidas datos que ya están en el hilo.

Da un responsable a la siguiente acción

“Estamos trabajando en ello” oculta la responsabilidad. Nombra el equipo o la función que hará el siguiente paso, aunque no des el nombre de una persona. “Nuestro equipo de facturación comprueba si la reversión salió de nuestra cuenta” informa más que “El caso se ha escalado”.

La responsabilidad debe verse dentro del equipo. El registro del cliente necesita un propietario, una siguiente acción y un plazo. Una transferencia termina cuando alguien acepta el trabajo y conserva las promesas anteriores.

Situación actualQué debe escuchar el clientePromesa que conviene evitarResponsable interno
Espera de datos del clienteEl dato que falta y por qué es necesarioUna solución antes de recibir la respuestaResponsable actual de soporte
Espera de otro equipoQué está comprobando y cuándo habrá seguimientoUna fecha final sin confirmarResponsable de coordinación
Espera de una parte externaQué dependencia sigue abierta y qué continúa disponibleUn plazo que controla el proveedorResponsable del caso
Causa desconocidaEl impacto confirmado y el siguiente diagnósticoUna explicación especulativaResponsable de la investigación

Promete la próxima actualización y no el resultado

El compromiso más seguro suele ser la siguiente comunicación, no la solución final. Puedes escribir: “Te actualizaré mañana antes de las tres, aunque la investigación siga abierta”. El cliente recibe un punto de referencia fiable sin que la empresa finja conocer el resultado.

Elige el intervalo según las consecuencias. Un pago bloqueado puede exigir noticias en horas; un defecto cosmético puede admitir más tiempo. La documentación de Microsoft sobre seguimiento de casos describe correos periódicos activados por el estado y los intervalos configurados. Son disparadores útiles, pero el ritmo debe responder al impacto.

Si llega la hora prometida y no hay una solución nueva, envía el mensaje de todos modos. Di que el caso continúa abierto, cuenta la última acción y fija otro punto de contacto. Incumplir la actualización crea un segundo fallo que la dependencia original no justifica.

Adapta el mensaje al motivo de la espera

Cada espera necesita palabras distintas. Si faltan datos, formula una pregunta y explica para qué sirve. Si un especialista tiene el siguiente paso, soporte conserva la comunicación. Si interviene un tercero, explica la dependencia sin acusarlo.

Cuando el impacto es importante, ofrece una alternativa segura y describe sus límites. No presentes un proceso manual arriesgado como inocuo. Si no hay alternativa, dilo claramente.

El constructor de automatizaciones puede programar recordatorios y dirigir acciones vencidas, pero no debe fabricar certeza. Una automatización puede detectar que toca actualizar. La persona responsable debe confirmar los hechos antes de enviar.

Comprueba si la actualización reduce la incertidumbre

No midas el éxito solo por el envío. Revisa si el cliente volvió a preguntar antes de la hora prometida, si el responsable perdió el plazo, si el cliente repitió información o si un agente posterior contradijo un mensaje anterior.

Muestrea los casos difíciles, como esperas largas, transferencias, dependencias externas y mensajes sin una solución nueva. En el canal de WhatsApp aplica el mismo estándar que en correo o chat web. Un mensaje más corto todavía necesita un estado verdadero, responsable, siguiente acción y próxima actualización.

Una buena actualización no hace que un problema abierto parezca resuelto. Hace visible la incertidumbre y le asigna un dueño. Si faltan esos elementos en el historial, prueba un caso real en una sesión de trabajo con DripTell antes de automatizar el ritmo.

Preguntas frecuentes

Qué debe incluir una actualización de soporte

Incluye el impacto, el estado confirmado, la siguiente acción, su responsable, lo que debe hacer el cliente y cuándo llegará el próximo mensaje.

Conviene dar una fecha estimada de solución

Solo cuando la estimación procede del equipo o la parte que controla el trabajo. En otro caso, promete una hora concreta para la próxima actualización y explica qué ocurrirá antes.

Qué ocurre si nada cambió a la hora prometida

Envía la actualización a tiempo. Di que el caso sigue abierto, nombra la última acción y cualquier dependencia confirmada, y fija el siguiente punto de contacto.

Se pueden automatizar las actualizaciones

Automatiza recordatorios, enrutamiento y mensajes ligados a eventos estables. Exige que una persona responsable verifique los hechos cuando la causa, el impacto, la alternativa o la fecha final no estén claros.

DT

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