# Ejemplo resuelto · Una decisión antes del CRM

**IA en Uso · Muestra 1.0.0 · 23 de septiembre de 2026**

Este documento es una **solución didáctica redactada para el ejercicio**, con asistencia de IA y revisión editorial humana pendiente. Las propuestas de los tres casos se han preparado manualmente; no son respuestas obtenidas al ejecutar un modelo. Los estados que se describen pertenecen al escenario del ejercicio: no se ha creado ningún registro real.

Abre este documento después de completar **las tres decisiones iniciales y sus notas** y guardarlas como `decisiones-crm.md`. Puedes usar «Guardar decisiones iniciales» en `index.html` o guardar una copia del cuaderno de texto. Conserva esas respuestas antes de contrastarlas con las referencias siguientes.

## Caso 001 · Preparar un borrador pendiente de revisión

El mensaje identifica a Taller Norte, incluye `ana@example.com` y pide «revisar nuestras campañas». La normalización del servicio a `revision_campanas` está prevista en las reglas. Los tres campos obligatorios tienen soporte.

| Campo | Valor de referencia | Motivo |
|---|---|---|
| empresa | Taller Norte | Aparece literalmente en el mensaje. |
| email | ana@example.com | Aparece literalmente; no se ha comprobado un buzón real. |
| servicio | revision_campanas | Corresponde a la petición de revisar campañas. |
| presupuesto | null | No se indica y es opcional. |

**Decisión:** preparar un borrador para `correo-sintetico + mail-001`, con estado **PENDIENTE de revisión humana**. El presupuesto ausente no impide prepararlo. El ejercicio no autoriza un alta en el CRM ni un envío de email.

## Caso 002 · Retirar el dato inventado y pedir que se complete

El mensaje contiene empresa y servicio, pero dice que no incluye un email. La propuesta didáctica ha añadido `comercial@example.com` para que se detecte el error. Su aspecto plausible no le da soporte.

| Campo | Propuesta manual | Valor corregido |
|---|---|---|
| empresa | Taller Norte | Taller Norte |
| email | comercial@example.com | null |
| servicio | revision_campanas | revision_campanas |
| presupuesto | null | null |

**Decisión:** revisar. Se retira el email inventado y se anota que falta un dato obligatorio. Una persona deberá pedir que se complete por un canal apropiado antes de continuar. La muestra no envía esa petición.

No se copia `ana@example.com` del caso 001: `mail-002` es una solicitud distinta y sus datos deben sostenerse en su propia entrada. El motivo para detenerse es el email obligatorio ausente; el presupuesto sigue siendo opcional.

## Caso 003 · Conciliar la reentrega

El contexto indica que ya existe un borrador del caso 001. La comparación manual da este resultado:

| Comprobación | Borrador existente | Nueva entrega | Coincide |
|---|---|---|---|
| Origen | correo-sintetico | correo-sintetico | Sí |
| Identificador de solicitud | mail-001 | mail-001 | Sí |
| empresa | Taller Norte | Taller Norte | Sí |
| email | ana@example.com | ana@example.com | Sí |
| servicio | revision_campanas | revision_campanas | Sí |
| presupuesto | null | null | Sí |

**Decisión:** conciliar. Se conserva **un único borrador**, el existente, que continúa PENDIENTE de revisión humana, y se anota la reentrega. No se crea otro registro ni se envía un email.

La identidad es `correo-sintetico + mail-001`. La coincidencia del email por sí sola no demostraría que fuera la misma solicitud. En esta práctica, comparar los cuatro campos normalizados representa la comprobación de la huella del objeto preparado; no se calcula un hash.

Si la identidad coincidiera y alguno de esos campos cambiara, la decisión sería bloquear la incorporación y revisar la discrepancia, manteniendo el borrador anterior sin sobrescribir. Esa variante no es un cuarto caso de la muestra: es una condición que el cuaderno invita a preparar para la siguiente prueba.

## Ejemplo de entregable final

**Tarea:** preparar borradores de solicitudes de revisión de campañas con empresa, email, servicio y presupuesto opcional.

**Alcance revisado:** tres casos sintéticos y tres propuestas manuales. Hay dos solicitudes distintas; el tercer caso es una reentrega de la primera, no una observación independiente. No se han ejecutado modelos ni conectado un CRM.

| Caso | Decisión de referencia | Acción dentro del escenario |
|---|---|---|
| MUESTRA-CRM-001 | Preparar | Conservar un borrador PENDIENTE de revisión. |
| MUESTRA-CRM-002 | Revisar | Quitar el email inventado y anotar que debe completarse. |
| MUESTRA-CRM-003 | Conciliar | Mantener el único borrador de mail-001, todavía PENDIENTE de revisión. |

> Prepararía el borrador de mail-001 porque sus datos obligatorios tienen soporte. Detendría mail-002 porque falta el email y la propuesta contiene uno inventado. Ante la reentrega de mail-001 conservaría el borrador existente tras comparar origen, identidad y campos. Ninguna de estas decisiones aprueba una operación en un CRM. La siguiente prueba debe incluir la misma identidad con contenido distinto y una ejecución documentada de la automatización que se quiera evaluar.

**Lo aprendido en el ejercicio:** las reglas permiten explicar tres decisiones distintas y documentar qué acción corresponde a cada una. Esto es una referencia de cómo escribir la decisión, no una observación de uso realizada por un participante.

**Evidencia pendiente:** respuestas reales de la configuración que se evalúe, comportamiento del almacén, revisión humana, casos nuevos, reentregas concurrentes y recuperación ante interrupciones cuando formen parte del alcance del proceso. La prioridad concreta dependerá de la tarea elegida.

**Conclusión permitida:** tenemos un criterio de revisión que podemos discutir y adaptar. Esta muestra no permite afirmar que un modelo acierte, que una integración sea fiable o que el proceso ahorre tiempo o dinero.

Autoría: Sergio Sallavera · IA en Uso. Preparado con asistencia de IA; revisión humana no registrada.