Checklist de contrato, NDA y accesos
Una propuesta aceptada entra en una pista de preparación donde las obligaciones comerciales, legales, de seguridad y acceso deben completarse antes del despegue operativo.
Nota del caso
La implementación se trató como un sistema operativo pequeño: primero visibilidad, después ownership y solo entonces automatización.
Caso de uso
Checklist de contrato, NDA y accesos
Una propuesta aceptada entra en una pista de preparación donde las obligaciones comerciales, legales, de seguridad y acceso deben completarse antes del despegue operativo. Un equipo de servicios profesionales podía vender y agendar con rapidez, pero la preparación operativa estaba fragmentada. El alcance, los acuerdos, el pago, la responsabilidad y los accesos vivían entre documentos, CRM y chat, por lo que la entrega podía empezar antes de que el cliente estuviera realmente listo.
Resultado: El inicio se convierte en una decisión deliberada de avanzar o esperar. Las obligaciones comerciales, legales y de acceso se ven en un único registro, y cada bloqueo queda asignado antes de comprometer tiempo de entrega.
Mapa del flujo
Workflow de propuesta aceptada a kickoff desbloqueado
El workflow hace visibles los bloqueos comerciales, legales y de acceso antes de empezar delivery.
Base de datos principal: Supabase
Todo el workflow usa Supabase como fuente de verdad: guarda cada registro, su estado y los eventos clave para ver que paso, reintentar fallos y depurar sin buscar en cada herramienta.
Iconos de herramientas
Racional del sistema
La preparación protege la entrega antes del inicio
Este flujo hace explícitas las condiciones previas: contrato, condiciones de pago, documentos legales, accesos y gestión segura de credenciales.
La entrega no debe empezar con supuestos
La lista convierte el alcance aceptado en un estado listo o pendiente antes de crear el espacio de trabajo.
El acceso es un riesgo operativo
Cada sistema solicitado tiene propósito, responsable, permiso y fecha de revisión; los secretos quedan fuera del flujo.
Los bloqueos necesitan un lugar
Un acuerdo, pago, responsable o acceso crítico pendiente se convierte en un bloqueo asignado, no en un hilo de chat.
Add-ons que encajan encima
El punto de partida
Un equipo de servicios profesionales podía vender y agendar con rapidez, pero la preparación operativa estaba fragmentada. El alcance, los acuerdos, el pago, la responsabilidad y los accesos vivían entre documentos, CRM y chat, por lo que la entrega podía empezar antes de que el cliente estuviera realmente listo.
El diagnostico se hizo sobre volumen real, herramientas conectadas, puntos de decision y excepciones. La pregunta no era solo que automatizar, sino que prueba demostraria que el proceso habia terminado bien. La prueba operativa importo tanto como la automatizacion.
La implementación
Ductio creo un workflow de readiness disparado por proposal_accepted. Construye checklist comercial/legal/accesos, crea inventario sin guardar secretos, redacta access request seguro, prepara plan de folder cliente y solo marca ready_for_kickoff cuando los items requeridos estan completos.
La implementacion separo reglas, contexto libre, decisiones humanas y efectos externos. Asi el sistema podia mejorar el trabajo diario sin convertir cada excepcion en una caja negra. IA como apoyo dentro del proceso, no como piloto automático.
Qué se usó
La selección de herramientas se hizo desde el proceso, no desde una preferencia técnica previa. El criterio fue que cada pieza tuviera un owner claro, integración estable y una forma sencilla de revisar errores.
En la práctica se combinó Supabase, Python/FastAPI, OpenRouter, Google Workspace adapter, Email Resend-ready. Las herramientas visibles para el equipo quedaron cerca de su trabajo diario, mientras la lógica de integración quedó documentada y separada de decisiones comerciales sensibles.
La mejora se vio en el trabajo diario.
En lugar de presentar el resultado como un dashboard, el equipo lo notó en tres escenas concretas: menos preparación manual, menos búsqueda de contexto y menos dudas sobre quién tenía que actuar.
Bloqueos kickoff: Bloqueos comerciales/legales/accesos antes de kickoff pasó de Tarde a Visibles.
Claridad accesos: Sistema, owner, permiso y review date pasó de Chat a Inventario.
Credenciales: Sin secretos en email o tablas pasó de Ad hoc a Reglas.
Prueba antes/después
Qué cambió en la operación
Antes
Después
Artefactos visibles
- Checklist readiness
- Inventario accesos
- Email access request seguro
- Reglas credential handling
- Plan folder cliente
- Log blockers pendientes
- Evento ready_for_kickoff
Controles
- No se guardan secretos
- Gates NDA/DPA/pago explicitos
- Acceso con minimo privilegio
- Kickoff bloqueado hasta completar requeridos
- Cada pendiente tiene owner/status
Qué cambió después
El inicio se convierte en una decisión deliberada de avanzar o esperar. Las obligaciones comerciales, legales y de acceso se ven en un único registro, y cada bloqueo queda asignado antes de comprometer tiempo de entrega.
El resultado no fue solo ahorrar minutos. El equipo gano una secuencia comun para revisar entradas, entender contexto, decidir, actuar y comprobar que el workflow habia quedado registrado. Bloqueos visibles antes de kickoff
El workflow en una línea
Cómo se construyó
El workflow usa client_readiness, access_inventory y readiness_events en Supabase. Python/FastAPI construye el estado del checklist, OpenRouter redacta access/credential language y el adaptador Google Workspace puede crear el folder cliente si esta configurado.
El stack fue pragmático: Supabase, Python/FastAPI, OpenRouter, Google Workspace adapter, Email Resend-ready. No se eligieron herramientas para impresionar, sino por ownership, integración y mantenimiento. El resultado es un sistema que el equipo puede entender y operar.
Lo que quedó entregado
- Trigger proposal_accepted
- Checklist comercial
- Gates NDA/DPA/pago
- Inventario accesos
- Reglas credenciales
- Plan folder cliente
- Estado ready_for_kickoff
- Items comerciales, legales y de accesos quedan visibles antes de kickoff.
- Access requests explican proposito, owner, permiso y manejo seguro de credenciales.
- No se guardan passwords ni API keys en el workflow.
- Kickoff se bloquea si falta SOW, pago, owner o acceso critico.
- Delivery sabe exactamente por que un cliente esta pending o ready.
- La fila de readiness se convierte en handoff hacia onboarding workspace.
- Las solicitudes de acceso transmiten coordinación y criterio de seguridad ante el cliente.
