Cómo creé un software de satisfacción de cliente en 1 semana

Mi experiencia con este tipo de herramientas era nula. Así que tocó investigar varias cosas. Entre otras:

1. Soluciones existentes. Benchmarking para entender sus productos, features, pricings, clientes objetivo, etc.
2. Terminología de la industria. CSAT, NPS, CES… Son términos de conceptos estándar, que son la base de todo y debía conocer.
3. Opiniones sobre las soluciones existentes. Saber lo que opinan sus usuarios o ex/usuarios en foros, Trustpilot, etc es interesante para saber lo que les gusta y lo que no.
4. Contacto con clientes de la agencia. Saber si conocían o no la utilidad de hacer encuestas; conocer si hacía o habían hecho algún tipo de encuestas; sus motivos para hacerlas o no hacerlas, etc.
5. Conversación con CEO y Director de la agencia. Una vez que tenía cierto conocimiento, era hora de poner en común y acordar el alcance del proyecto.
6. Entrevistas con Project Managers y Jefe Comercial. Para determinar en qué momentos exactos de sus flujos de trabajo convendría disparar encuestas.

• Muchos gerentes y propietarios de negocios locales conocen la utilidad de estos sistemas, pero existe una barrera económica y técnica que les impide dar el paso de implementarlos e interpretarlos activamente.
• La mayoría de soluciones actuales tienen tantas características que muchos usuarios sienten:
  • Que pagan por más de lo que necesitan
  • Que son difíciles de utilizar para lo que ellos necesitan
  • Que son demasiado técnicas (implementación, terminología, métricas, interpretaciones, automatización...)
  • Que necesitan que se encargue de ello una agencia de marketing que muchas veces no tienen

Partí de cuatro supuestos de producto:

1. Multi-tenancy desde el inicio El cliente, la entidad y el usuario final podían ser perfiles distintos. Si no contemplábamos permisos y jerarquías desde el MVP, el producto sería difícil de vender a agencias, grupos de clínicas o negocios multi-sede.
2. Simplicidad por defecto La mayoría de usuarios no querían configurar encuestas desde cero. Necesitaban presets para casos habituales, con opciones avanzadas ocultas o progresivas.
3. Lenguaje no técnico El producto debía evitar conceptos como triggers, webhooks o tokens en la interfaz principal. El usuario debía entender el sistema desde su operación diaria, no desde la lógica técnica interna.
4. Automatización del envío El valor no estaba solo en recoger respuestas, sino en lanzar la encuesta en el momento adecuado. Si el envío dependía siempre de una acción manual, el producto perdería escalabilidad y recurrencia de uso.
5. NPS, CES, CSAT se queda corto
   Centrarlo únicamente en encuestas de estos tres tipos estándar era un desperdicio. Íbamos a construir un sistema que permitiera hacer preguntas y recibir respuestas. A partir de ahí podrían haber más casos de uso, y que la interfaz no lo permita sería un desperdicio.

Debido a que la prioridad era terminar rápido, me apoyé únicamente en estos dos frameworks:

1. User Journey Map (para descubrir proceso y fricciones)
2. Jobs To Be Done (para idear las soluciones)

Habían varios puntos de vista que cubrir, pero me centré en los 3 más básicos que engloban los demás.

1. Persona que crea encuestas
2. Persona que responde encuestas
3. Persona que revisa e interpreta resultados

Con las conclusiones que saqué, identifiqué de manera más específica la características necesarias.

El desafío más relevante, arquitectónicamente, fue el proceso de diseño del sistema multi-tenancy; en el que entraban en juego diferentes tipos de posible cliente y usuario. Y al mismo tiempo, diferentes roles de usuario en cada uno de ellos.

La estructura de cuentas y usuarios que más se adaptaba, dadas las necesidades, fue la siguiente:

Organización A
- Entidad A1
- Entidad A2
- Entidad A3
- ...
Organización B
- Entidad B1
- Entidad B2
- ...

De esta forma, una Organización puede cubrir cualquier caso de uso:

• Una agencia de Marketing que necesita lanzar sus propias encuestas y las de sus clientes.
• Una empresa que tiene diferentes localizaciones y que necesita medir de manera tanto segregada como agregada.
• Una empresa que solo tiene una localización, pero el día de mañana puede crecer y necesitar segregar información.

Existen diferentes tipos de acceso:

• Acceso a todas las entidades de una organización
• Acceso a una o varias entidades de una organización

Y dentro de ellas, existen roles y permisos individuales, que permiten limitar accesos casi por cada funcionalidad.

La primera versión fue sobre papel. Estas iteraciones se centraron mayormente en la experiencia de creación de las encuestas y en el consumo de los resultados en el Dashboard.

Los elementos que mayor fricción presentaban eran sin duda las estadísticas. Hicimos varias iteraciones con el equipo para determinar la mejor manera de que casi cualquier persona fuera capaz de entender los resultados de las encuestas.

Algunos edge cases que debíamos contemplar desde el principio fueron:

• ¿Qué debe ocurrir si la entrega de una encuesta falla?
  Implementamos un sistema de reintentos y fallbacks para que se pueda configurar, por cada organización y/o entidad, por qué medios se quiere enviar las encuestas, en orden prioritario. Si WhatsApp es prioridad 0 y falla, se repite el intento unos minutos después. Si vuelve a fallar, se lanza a prioridad 1 . Y así sucesivamente, hasta tener éxito.
• ¿Qué debe ocurrir cuando caduca una invitación a una encuesta?
  Observamos que era crucial que el tiempo que transcurre, entre el evento que dispara la encuesta y la encuesta en sí, sea el mínimo posible. Ya que la motivación para responder y la objetividad de lo que se transmita decaen rápidamente con cada hora. Por esto, hicimos que la encuesta caduque en 24h, avisando al usuario si abre el enlace transcurrido ese tiempo.
• ¿Qué debe ocurrir si se deja una encuesta a medio responder, sin enviarse?
  • La persona puede terminar la encuesta si vuelve a abrir el enlace dentro de la ventana de 24h.
    • Se guarda en una categoría de métrica "Pendiente de finalizar".
  • Cuando transcurren las 24h, si abre el enlace el usuario recibe feedback de encuesta cerrada.
    • Se guarda como "Respuesta parcial" y contribuye a la métrica "Abandono", como indicador para mejorar las encuestas.