«Mejorar el soporte» suele acabar en dos cosas: contratar a alguien o pedir al equipo que responda más rápido. Las dos son caras y ninguna ataca el problema. En un SaaS casi nunca falta velocidad al escribir. Lo que pasa es que llegan preguntas que no deberían llegar, que para responder las que llegan hay que abrir tres pantallas y que las que necesitan a una persona compiten con las que no.
Estos son diez cambios que mejoran el servicio, ordenados de menos a más coste. Los primeros son gratis y el último es el que más se nota.
¿Cómo se mejora el soporte al cliente en un SaaS?
Mide tres cosas: el volumen de contacto, el coste por ticket y cómo se reparten las conversaciones (las que se responden con un artículo, las que dependen de la cuenta y las que necesitan a una persona). Después quita de la cola lo que no debería llegar con arreglos de producto, avisos y artículos titulados como pregunta el cliente; pon los datos de la cuenta donde se responde; deja el horario por escrito; atiende bien un canal antes de abrir otro; deja que un agente cierre lo repetido y lo que depende de la cuenta; cuida el paso a una persona; promete solo el SLA que cumples, y lleva lo que aprendes al equipo de producto. Y mide cruzando métricas, o mejorarás el informe en vez del servicio.
Antes de cambiar nada: tres números
Sin ellos, cualquier mejora es una impresión.
Volumen de contacto. Tickets entre clientes activos, cada mes. Si sube, el producto está generando soporte; si baja, lo que haces funciona. Es la única de las tres que anticipa lo que viene. Más en volumen de contacto.
Coste por ticket. El coste por hora de quien atiende multiplicado por el tiempo que le lleva, contando lo que tarda en buscar los datos y en volver a concentrarse. Suele salir entre 4 y 8 € un ticket sencillo y entre 40 y 90 € uno que escala a ingeniería. El método está en cuánto cuesta atender un ticket de soporte.
Reparto por tipo. Separa las últimas cien conversaciones en tres montones: las que se responden con un artículo, las que obligan a mirar la cuenta y las que necesitan que alguien decida. En un SaaS el segundo suele ser la mitad, y es el que decide qué herramienta necesitas y cuál no.
Con esos tres números, los diez cambios se ordenan solos.
1. Arreglar en el producto lo que es del producto (una tarde)
Una parte de los tickets son datos que el cliente no ve en su cuenta: cuántos usuarios le quedan, cuándo le cobráis, qué incluye su plan, si la integración está activa. Cada uno se convierte en ticket solo porque no está en la pantalla.
Es la única mejora que elimina la conversación. Hay tres arreglos que en casi todos los SaaS quitan más de lo que parece: el plan y sus límites visibles en los ajustes, mensajes de error que digan qué hacer y no solo qué ha pasado, y el estado de cada integración a la vista.
Qué esperar: entre un 10 % y un 20 % del volumen.
2. Avisar antes de que pregunten (unos días)
El ticket que no llega tiene tiempo de respuesta cero. Si sabes que un cliente va a escribir porque le queda un 10 % de cupo, le ha fallado la tarjeta, una integración lleva dos días sin sincronizar o la prueba caduca mañana, díselo tú. El aviso se escribe una vez y sale solo.
Qué esperar: otro 10 %, y clientes que ven buen servicio donde antes había una queja.
3. Titular la documentación como pregunta el cliente (una semana, a ratos)
La mitad de las veces el artículo existe y nadie lo encuentra, porque se titula con vuestro vocabulario y no con el del cliente: «Política de retención» en vez de «cuánto tiempo guardáis mis datos». Cambiar el título a los veinte más leídos, con las palabras que la gente usa en la bandeja de entrada, rinde más que escribir veinte nuevos.
Cuando escribas artículos nuevos, prioriza por frecuencia y coste, una pregunta por artículo, la respuesta en la primera frase y un enlace desde la pantalla donde surge la duda. El método está en cómo escribir un centro de ayuda que se lee.
Qué esperar: lo que quede del montón que se resuelve con un artículo, sobre todo si algo lo sirve dentro de la conversación.
4. Poner los datos de la cuenta donde se responde (un día técnico)
Cronometra desde que alguien abre un ticket hasta que empieza a escribir. En la mayoría de los equipos son entre cinco y diez minutos, todos en el panel de administración. Llevar el plan, el uso, la última factura y el estado de las integraciones a la pantalla donde se responde recorta más tiempo por ticket que cualquier otra cosa de esta lista.
Es lo que hace la bandeja de entrada de Intake, y se puede montar con campos personalizados en casi cualquier herramienta si tienes quien lo desarrolle.
Qué esperar: entre un tercio y la mitad del tiempo por ticket, y una primera respuesta que ya resuelve en vez de «¿me pasas el email de tu cuenta?».
5. Dejar el horario y la expectativa por escrito (una hora)
«Respondemos de lunes a viernes de 9 a 18, normalmente en menos de cuatro horas.» No mejora ningún número, pero quita casi toda la frustración que provoca la espera. El cliente se enfada sobre todo por no saber cuánto va a esperar.
Y que la respuesta automática no cuente como primera respuesta en tus métricas, o el tiempo de respuesta será de dos segundos y no medirá nada.
6. Atender bien un canal antes de abrir otro (una decisión)
Cada canal trae su expectativa: en el chat y en WhatsApp se esperan minutos, en el email, horas. Abrir cinco canales con dos personas es prometer cinco cosas que no puedes cumplir. Abre el que ya usan tus clientes, atiéndelo bien y añade el siguiente cuando el primero ya no te absorba.
Si vendes a tiendas o a consumidores en España, ese canal probablemente es WhatsApp; si vendes a empresas, el email y a veces un canal de Slack compartido.
7. Un agente que lea la cuenta y cierre lo repetido (una tarde y otra técnica)
Con los seis cambios anteriores hechos, en la cola quedan preguntas que dependen de la cuenta y casos que necesitan que alguien decida. Las primeras las cierra un agente que consulte los datos del cliente antes de responder (plan, uso, facturación) y que haga la gestión cuando la respuesta lo pide: ampliar un límite, reenviar una factura, reactivar un webhook.
Aquí no sirve un chatbot que solo lee la documentación, porque esa respuesta no está escrita en ningún artículo. La diferencia está en chatbot o agente de IA, y lo que hace el nuestro, en el agente de Intake.
Empieza con acciones que solo consultan, añade las que cambian algo con confirmación del cliente y revisa cada semana qué ha cerrado y qué ha pasado al equipo.
Qué esperar: la mayor parte del montón que depende de la cuenta, que suele ser la mitad del volumen. A cualquier hora.
8. Cuidar el paso a una persona (una tarde)
De un agente, lo que más se nota es cómo pasa lo que no cierra. Si quien recoge la conversación empieza de cero y el cliente tiene que repetirlo todo, has añadido un paso. La conversación tiene que llegar con lo que se preguntó, lo que se comprobó y por qué se paró, y a la persona o al equipo que corresponde según el canal, el idioma o el motivo.
Es pasar a una persona con el historial: la parte menos vistosa y la más importante.
9. Un SLA que puedas cumplir (tres meses midiendo y luego una hora)
Prometer plazos antes de saber cuáles cumples es la forma más rápida de incumplirlos. Mide tres meses: el plazo que puedes prometer es el que ya cumples en el 95 % de los casos. Sepáralo por prioridad y por canal, cuéntalo solo en horario laboral y distingue las incidencias de la plataforma de las consultas de soporte. Qué contiene y qué valores son razonables está en qué es un SLA.
10. Llevar lo que aprendes a producto (cada mes, media hora)
El soporte es tu mejor fuente de información sobre el producto y la que menos se escucha. Cada mes, lleva los cinco temas que más entran, con su coste, a quien decide qué se desarrolla. Y etiqueta desde el primer día las peticiones de funcionalidades, para que no se pierdan entre los tickets.
Cómo saber si ha funcionado
Cruza métricas en vez de mirarlas sueltas:
| Si mejora… | …comprueba que no empeora | Si empeora, lo que ha pasado |
|---|---|---|
| Tiempo de primera respuesta | Resolución en el primer contacto | Respondes rápido para pedir datos |
| Tiempo de resolución | Tasa de reapertura | Cierras lo que no estaba resuelto |
| Consultas resueltas sin el equipo | CSAT y volumen por otros canales | Has escondido el botón de contacto |
| Tickets por persona | Casos que escalan a ingeniería | Has movido el coste a otro equipo |
El número que lo resume todo es el volumen de contacto bajando mientras crece el número de clientes. Lo explica métricas de soporte que sirven.
Los errores que empeoran el servicio mientras mejora el informe
- Pedir velocidad. El tiempo se va en buscar los datos de la cuenta, no en escribir.
- Contratar antes de medir. Si la mitad de los tickets se repiten, contratar es pagar a alguien por copiar y pegar.
- Poner un chatbot y concluir que la IA no sirve. Un bot que solo lee la documentación no puede responder lo que depende de la cuenta, porque le faltan esos datos.
- Esconder el contacto para que suba el autoservicio. El cliente que no encuentra cómo escribirte acaba yéndose.
- Abrir canales para parecer disponible. Cada canal sin atender es una promesa incumplida.
- Automatizar decisiones que perjudican al cliente. Denegar un reembolso lo decide una persona; hacerlo automático es un problema legal y de confianza.
Preguntas frecuentes
¿Por dónde empiezo si tengo poco tiempo?
Por los tres números y por el cambio 1: una tarde clasificando cien conversaciones y otra arreglando en el producto lo que salga. Es lo que más quita por hora invertida.
¿Cuándo tiene sentido un agente de IA?
Cuando el montón de preguntas que dependen de la cuenta es grande, que en un SaaS es casi siempre, y después de haber quitado lo que no debería llegar. Antes de eso, automatizas preguntas que no deberían existir.
¿Cuánto cuesta mejorar el soporte de un SaaS?
Los cambios 1 a 6 y 8 a 10 cuestan tiempo del equipo, no dinero. El 7 es una herramienta: en nuestro caso, desde 49 € al mes con la IA incluida, más una tarde técnica para conectar la API. Sale antes a cuenta que una contratación.
¿Cómo mejoro el soporte sin contratar?
Con los diez cambios, en ese orden. Contratar tiene sentido cuando crecen los casos que necesitan a una persona, no los repetidos. Está en cómo lleva el soporte un SaaS sin contratar a nadie.
¿Qué herramienta necesito?
Depende del reparto: una bandeja de entrada ligera si el correo es tu canal y el equipo es pequeño, una suite si hay turnos y procesos, y un agente que lea la cuenta si la mitad de las preguntas empiezan por «en mi cuenta». El método está en qué helpdesk elegir para un SaaS.
