Imagen ilustrativa sobre soporte cliente empresa pequeña

Cómo montar un proceso de soporte al cliente cuando sois 5 personas

No necesitas un equipo de soporte para dar buen servicio. Necesitas un proceso que funcione con las personas que ya tienes.

·soporte cliente empresa pequeña·por Ebägurin

Analizar con IA — elige tu favorita

Obtén un resumen del artículo al instante

Tu cliente acaba de escribir por WhatsApp, por email y por el chat de la web preguntando lo mismo. Tres personas del equipo le han respondido por separado. Una le ha dicho que sí, otra que quizás, otra que lo mira. El cliente está confundido. Vosotros también.

Eso no es un problema de atención al cliente. Es un problema de proceso.

Lo que vas a aprender en este artículo:

  • Por qué en un equipo pequeño el soporte sin proceso es el primer foco de caos visible para el cliente

  • Cómo montar un proceso de soporte funcional con 5 personas, sin herramientas caras ni equipo dedicado

  • Qué SLAs son realistas cuando el soporte lo lleva parte del equipo, no un departamento completo

  • Qué automatizar desde el principio (y qué no tocar todavía)

  • Qué herramientas tienen sentido según tu fase, con precios reales en euros


El problema real: tres canales, tres respuestas, cero control

Cuando sois 5 personas, el soporte al cliente suele funcionar así: quien lo ve, responde. WhatsApp, email, un DM en LinkedIn, el chat de la web. Sin criterio, sin registro, sin seguimiento.

El resultado es predecible. Clientes que no saben si alguien les ha visto. Respuestas contradictorias. Problemas que se "resuelven" a medias porque nadie tiene el contexto completo. Y un equipo donde todo el mundo hace soporte pero nadie es responsable del soporte.

"Si nadie en tu equipo sabe quién hace qué, no tienes un problema de personas. Tienes un problema de procesos."

Esto se agrava con el tamaño. Con 5 personas, no tienes margen para duplicidades. Cada minuto de confusión interna es un minuto que no estás resolviendo el problema del cliente. Y en una startup early-stage, perder un cliente por una mala experiencia de soporte duele mucho más que en una empresa con miles de clientes.

Según datos de Salesforce, el 91% de los clientes que tienen una mala experiencia de atención no vuelven a comprar y no avisan: simplemente desaparecen. Con una base de clientes pequeña, no te puedes permitir ese churn silencioso.


Paso 1: Canal único como primer principio

El primer movimiento es el más contraintuitivo: cierras canales, no abres más.

Un equipo de 5 personas no puede gestionar soporte de calidad en 4 canales simultáneos. No es falta de ganas, es matemática. Así que la primera decisión operativa es elegir un canal principal donde llegan todas las consultas, y redirigir el resto hacia él.

¿Cuál? Depende de tu producto y de dónde están tus clientes. En startups B2B, el email sigue siendo el canal más fácil de centralizar y gestionar asíncronamente. En B2C con producto de consumo, puede ser WhatsApp Business. Lo que importa no es el canal elegido, sino que sea uno.

La implementación práctica:

  • Pones un email de soporte dedicado (soporte@tuempresa.com) que no es el email personal de ningún miembro del equipo

  • En todos los demás canales (chat de la web, WhatsApp, redes) configuras un mensaje automático que redirige: "Para que podamos ayudarte mejor, escríbenos a soporte@... y te respondemos en menos de 24h"

  • Internamente, nadie responde consultas de soporte desde su email personal ni desde su DM. Todo va al canal central

Esto parece simple. Cuesta más de lo que parece implementarlo culturalmente: el equipo tiene que dejar de responder "por reflejo" y empezar a redirigir. Pero sin este paso, todo lo demás falla.


Paso 2: El ticket mínimo viable

Una vez que tienes canal único, necesitas que cada consulta que entra se convierta en un ticket. Un ticket es solo una unidad de trabajo con tres elementos: un responsable, un estado y una fecha de entrada.

No necesitas un software sofisticado para esto. Al principio, puede ser tan simple como una tabla en Notion o en Google Sheets con estas columnas:

Fecha

Cliente

