Soporte al cliente SaaS: niveles, traspaso y tiempos
Cómo organizar el soporte al cliente SaaS: niveles de ayuda, preguntas de onboarding, error o duda de uso, traspaso a ingeniería y tiempos por plan.
En este artículo
Un cliente de SaaS no compra una vez y se va. El lunes entra, el martes se atasca y el día de la renovación decide si el producto valió la pena. El soporte al cliente SaaS es el trabajo que ocurre entre esos momentos, y no se parece al de una tienda: las preguntas tratan del comportamiento del software, la misma persona pregunta varias veces y una parte de lo que reporta es un error real que solo ingeniería puede corregir.
Esta guía explica cómo ordenar la ayuda que ofreces, cómo separar los reportes de error de las dudas de uso, cómo pasar un problema a los ingenieros y qué prometer en cada plan.
Tres niveles de ayuda
La mayoría de los equipos SaaS acaban con tres capas, lo hayan planeado o no. Planearlo significa que cada capa tiene una función clara.
| Nivel | Sirve para | Quién lo atiende | Espera habitual |
|---|---|---|---|
| Autoservicio (documentación, ayudas dentro del producto) | Pasos de configuración, «dónde está este ajuste» | El propio cliente | Ninguna |
| Chat en vivo | Pregunta rápida mientras la persona está en el producto | Agentes de soporte | Minutos |
| Tickets | Lo que necesita investigación o varios días | Soporte, luego otros | Horas a días |
Regla práctica: una pregunta con una sola respuesta correcta va a la documentación, una que necesita una mirada humana rápida va al chat, y una que exige revisar la cuenta o los registros va a un ticket. Hodhod no incluye una base de conocimiento; la documentación vive donde tú la publiques y la enlazas desde tus respuestas predefinidas. Para escribirla, mira base de conocimiento y centro de ayuda.
Chat y tickets pueden convivir en una misma bandeja. Un chat que resulta necesitar una hora de investigación se convierte en ticket con todo su historial. Consulta tickets y chat en vivo.
Las preguntas de onboarding son una categoría aparte
Durante las dos primeras semanas la gente pregunta cosas distintas a las de los usuarios veteranos. Rara vez reportan errores. Quieren saber qué hacer primero.
Reúne las preguntas de las primeras veinte o treinta cuentas nuevas y agrúpalas. Casi siempre son las mismas cinco o seis: conectar datos, invitar a compañeros, importar un archivo, lo básico de la facturación, un ajuste confuso. Después:
- Escribe una respuesta predefinida para cada una, con enlace al documento o una respuesta de dos líneas.
- Pon un menú corto de chatbot o una pregunta previa al chat para que esas dudas se resuelvan al instante.
- Márcalas con la etiqueta «onboarding» para contarlas cada mes.
Si una misma pregunta de onboarding sigue llegando, lo más probable es que el producto o la primera pantalla no sea clara. Eso es un hallazgo para el equipo de producto, no un motivo para contratar a otro agente. Mira respuestas predefinidas y plantillas.
¿Error o duda de uso?
La primera tarea ante cualquier mensaje es decidir cuál de las dos es. La respuesta y el responsable cambian.
| Señal | Duda de uso | Error |
|---|---|---|
| El cliente dice | «¿Cómo exporto esto?» | «La exportación da un error» |
| ¿A ti te funciona? | Sí, con los mismos pasos | No, ves el mismo fallo |
| Solución | Una respuesta, quizá un documento | Un cambio de código |
| Responsable | Soporte | Ingeniería |
Si no está claro, intenta reproducirlo con el mismo plan y rol que el cliente. Si no puedes, pide los detalles en un solo mensaje y no en cinco. Una plantilla para copiar:
Gracias por el aviso. Para comprobarlo por nuestra parte, ¿puedes enviarnos lo siguiente? 1. La página o pantalla donde ocurre y lo que esperabas ver 2. Lo que viste en su lugar (una captura ayuda) 3. La hora a la que ocurrió, con tu zona horaria 4. La versión de tu navegador o de la app 5. Si pasa siempre o solo a veces
La prioridad es una decisión aparte del tipo. Un error que bloquea a todos los usuarios de una cuenta es urgente, y puede serlo también la duda de uso de un usuario de prueba a un día de que termine su prueba. Mira triaje y prioridad de tickets.
Pasar un error a ingeniería
Aquí suele fallar el soporte, no porque los ingenieros sean inaccesibles, sino porque el reporte llega sin la información necesaria o llega once veces.
Una nota de traspaso debería incluir, la envíes por tu herramienta de seguimiento o a mano:
- Resumen del problema en una frase
- Pasos para reproducirlo y lo que viste
- Cuenta, plan y hora del primer reporte
- Cuántos clientes lo han reportado hasta ahora
- Solución provisional, si la hay, y lo que le dijiste al cliente
En Hodhod puedes vincular conversaciones y tickets a una incidencia: un registro para un problema, de modo que ingeniería vea un solo elemento con un contador en vez de un montón de mensajes. La incidencia también registra las apariciones cuando el problema vuelve y puede enviarse a Jira como ticket de ingeniería. Mira seguimiento de incidencias. Dile al cliente qué pasará después («lo hemos pasado a los ingenieros y te escribiré cuando esté corregido») y pon una fecha de vencimiento al ticket para acordarte de escribir.
Cuando un problema afecta a varias cuentas a la vez, es un incidente, no un ticket. Quién avisa a quién y cuándo está en la plantilla de política de escalado.
Soporte dentro de la app
El cliente pregunta en el momento en que se confunde, es decir, dentro de tu producto. Un botón de ayuda que abre el chat con el usuario ya identificado ahorra el «¿cuál es tu correo?» y da contexto al agente. En móvil, el SDK de Android lleva chat y tickets a la app nativa; mira el tutorial del SDK de Android. En la web hace el mismo trabajo el widget del sitio.
Qué esperar según el plan
No todos los planes tienen que recibir la misma velocidad, pero todos necesitan una promesa que puedas cumplir. Una estructura sencilla, con cifras de ejemplo en horario laboral:
| Plan | Canales | Primera respuesta | Objetivo de resolución de un error que bloquea el trabajo |
|---|---|---|---|
| Gratuito | Documentación, tickets | 2 días laborables | Sin compromiso |
| Estándar | Documentación, chat, tickets | 8 horas laborables | 3 días laborables |
| Business | Todos, más un contacto asignado | 1 hora laborable | 1 día laborable |
Son cifras de marcador. Parte de lo que tu equipo entrega hoy y comprueba la cuenta: si tres agentes atienden unos 30 tickets al día cada uno y el plan Business tiene 40 cuentas que envían un ticket por semana cada una, la cola Business está muy lejos del límite. Si el plan gratuito tiene 4.000 usuarios, quizá no. Haz tu propio cálculo antes de imprimir cifras en la página de precios.
Para aplicarlo en Hodhod, etiqueta la conversación con el plan (por ejemplo «plan-business») y crea una regla de automatización que añada la política de SLA correspondiente a las conversaciones con esa etiqueta. Detalles en SLA en atención al cliente.
Lista semanal
- Cuenta los tickets nuevos por etiqueta: uso, error, facturación, onboarding
- Lee los cinco tickets abiertos más antiguos
- Lista los errores con más de un reporte y pregunta a ingeniería cómo van
- Busca las dudas de uso que llegaron tres veces o más y escribe o corrige un documento
- Compara los plazos incumplidos con las promesas de cada plan
Si quieres verlo en una bandeja compartida con tus propios planes y etiquetas, solicita una demo gratuita.
Preguntas frecuentes
¿Deben recibir soporte los usuarios gratuitos?
Lo decides tú, pero ofréceles algo: documentación y un formulario de ticket con una promesa más lenta, o un foro. El silencio se convierte en abandono antes del primer pago.
¿Quién es responsable de los reportes de error, soporte o ingeniería?
Soporte lleva la conversación con el cliente hasta el final e ingeniería lleva la corrección. El cliente no debería tener que repetir su historia a ingeniería; para eso existe la nota de traspaso.
¿Cómo evito que vuelva la misma duda de uso?
Cuéntala. Cuando una pregunta llega tres veces en un mes, escribe la respuesta en un documento y en una respuesta predefinida. Si sigue llegando, revisa la pantalla de la que viene.
¿Es imprescindible el chat en vivo para un producto SaaS?
No. Muchos equipos funcionan con documentación y tickets. El chat ayuda cuando alguien se atasca en mitad de una tarea o duda antes de comprar, y necesita a alguien que lo atienda en horarios declarados.
¿De dónde sale la información del plan del cliente?
De ti. Hodhod no lee tu sistema de facturación, así que el plan hay que añadirlo como etiqueta a mano o con una regla de automatización basada en otras condiciones.
