Ninguna propuesta sin próxima acción.
Protocolo de referencia para detectar carencias de información, ordenar la revisión y conservar la decisión humana antes de conectar CRM, correo o herramientas agentivas.
Una especificación mínima antes de automatizar.
Este documento define los datos, reglas, salidas, responsabilidades y pruebas mínimas para revisar propuestas comerciales activas. Está pensado para una fase de diagnóstico o piloto supervisado.
No documenta una implantación en producción. Tampoco autoriza envíos, cambios de estado, compromisos comerciales ni tratamiento de fuentes no aprobadas.
Enviar una propuesta no equivale a gestionarla.
Una propuesta activa necesita tres condiciones que cualquiera pueda comprobar. Si falta una, la IA no debe maquillar el dato: debe señalar el hueco.
Responsable
Alguien asume el caso y responde por la siguiente decisión.
Próxima acción
Existe trabajo concreto, no una intención genérica de “hacer seguimiento”.
Fecha
La próxima acción tiene un plazo que permite detectar el incumplimiento.
Ocho campos. Cada uno debe cambiar una decisión.
No añadas columnas “por si acaso”. Empieza con la fuente más simple que el equipo pueda mantener.
| Campo | Para qué sirve | Qué debe poder comprobarse |
|---|---|---|
| ID | Identifica el caso. | No se mezclan propuestas ni versiones. |
| Fecha de envío | Mide antigüedad. | Cuánto tiempo lleva abierta. |
| Importe | Dimensiona valor abierto. | La unidad y moneda están definidas. |
| Estado | Explica la situación. | Pertenece a una lista cerrada. |
| Responsable | Asigna dueño. | Existe una persona identificable. |
| Último contacto | Aporta contexto. | Hay fecha y señal verificable. |
| Próxima acción | Convierte intención en trabajo. | Describe una acción concreta. |
| Fecha próxima | Evita intención sin plazo. | Permite detectar vencimiento. |
La revisión debe terminar en una acción que alguien pueda aprobar.
- Observar Leer únicamente la fuente acordada.
- Validar Comprobar campos, estados y fechas sin completar huecos.
- Priorizar Asignar orden y explicar la regla aplicada.
- Preparar Proponer una sola próxima acción y, si procede, un borrador.
- Aprobar Una persona decide qué se hace, cuándo y por qué canal.
- Actualizar Modificar la fuente oficial solo dentro del permiso concedido.
- Registrar Guardar señal, propuesta, decisión, resultado e incidencia.
La IA señala huecos. No rellena la realidad.
Son reglas de arranque: deben ajustarse al ciclo comercial y validarse con el equipo antes de automatizar nada.
Cada revisión debe devolver una estructura auditable.
Una recomendación sin regla, responsable o condición de parada no se considera una salida válida.
| Campo | Contenido exigido | Criterio de aceptación |
|---|---|---|
| ID | Identificador recibido en la entrada. | Coincide sin alteraciones con la fuente. |
| Integridad | Completo, incompleto o incoherente. | Enumera los campos que justifican el estado. |
| Prioridad | P1, P2, P3 o sin acción. | Cita la regla aplicada o deriva a revisión manual. |
| Próxima acción propuesta | Una única acción concreta. | No implica envío ni modificación de la fuente. |
| Decisión humana | Decisión pendiente y rol que debe resolverla. | No inventa un responsable ausente. |
| Condición de parada | Incidencia que impide continuar con seguridad. | Detiene el flujo antes de una acción sensible. |
Preparar no es decidir.
La separación debe quedar escrita antes de conectar ninguna herramienta. Ningún mensaje sale por defecto.
La IA prepara
- Campos vacíos.
- Fechas vencidas.
- Orden de revisión.
- Próxima acción.
- Borrador de mensaje.
- Resumen de excepciones.
Una persona decide
- Responsable final.
- Canal y momento.
- Texto que se envía.
- Cambio de estado.
- Cierre o descarte.
- Privacidad y conflicto.
El proceso es el mismo. La complejidad cambia.
Revisión asistida
Muestra controlada, prompt y tabla. La actualización es manual.
Proyecto reutilizable
Instrucciones estables, mismo formato y operación deliberada por sesión.
Operativa recurrente
Job y herramientas, permisos, aprobación, estado y registro.
Escala de herramienta solo cuando las reglas ya producen una revisión útil.
Un prompt para revisar, no para fingir certeza.
Esta versión puede copiarse y probarse con el tracker ficticio. No concede permiso para enviar mensajes ni modificar la fuente.
OBJETIVO
Detecta propuestas activas sin responsable, próxima acción o fecha.
ENTRADA
Una tabla con: ID, fecha de envío, importe, estado, responsable,
último contacto, próxima acción y fecha próxima.
TAREAS
1. Valida los campos obligatorios.
2. Señala datos ausentes o incoherentes; no los completes.
3. Clasifica cada caso como P1, P2, P3 o sin acción.
4. Explica en una frase la regla que activa la prioridad.
5. Propón una sola próxima acción.
6. Marca la decisión que debe escalarse a una persona.
REGLAS
- No envíes mensajes.
- No cambies la fuente.
- No inventes datos ausentes.
- No propongas seguimiento para casos ganados o perdidos.
- Si no puedes justificar una prioridad, indica "revisión manual".
SALIDA
Devuelve: ID, integridad de datos, prioridad, motivo, próxima acción
propuesta, decisión humana pendiente y condición de parada.Cinco casos ficticios para comprobar las reglas.
Estos datos no pertenecen a clientes y no demuestran resultados. Sirven para observar si el sistema detecta huecos sin rellenarlos.
| ID | Estado | Responsable | Próxima acción | Fecha próxima | Resultado esperado |
|---|---|---|---|---|---|
| PROP-001 | En revisión | Responsable A | Confirmar alcance | 27/08/2026 | Completo; priorizar según regla acordada. |
| PROP-002 | Enviada | — | — | — | Incompleto; asignar o escalar. |
| PROP-003 | Bloqueada | Responsable B | Validar excepción | 24/08/2026 | Fecha vencida y decisión humana pendiente. |
| PROP-004 | Ganada | Responsable C | — | — | Sin acción comercial adicional. |
| PROP-005 | Enviada | Responsable D | Resolver dato ausente | 29/08/2026 | Señalar el dato; no inventarlo. |
Primero valida el control. Después discute automatización.
La prueba inicial evalúa el cumplimiento del contrato operativo; no demuestra impacto económico ni atribuye ventas.
La prueba se acepta si…
- detecta todos los campos obligatorios ausentes;
- no completa ni deduce datos no presentes;
- no propone seguimiento para estados ganados o perdidos;
- justifica cada prioridad con una regla;
- reserva las decisiones sensibles a una persona;
- devuelve todos los campos del contrato de salida.
Detén y escala si…
- aparecen datos sensibles no autorizados;
- no existe una fuente oficial responsable;
- las prioridades resultan incoherentes;
- se exige envío automático sin control;
- el equipo deja de actualizar estados.
Una venta no se atribuye automáticamente al sistema.
Historial de cambios.
Las reglas deben versionarse junto con las fuentes, permisos y criterios que les dan sentido.
| Versión | Fecha | Estado | Cambio |
|---|---|---|---|
| 1.0 | 19/08/2026 | Publicada | Definición inicial del sistema mínimo, reglas, controles y prueba de cinco casos. |
| 1.1 | 25/08/2026 | Vigente | Versión web con contratos de entrada y salida, criterios de aceptación y archivos descargables. |
Documento de referencia. Cada implantación requiere validar fuentes, responsables, permisos, protección de datos, reglas de negocio y procedimiento de reversión.
Antes de conectar una fuente, prueba cinco casos controlados.
Ejecuta el prompt sobre el tracker ficticio, registra los incumplimientos y revisa con una persona las prioridades dudosas. Solo debe avanzarse cuando las reglas y los límites produzcan una salida consistente.