Canal origen

Descripción breve

Responsable

Estado

Fecha cierre

Lo que esta tabla te da es visibilidad. Puedes ver en 30 segundos cuántas consultas están abiertas, quién lleva qué y cuánto tiempo lleva cada una sin resolver.

El error habitual en este punto es querer montar algo demasiado elaborado desde el principio. Con 5 personas y 10-20 tickets por semana, una hoja de cálculo bien mantenida es suficiente. Si ya recibes 50+ tickets por semana, probablemente necesitas pasar directamente a una herramienta de helpdesk (más sobre esto abajo).


Paso 3: Asignación clara, sin ambigüedad

Cada ticket necesita un responsable antes de salir del estado "nuevo". Sin responsable asignado, los tickets envejecen. Y en un equipo pequeño, los tickets que envejecen se convierten en clientes cabreados.

La asignación puede funcionar de dos formas:

Rotación fija: hay una persona responsable del soporte cada día o cada semana. Esa persona procesa todos los tickets entrantes. El resto del equipo no responde, aunque vea la consulta. Si necesita contexto técnico, lo pide internamente y responde ella.

Asignación por tipo: si tu producto tiene áreas claramente diferenciadas (técnico vs. facturación vs. onboarding), cada tipo de consulta va al responsable de esa área. Requiere más criterio para clasificar, pero escala mejor.

Lo que nunca funciona es la asignación implícita ("que lo coja quien pueda"). Eso es exactamente el escenario del principio: tres personas respondiendo, ninguna responsable.

Cuando montes este sistema, vincularlo con los procesos básicos que tu startup debería tener documentados antes de llegar a 10 personas te ahorra reescribir las reglas del juego cada vez que entra alguien nuevo.


Paso 4: SLAs realistas para un equipo sin departamento de soporte

Un SLA (Service Level Agreement, o acuerdo de nivel de servicio) en soporte define cuánto tiempo máximo pasa entre que llega una consulta y que el cliente recibe respuesta. No tienes que llamarlo SLA internamente, pero necesitas una regla clara.

Lo que es realista con 5 personas donde nadie es exclusivamente de soporte:

  • Primera respuesta: máximo 8 horas hábiles (o 24 horas si no tenéis cobertura de tarde). No 2 horas. No "lo antes posible". Ocho horas, y lo cumples siempre.

  • Resolución: depende de la complejidad. Consultas simples (información, facturación): mismo día. Problemas técnicos: 48-72 horas hábiles con actualización al cliente si se alarga.

  • Seguimiento activo: si un ticket lleva más de 48 horas sin resolverse, el cliente recibe una actualización proactiva. No espera a preguntar.

El error más común aquí es fijar SLAs aspiracionales ("respondemos en 2 horas") que no puedes cumplir de forma consistente. Un SLA que cumples siempre genera más confianza que uno ambicioso que fallas una de cada tres veces.

"Medir todo es no medir nada. Elige 5 métricas y haz que signifiquen algo."

Para soporte en fase early-stage, las métricas que importan son dos: tiempo medio de primera respuesta y tasa de resolución en primer contacto. Si controlas esas dos, controlas la experiencia del cliente.


Paso 5: El ciclo de vida de un ticket y el cierre activo

Un ticket no se cierra solo porque hayas respondido. Se cierra cuando el cliente confirma que su problema está resuelto o cuando han pasado X días sin respuesta del cliente tras tu última respuesta (en ese caso, se cierra con nota).

Define el ciclo completo:

  1. Nuevo: consulta recibida, aún sin asignar

  2. En curso: responsable asignado, trabajando en ello

  3. Pendiente de cliente: has respondido, esperas confirmación o información adicional

  4. Cerrado: resuelto o archivado por inactividad

Este ciclo parece obvio. Pero sin estados explícitos, los tickets quedan en un limbo donde "creías que estaba resuelto" pero el cliente sigue esperando. El cierre activo significa que alguien revisa los tickets en estado "pendiente de cliente" cada 48-72 horas y los cierra si no hay respuesta.


Paso 6: La FAQ como sistema de deuda operativa inversa

