Plataforma de atención al cliente para una marca regional de servicios

El cliente atendía a sus primeros cien clientes desde una bandeja compartida, un sitio de marketing, una carpeta de contratos en Google Drive y una hoja de Excel que registraba el estado. El montaje funcionaba. Los siguientes cien clientes lo rompieron.

Cuando entramos, tres personas del equipo mantenían tres versiones ligeramente distintas de "la verdad" sobre los tickets abiertos. Los correos de clientes se perdían entre la bandeja y la hoja de cálculo. Los contratos vivían en una carpeta de Drive estructurada por quien hubiera subido el último archivo. El backend a medida que conectaba parte de esto lo había escrito un contratista ya no localizable, y nadie del equipo actual había leído el código.

No había rastro de auditoría. Ni búsqueda estructurada sobre el historial de un cliente. Ni forma de que un cliente consultara el estado sin enviar otro correo. El equipo estaba a punto de contratar a dos personas más de soporte para no quedarse atrás — lo que habría empeorado el problema de coordinación, no resuelto.

Reemplazamos el mosaico por una sola plataforma de atención al cliente, entregada en tres meses con alcance fijo. La división es convencional y deliberada: un sitio público de marketing, un área de cliente sobre una API, y herramientas internas montadas sobre una herramienta de back-office extendida donde toca.

El sitio público es la superficie de marketing — renderizado en servidor para SEO, i18n donde el negocio realmente atiende en más de un idioma, sin JavaScript de cliente cuando una respuesta del servidor basta. Es la parte más barata de operar y la primera que ve el cliente, así que se lleva el presupuesto de pulido.

El área de cliente es donde sucede el trabajo. El cliente se registra, aterriza en un panel autenticado, completa un perfil, abre una solicitud de servicio, sube los documentos de soporte, ve cómo se actualiza la línea de estado y conversa con el equipo en un hilo atado a la solicitud. Se acaban los "¿recibiste mi correo?". El estado de cada solicitud es visible para el cliente que la abrió y para la persona del equipo asignada, en la misma forma y al mismo tiempo.

El panel interno es una herramienta de back-office extendida donde la extensión vale la pena — vistas de lista con los filtros que el equipo usa de verdad, acciones en línea para clasificar y asignar, hilos de comentarios en cada solicitud, trabajo programado asociado al registro del cliente, informes que el equipo saca sin pedírnoslos. No construimos una aplicación de "panel de operaciones" aparte. La herramienta de back-office, tratada como una superficie de producto real, cubrió el noventa por ciento de lo que el equipo necesitaba.

Debajo va una base de datos relacional con un esquema diseñado para las consultas que el negocio ejecuta de verdad — índices parciales sobre solicitudes abiertas, columnas semiestructuradas para los campos específicos por tipo de servicio, claves foráneas allí donde la relación es real. Una cola de trabajos en segundo plano se encarga de lo que no debe bloquear una petición: notificaciones por email y push para los cambios de estado, recordatorios de solicitudes sin respuesta, informes nocturnos y escaneo antivirus al subir documentos.

La autenticación es por sesión tanto para el equipo como para los clientes — sin tokens dando vueltas, sin proveedor SaaS de auth. El acceso por roles distingue los roles del equipo (admin, editor, lector) de los del cliente (titular, usuario delegado). Cada acción que cambia estado escribe una fila en el log de auditoría con usuario y solicitud, consultable desde el admin. La búsqueda corre sobre índices full-text de la base de datos a lo largo del historial del cliente, acotada por rol.

Un proveedor de pagos está integrado para los servicios de pago que lo requerían, detrás del mismo worker en segundo plano para que el manejo de webhooks no bloquee el hilo de la petición. La integración es lo bastante genérica como para que cambiar de proveedor más adelante sea un cambio contenido.

• El autoservicio del cliente reemplazó la cola de emails entrantes para los casos comunes. El equipo abre la bandeja para las excepciones, no para consultar estados.
• Las hojas de cálculo y los documentos compartidos dejaron de ser la fuente de verdad. Lo es la base de datos.
• Cada cambio de estado tiene su fila de auditoría. La revisión de cumplimiento pasó de "vamos a escarbar en el correo" a "aquí está la consulta".
• La búsqueda sobre el historial del cliente funciona. El equipo dejó de preguntarse entre sí qué pasó con una solicitud el trimestre pasado.
• El equipo no necesitó las dos contrataciones extra que tenían previstas. Sumaron una, y esa persona tuvo un sistema en el que trabajar.
• Entregamos a tiempo, con el alcance fijo, con demos al final de cada sprint cada dos semanas contra la URL real.

Lo que recortamos

No construimos una app móvil. El área de cliente es una web responsive, que cubrió el caso de uso real. Una app nativa habría duplicado el proyecto y no habría aportado nada que la versión responsive no diera.

No construimos un motor de workflows a medida para el enrutamiento del equipo. Acciones del admin más tres tareas en segundo plano hicieron el trabajo. Un motor de workflows era una función que podíamos añadir más tarde si la lógica de enrutamiento superaba al código, y no lo hizo.

No migramos el archivo histórico de correos al nuevo sistema. El coste de esa migración era desproporcionado al valor de buscar sobre hilos viejos, y el cliente estuvo de acuerdo. El correo viejo se queda en el correo viejo.

No construimos dashboards de analítica más allá de la media docena de informes que el equipo usó desde el día uno. Los dashboards son fáciles de añadir después sobre datos limpios. Los dashboards sobre datos sucios son trabajo tirado.

Entrega

El cliente es dueño del código, de la infraestructura, de los runbooks y del pipeline de despliegue. El repositorio es suyo, el clúster de base de datos está en su cuenta cloud, el dominio en su registrador. Dejamos un runbook escrito para la guardia, un documento de arquitectura cubriendo cada decisión que tomamos y un backlog de lo que aplazamos a propósito. Sin lock-in. Sin retainer obligatorio para mantener las luces encendidas.

Si quieren volver a trabajar con nosotros en un siguiente alcance, la puerta está abierta. Si quieren seguir solos desde aquí, el sistema está construido para que lo lea un ingeniero que no lo escribió. Ese era el encargo.