Servicios de limpieza — del horario en papel al despacho por app móvil

El negocio funcionaba. Lo que no funcionaba era escalarlo.

Las reservas entraban por tres grupos de WhatsApp distintos. El horario del día vivía en una hoja de papel pegada a la pared de la oficina. Una hoja de cálculo compartida intentaba seguir quién tenía servicios recurrentes y qué empleada estaba asignada, pero perdía sincronía a la hora de cualquier cambio.

Los síntomas eran los típicos de una empresa de servicios que superó sus herramientas. Dos empleadas enviadas a la misma dirección. Clientes recurrentes olvidados cuando la persona de despacho libraba. Reseñas que nunca se recogían porque nadie hacía seguimiento. Pagos perseguidos por mensajes una semana después del servicio. Clientes que llamaban a la oficina para saber cuándo llegaría su limpiadora, porque no había otra manera de saberlo.

Los dueños habían probado software genérico de field-service dos veces. Las dos veces falló porque el producto era genérico y el equipo no lo adoptó. El encargo a nosotros fue específico: construye el sistema que esta empresa realmente necesita, con la forma en la que esta empresa realmente trabaja, y haz que sea aburrido de usar.

Lanzamos apps nativas iOS y Android para clientes, un admin web para el back-office, y un backend compartido que es el dueño del dominio.

La app de cliente es la puerta de entrada. El cliente reserva una limpieza puntual o recurrente, elige la propiedad, elige el horario y paga. Ve la hora de llegada según se concreta, le escribe a su limpiadora desde la app, califica el servicio al terminar y gestiona métodos de pago y direcciones guardadas. Las reservas recurrentes son un objeto de primera clase, no una marca sobre una reserva puntual — esa distinción condicionó el resto del modelo de datos.

El admin web es donde despachadores y gerentes pasan el día. Un calendario de reservas, un cuadro de personal, asignación de rutas, historial de cliente y los informes financieros que los dueños abren un lunes por la mañana. Lo construimos como reemplazo amable del horario de pared, no como un recorrido por cada tabla de la base de datos.

El backend es dueño de la base de datos. El motor de planificación se ocupa de las reglas de recurrencia, los saltos por feriados, la disponibilidad de las limpiadoras y la detección de conflictos. Las notificaciones push salen para ambas plataformas, por detrás de workers en segundo plano para que las peticiones web sigan siendo rápidas. Los pagos y la facturación corren por un proveedor de pagos — tarjeta guardada, depósitos donde la empresa los necesita, reembolsos con rastro de auditoría.

La interfaz para la limpiadora vive dentro de la misma app móvil, controlada por rol. La limpiadora abre la app y ve los trabajos del día en orden, con dirección, notas de acceso y un check para marcar lo completado. Sin una segunda app que instalar, sin login aparte, sin una base de código paralela que mantener. Esa decisión nos ahorró aproximadamente un mes de trabajo y eliminó toda una superficie de bugs.

Todo vive en una sola aplicación con una sola base de datos. Elegimos eso por encima de una división en microservicios porque el equipo es un solo grupo de ingeniería y el dominio es un solo negocio. Una división no habría comprado nada y le habría costado un runbook a los dueños.

• Las reservas se toman en la app. El teléfono de la oficina dejó de ser el canal de reserva.
• El horario de papel salió de la pared. El despacho corre desde el calendario del admin.
• Los clientes recurrentes son ahora un objeto rastreado, no un recuerdo. Saltos y feriados están cubiertos.
• Las limpiadoras hacen check-in y cierran el trabajo desde su teléfono. Los gerentes ven el estado en tiempo real.
• Las reseñas cierran el ciclo automáticamente al terminar cada servicio, en vez de nunca.
• Los pagos se cobran al completar. Se acabó perseguir clientes por mensajes.
• Los dueños sacan los números semanales del admin en vez de una hoja de cálculo que tenían que reconstruir.

Lo que recortamos

No construimos integración con marketplaces de terceros. La empresa no vende por agregadores y añadirlos habría implicado un segundo modelo de autenticación y un segundo flujo de conciliación de pagos sin retorno actual.

No entregamos chat in-app completo con historial, adjuntos y presencia. Cliente y limpiadora intercambian mensajes cortos de coordinación atados a una reserva; eso es todo. Un producto de mensajería de verdad es otro producto.

No construimos un optimizador de rutas. La persona de despacho conoce la ciudad mejor que cualquier solver que pudiéramos entregar en cuatro meses. El admin muestra distancia y tiempo entre paradas y deja que el humano decida. Dejamos un costura limpia para añadir optimización después si el volumen lo justifica.

No construimos programa de fidelidad, motor de referidos ni CRM de marketing. Son funciones reales. No son este proyecto.

Cada recorte está documentado. Los dueños saben qué no está y por qué.

Entrega

El cliente es dueño de todo.

La cuenta de desarrollador de Apple y la cuenta de desarrollador de Google Play están a nombre del cliente. El código está en los repositorios del cliente. La base de datos, la aplicación, el admin web y los workers en segundo plano corren sobre la infraestructura del cliente bajo la facturación del cliente. La cuenta del proveedor de pagos es del cliente; nunca tocamos su dinero.

Escribimos los runbooks que la persona de guardia necesita: cómo hacer rollback de un release, cómo rotar los certificados de notificaciones push antes de que expiren, cómo restaurar desde un backup, cómo destrabar una tarea en segundo plano, cómo subir una build nueva a los canales de prueba del App Store y de la Play Store. Dejamos una lista corta de aristas conocidas para que el siguiente ingeniero no tropiece con ellas.

Las demos de fin de sprint cada dos semanas dieron a los dueños ojos sobre la build durante todo el camino. En la entrega no hubo sorpresas. Vienen operando el negocio sobre el sistema desde entonces, y no nos necesitan en el loop para hacerlo.