Trece columnas. Tres se llenan.

Antes de diseñar nada, contamos. Esto es cuántas veces se llenó cada columna del Excel de Pedro entre enero y junio de 2026 — leído con un parser de CSV de verdad, porque varias filas llevan saltos de línea dentro de las comillas y contar líneas da un número inflado.

La columna peor llenada es la más reveladora: fecha de cierre, 9 de 51. No es que los tratos no cerraran — es que nadie volvió a la hoja a escribir la fecha. Y ese es el patrón completo: cada columna de ese cuadro es una segunda transcripción de algo que ya pasó en otro lado. El nombre y el teléfono ya están en la conversación de WhatsApp. Los adjuntos literalmente se llaman WhatsApp Image 2026-02-04 at 3.44.18 PM.jpeg — ya son mensajes. El encargado es quien atiende el chat. La fecha de cierre es cuándo se aprobó la cotización.

Nadie sostiene un espejo a mano. Por eso el espejo está roto donde está roto.

La primera versión de esta propuesta creaba una tabla ProductSearch aparte, unida a la cotización por una llave foránea compuesta. El argumento sonaba bien: una búsqueda es una orden de trabajo, una cotización es su resultado. Estaba mal, y la señal estaba a la vista.

Y todo lo que iba a construir ya existía

La escalera entera de estatus ya es filtrable hoy, porque status y paymentStatus son los dos parámetros de la lista. Iba a construir un servicio de rollup para producir algo que el módulo ya devuelve.

Los tres argumentos que tenía, y por qué no aguantan

// 1 · dos estados antes de que exista precio. en inglés, como el resto del enum.
enum ServiceQuoteStatusEnum {
  NEW        // llegó la solicitud, nadie la ha trabajado   (POR EMPEZAR)
  SOURCING   // se está buscando proveedor                  (CONVERSACION)
  DRAFT  PENDING  APPROVED  REJECTED  EXPIRED  CANCELLED   ← ya existían
}

// 2 · que los dos nuevos solo valgan para búsqueda de producto
CHECK (status NOT IN ('NEW','SOURCING') OR "serviceType" = 'PRODUCT_SEARCH')

// 3 · el ancla al chat, y la procedencia cuando se reusa una vieja
model ServiceQuote {
  sourceMessageId  String?   // el mensaje del cliente que la originó
  reusedFromId     String?   // de cuál se duplicó
}

// 4 · para poder anclar mensajes (los "Recursos" de Pedro) y notas y bitácora
enum EntityTypeEnum { … SERVICE_QUOTE }   // hoy: 0 ocurrencias

Eso es todo. Tres valores de enum, dos columnas anulables y una restricción. Ninguna tabla, ningún índice nuevo más allá de los que ya cubren status y createdAt.

La primera versión guardaba conversationId. Es insuficiente: una conversación es de un cliente, no de una petición. Si el mismo cliente pide jacuzzis en enero y pantallas LED en junio, los dos están en el mismo hilo — abrir la búsqueda te dejaría en seis meses de mensajes sin saber dónde empieza esta.

sourceMessageId  String?   // el mensaje del cliente que originó la búsqueda

Una sola columna, y da cuatro cosas:

Y evita repetir el error de la llave compuesta: guardar conversationId junto a sourceMessageId serían otra vez dos verdades sobre el mismo hecho, porque el mensaje ya sabe de qué conversación es.

Fecha de cierre estaba en 9 de 51 porque era una consecuencia disfrazada de tarea. Lo mismo el estatus. Lo que ve Pedro sale de cruzar dos cosas que el módulo ya devuelve juntas en cada consulta: el estado del trato y el estado del cobro.

«Lleva N días callado» cambia solo con el paso del tiempo. Materializarlo obligaría a un trabajo programado que recorra la tabla cada noche — y a que el tablero mienta entre corrida y corrida. No hace falta: la columna que se necesita ya está.

WHERE status = 'PENDING'
  AND "sentToClientAt" <= now() - interval '7 days'
-- sentToClientAt existe desde el primer día del módulo