Cada vez que recibes la misma pregunta por tercera vez, tienes deuda operativa acumulándose. Esa pregunta debería estar en una FAQ pública o en una base de conocimiento, y no debería llegar a tu canal de soporte.

Esto es una práctica que empieza como documentación y acaba como automatización. El proceso es:

  1. Durante el primer mes de funcionamiento del sistema, etiqueta todas las consultas que son preguntas frecuentes

  2. Al cabo de 30 días, tienes una lista clara de las 10-15 preguntas más repetidas

  3. Las documentas en una página pública (puede ser una sección de tu web, un Notion público o un documento enlazado desde tu onboarding)

  4. En el mensaje de respuesta automática del canal central, enlazas esa FAQ: "Antes de escribirnos, puede que tu pregunta ya tenga respuesta aquí: [enlace]"

Esto reduce el volumen de tickets repetitivos entre un 20 y un 40% en startups early-stage, según lo que observamos en proyectos de diagnóstico operativo. No es un dato de industria: es lo que vemos ocurrir sistemáticamente cuando se implementa bien.

El siguiente paso, que tiene sentido cuando el volumen justifica la inversión de configuración, es un chatbot que responde automáticamente a esas preguntas frecuentes antes de que el ticket llegue a una persona. Sobre cómo integrar esto con automatizaciones más amplias de tu operativa, tienes una guía detallada en el artículo sobre automatizaciones básicas que tu startup necesita antes del quinto empleado.


Herramientas según tu fase, con precios reales

No hay una herramienta universal para soporte. Hay la herramienta correcta para tu volumen y tu fase.

Pre-seed / hasta 15-20 tickets por semana

Notion + email compartido (soporte@) es suficiente. Coste adicional: 0€ si ya tienes Notion en el plan gratuito o en el plan equipo. La tabla de tickets vive en Notion, el email se revisa desde un buzón compartido en Google Workspace (desde 6€/usuario/mes).

No añadas nada más todavía. Cada herramienta que añades es configuración, mantenimiento y curva de aprendizaje.

Seed / entre 20 y 80 tickets por semana

Aquí empieza a tener sentido un helpdesk específico. Las opciones realistas para un equipo pequeño:

  • HubSpot Service Hub (plan gratuito o Starter): funciona especialmente bien si ya usas HubSpot para CRM, porque el contexto del cliente está en el mismo sitio. El plan gratuito incluye tickets básicos. El Starter cuesta desde 45€/mes para 2 usuarios.

  • Freshdesk (plan gratuito): hasta 10 agentes gratis, con tickets, estados y asignación. Suficiente para una startup de 5 personas. El plan Growth cuesta 15€/agente/mes si necesitas más funcionalidades.

  • Intercom (plan básico): más orientado a soporte en tiempo real y onboarding. Empieza desde 74€/mes. Tiene sentido si tu soporte es muy conversacional y necesitas el chat de la web integrado. Es caro para un equipo pequeño si el volumen no lo justifica.

Series A / más de 80-100 tickets por semana con equipo creciendo

Con este volumen ya necesitas un helpdesk con automatización de asignación, SLAs configurados en la herramienta y métricas de rendimiento. Zendesk, HubSpot Service Hub Professional o Freshdesk Growth son las opciones habituales. Pero en esta fase, la decisión de herramienta ya forma parte de una conversación más amplia sobre cómo estructurar operaciones, que cubrimos en detalle en la guía de operaciones para startups de 2 a 50 personas.


Los errores que vemos repetirse

Montar el proceso de soporte "cuando tengamos más volumen": el mejor momento para montar el proceso es antes de que el volumen lo haga urgente. Con caos instaurado, montar el proceso cuesta el doble porque tienes que cambiar hábitos, no solo añadir estructura.

Usar el email personal de alguien como canal de soporte: cuando esa persona se va de vacaciones, el soporte desaparece. Cuando deja la empresa, pierdes el histórico del cliente. Siempre un buzón de equipo, nunca un email personal.

Automatizar antes de tener el proceso claro: si no sabes cómo clasificas los tickets manualmente, no sabes cómo automatizar la clasificación. Primero el proceso manual, validado, que funciona. Después la automatización.

