# Entrega y documentación

> Agentes y Automatizaciones · Empaquetarlo como servicio
> Fuente: https://magoallegri.com/cursos/agentes/servicio/entrega-y-documentacion

---

Los flujos del cliente corren — falta el final que define la relación: **la entrega**. Los sistemas tienen un handoff más delicado que los sitios (lo invisible asusta: "¿y esto qué hace solo? ¿y si toco algo?"), y la entrega que no resuelve ese miedo produce o dependencia total (te llaman por cada botón) o abandono (apagan todo "por las dudas"). El diseño correcto produce lo contrario: el cliente que entiende, opera lo suyo — y te retiene por las razones correctas.

## El paquete de entrega de sistemas (las cuatro piezas)

**1. El mapa de lo que corre** — la versión final del mapa del stack: cada flujo construido, dibujado en idioma de dueño (*"cuando alguien completa el form, pasa esto, esto y esto — y vos recibís este aviso"*). La pieza que convierte lo invisible en entendible.

**2. El manual de operación diaria** — NO la documentación técnica (esa es tuya): las 5-8 cosas que el dueño/su equipo van a hacer de verdad — dónde ver los leads, cómo dar el OK a los mensajes preparados, qué hacer con la alerta X, cómo cargar el lead de mostrador. Con capturas, en su idioma, una página por tarea.

**3. Los "si pasa esto"** — la mini-guía de incidentes del cliente: los 3-4 problemas probables con su primer auxilio (*"si no llegan avisos: revisá esto / si un mensaje salió raro: esto / para frenar todo YA: este botón"*) y la línea final: *"cualquier otra cosa: me escribís, está incluido"* (el retainer asoma).

**4. La capacitación de 30 minutos** — la llamada de entrega donde el equipo USA el sistema con vos mirando: cargan un lead de prueba, aprueban un mensaje, leen el panel. La regla del Paso 1, aplicada a humanos: lo que el usuario hizo una vez con acompañamiento, lo hace solo después; lo que solo vio en un PDF, jamás.

```
Armemos el paquete de entrega tipo (sobre mi proyecto del lab como
modelo):

1. Generá las cuatro piezas para MIS sistemas: el mapa final en
   idioma de dueño, el manual de operación (las tareas humanas
   reales del sistema), los "si pasa esto", y el guion de la
   capacitación de 30 min.
2. La regla de propiedad del camino, verificada pieza por pieza:
   TODO a nombre del cliente (las cuentas de las plataformas de
   flujos, las planillas, los accesos) — el cliente es dueño de
   su maquinaria, siempre.
3. La plantilla queda en /servicio — para cada cliente futuro, se
   genera desde SUS fichas (que tu disciplina de documentación ya
   produce sola: por eso existía).
```

## 💡 La paradoja de la buena entrega (resuelta)

¿Documentar tanto no te hace prescindible? La experiencia del rubro dice exactamente lo contrario: **el cliente que entiende su sistema confía, y el que confía renueva** — mientras que el cliente confundido cancela todo a la primera frustración ("esto es muy complicado para mí"). Además, releé el manual: el cliente opera SU parte (los OKs, las cargas) — el monitoreo, los ajustes, las reparaciones y las mejoras son otro oficio... que es exactamente el retainer de la próxima lección. La entrega clara no regala tu trabajo: lo delimita.

> [!info] **Checkpoint** — El paquete de entrega tipo existe con sus cuatro piezas y la propiedad verificada. Tu entrega de sistemas produce clientes que entienden, operan y confían — la antesala exacta del mantenimiento.

## 🟢 Hacelo ahora

1. Generá el paquete sobre tu proyecto modelo.
2. La prueba del manual: dáselo a alguien ajeno con una tarea ("aprobá este mensaje siguiendo la página 2") — donde se trabe, la página se reescribe.
3. Ensayá el guion de capacitación en voz alta — 30 minutos, cronometrados.

---

La entrega está diseñada. La próxima lección cierra el modelo de negocio: **mantenimiento como retainer** — el ingreso recurrente más natural del mundo de los sistemas.