Cambiar el umbral de 7 a 10 días no exige recalcular ni una fila. Se guarda un hecho, que no caduca; no un estado, que sí. Y como «Seguimiento cliente» solo aparece en 2 de las 51 filas del Excel, la prueba de que nadie lo iba a marcar a mano ya está hecha.

La columna Encargado de Pedro dice «Verónica» y «Victoria». Son personal de Mogos, y quién puede encargarse de una búsqueda tiene que salir del RBAC — no de cualquier lado.

Y hay una confusión de vocabulario que conviene deshacer: en este repo RoleEnum.AGENT es otra cosa — el agente comercial que lleva la cartera de un cliente (User.agentId, relación ClientAgent). Verónica no es eso. Es quien trabaja este ítem.

La buena noticia: assignedAgentId ya existe en el modelo, en los tres DTOs y en el filtro de la lista. Ningún componente del admin lo muestra ni lo edita. No hay que construirlo — hay que sacarlo a la superficie. Y eso es lo que hace posibles la ficha «Mías» y los carriles del centro de acciones.

Un Excel abre en todo. Pedro entra, ve 51 filas y tiene que decidir cuáles le tocan hoy — y esa decisión, repetida cada mañana, es la que se deja de tomar. Así que el tablero no abre en la tabla: abre en lo que le reclama algo. Lo cerrado existe, pero detrás de una ficha.

Cinco columnas, y la más útil es la que su Excel nunca tuvo: Espera — cuánto lleva la búsqueda parada en el estado en que está. Es la única cifra que convierte una lista en una cola. Sin ella, «14 días callado» y «ayer» se ven exactamente igual, que es justo lo que pasa hoy.

Cada fila tiene exactamente una acción, y la decide el estado. No un menú de tres puntos con seis opciones de las que cinco no aplican: la que toca, escrita con el verbo que Pedro usaría. El admin ya tiene este patrón —la tarjeta de próxima acción de una cotización— y esto es lo mismo, llevado a la fila.

Y la salida de emergencia, que también es una sola: Rendirse — pasa a CANCELLED con un motivo, que se guarda en el historial que ya existe. Es el único estado que un humano marca en todo el sistema, y por eso pide la razón: es la que separa «no lo conseguimos» de «el cliente desapareció».

Los pasos que Pedro deja de dar

Las Nuevas sin dueño y las que llevan demasiado calladas aparecen además en el centro de acciones — que ya existe, ya es la pantalla de inicio del admin, y ya tiene carriles, «Tomar / Soltar» y atajos de teclado. Es una fuente más en un feed que se calcula al leer: no hay cola que mantener. Pedro no tiene que acordarse de entrar al tablero para que el tablero le hable.

SOURCING es donde vive el trabajo de verdad — días o semanas preguntándole a fábricas. Y ahí aparece una pregunta que el modelo no contestaba: Verónica encuentra un proveedor prometedor al segundo día, antes de que exista ninguna cotización. ¿Dónde guarda el link?

Un link vive en la opción de proveedor, que cuelga de un producto estructurado. Pero en NEW y SOURCING la solicitud es texto libre: «Cuatrimotos de 125cc o 110 a gasolina». Todavía no hay producto.

Esto además explica por qué Link del proveedor solo estaba en 3 de 51 filas del Excel: no es que no encontrara proveedores — es que la hoja no era el sitio donde guardarlos, y acababan en WeChat, en Alibaba o en la cabeza. Que es exactamente el problema que Pedro contó en la reunión: «mandé una cotización en enero… ahora el tema es ubicar al proveedor, porque ya han pasado 6 meses».

La prueba de si el diseño sirve es si el cuadro de Pedro cabe dentro. Sometimos las 51 filas, columna por columna. Nueve entran directo, dos se borran, dos necesitan una decisión — y una cosa se pierde.

Las tres decisiones de la importación

Y el pago de todo esto: con la historia dentro, el pedido de Pedro de reutilizar una búsqueda vieja funciona desde el primer día — buscar «pantallas LED» y encontrar la de enero que no cerró. Con la tabla vacía, esa función no vale nada.