ReparaCenter: el software que opera un laboratorio de reparación completo

El problema

• Un laboratorio de reparación no cabe en un CRM genérico: su unidad de trabajo no es un cliente ni una venta, es un equipo que entra averiado, pasa por un diagnóstico, consume repuestos de una bodega y sale reparado con una garantía encima.
• Cada laboratorio que se sumara iba a necesitar sus propias sedes, técnicos, precios y datos fiscales — pero mantener una instalación distinta por cliente es insostenible.
• Dentro de un mismo laboratorio no todos deben ver lo mismo: un técnico no tiene por qué ver las órdenes de otra sede, ni un asesor los márgenes de la operación.
• El cliente final llamaba al mostrador para preguntar por su equipo, y cada llamada consumía a alguien del equipo.

Qué construimos

Un solo producto, cada laboratorio en su propio espacio

ReparaCenter es multi-tenant de verdad, no una instalación por cliente. El aislamiento vive en la capa de persistencia: la conexión resuelve a qué laboratorio pertenece cada petición y filtra los datos por debajo, de modo que ninguna consulta del sistema puede ver información de otro. Cada laboratorio tiene su identificador propio, sus datos fiscales, su política de garantía, su WhatsApp y su cupo de almacenamiento; desde la consola de operación se dan de alta laboratorios nuevos sin desplegar nada.

La orden de servicio como eje, no como un ticket más

Entra el equipo, se registra el diagnóstico, se asocian las reparaciones y los repuestos que va a consumir, se asigna técnico y se sigue el estado hasta la entrega. Las finanzas viven en la misma orden, así que el margen de cada reparación deja de ser una estimación de fin de mes. Cada orden lleva un consecutivo propio del laboratorio, generado de forma centralizada: antes, si un asesor y el sistema guardaban al mismo tiempo, ambos calculaban el mismo número y uno de los dos chocaba contra la restricción de unicidad.

Permisos por alcance, no por cargo

El control de acceso no es una lista de roles fijos: son permisos con alcance. "Ver órdenes" existe en tres formas —todas, las de mi sede, o solo las asignadas a mí— y cada pantalla declara cuáles acepta. Eso permite que un técnico vea únicamente su trabajo, un asesor el de su sede y un administrador todo, sin duplicar código ni mantener tres versiones de la misma vista.

Inventario, proveedores y calidades como datos de primera clase

Los repuestos dejaron de ser texto libre. Cada uno tiene proveedor, calidad, compatibilidad por dispositivo y existencias por bodega, con requisiciones para mover stock entre sedes. Cotizar deja de depender de la memoria de quien atiende, y el consumo de repuestos queda amarrado a la orden que lo justificó.

Una API pública por laboratorio

Cada laboratorio expone, bajo su propio identificador y con límite de peticiones, un catálogo de precios, el seguimiento de la orden y el agendamiento de citas. Sobre esa API se apoyan tres cosas que el laboratorio ya no atiende a mano: la consulta de precios, el "¿cómo va mi reparación?" que antes era una llamada al mostrador, y el bot de Telegram que agenda citas fuera del horario de atención. La misma API sirve a cualquier laboratorio del sistema sin código nuevo.

Los documentos que ve el cliente llevan la marca del laboratorio

El recibo de la orden se imprime con el nombre, el NIT, la política de garantía y el código QR de seguimiento de ese laboratorio en particular. Es el tipo de detalle que decide si un SaaS se puede vender a varios clientes o se queda siendo el sistema de uno solo.

Por qué este sistema es difícil de replicar

El modelo de datos es el del laboratorio —equipo, falla, repuesto, calidad, bodega, técnico, garantía—, no el de un CRM adaptado a la fuerza. Y está construido como producto desde el primer día: multi-tenant, con permisos por alcance y con una API pública por laboratorio, que es lo que permite venderle al segundo cliente sin volver a construir nada.