Prometer SLAs que dependen de que todo salga bien: los SLAs se cumplen en el peor día, no en el mejor. Si tu equipo no puede responder en 2 horas cuando hay un bug crítico, no prometas 2 horas.


Preguntas frecuentes

¿Cuántas personas necesito para tener un equipo de soporte dedicado en una startup?

En fase early-stage (pre-seed a seed), no necesitas un equipo dedicado. Lo que necesitas es un proceso claro y una persona responsable por turno. La mayoría de startups con menos de 50 clientes pueden gestionar el soporte con rotación interna. A partir de 200-300 clientes activos o 100+ tickets por semana, empieza a tener sentido una contratación dedicada o un perfil híbrido customer success / soporte.

¿Qué canal de soporte debo elegir si tengo que elegir uno solo?

Para startups B2B, el email sigue siendo el canal más fácil de centralizar y con mejor ratio señal/ruido. Para B2C con producto de consumo frecuente, WhatsApp Business API es más natural para el usuario, pero requiere más configuración técnica para gestionar el volumen. Elige el canal donde ya están tus clientes, no el que más te guste a ti.

¿Cómo gestiono el soporte cuando no hay nadie disponible (fines de semana, noches)?

Define una cobertura real y comunícala de forma proactiva. "Respondemos de lunes a viernes de 9h a 18h" es honesto y gestionable. Configura una respuesta automática fuera de horario con el tiempo de respuesta esperado. Un cliente que sabe que recibirá respuesta el lunes a las 9h es más paciente que uno que no sabe si alguien ha visto su mensaje.

¿Tiene sentido implementar un chatbot de soporte cuando sois 5 personas?

Solo si ya tienes documentadas las preguntas frecuentes y el volumen de tickets repetitivos es suficientemente alto como para justificar el tiempo de configuración. Un chatbot mal configurado que no resuelve nada y frustra al cliente es peor que no tenerlo. Primero la FAQ pública, después el chatbot. Herramientas como Tidio o el chatbot nativo de HubSpot son asequibles (desde 0€ en plan básico) y relativamente fáciles de configurar para preguntas frecuentes simples.

¿Debo separar soporte técnico de soporte de facturación o producto desde el principio?

Con 5 personas, probablemente no. La separación por tipo de consulta tiene sentido cuando tienes suficiente volumen en cada categoría como para justificar la especialización. Al principio, una persona generalista que escala internamente cuando necesita ayuda técnica funciona mejor que una separación artificial que crea fricción en el routing.

¿Cómo mido si mi proceso de soporte está funcionando?

Dos métricas que importan en fase early-stage: tiempo medio de primera respuesta (el tiempo entre que llega el ticket y que el cliente recibe la primera respuesta real, no la automática) y tasa de resolución en primer contacto (porcentaje de tickets que se resuelven sin que el cliente tenga que volver a escribir). Si el primero sube o el segundo baja, algo en el proceso está fallando.

¿Qué hago con los tickets que llevan semanas sin resolverse?

Establece un límite máximo de antigüedad: ningún ticket puede estar abierto más de 10 días hábiles sin resolución o sin una comunicación activa al cliente explicando el estado. Revisa semanalmente los tickets más antiguos. Si llevas 10 días sin resolver algo, el problema no es el ticket: es que no tienes el proceso o el criterio para escalarlo correctamente.


El proceso de soporte que montas con 5 personas no tiene que ser perfecto. Tiene que ser consistente.

Un cliente que recibe una respuesta correcta en 8 horas todas las veces confía más en tu producto que uno que a veces recibe respuesta en 1 hora y otras veces no recibe respuesta en 3 días. La consistencia es lo que construye reputación. Y la consistencia solo viene del proceso, no de la buena voluntad.

La pregunta no es si tienes tiempo para montar esto. Es cuánto te está costando no tenerlo montado.

Si el soporte de tu startup es hoy mismo uno de los tres focos de caos que no tienes resueltos, empezamos con un diagnóstico de 1-2 semanas donde mapeamos exactamente qué canales, qué procesos y qué herramientas tienen sentido para tu momento. Agendar una llamada →