Quién aprueba qué: las reglas duras del equipo

Quién aprueba qué: las reglas duras del equipo

Un equipo de varios empleados de IA sin reglas compartidas es más riesgoso que uno solo mal configurado: cada empleado puede tomar una pequeña libertad distinta, y esas libertades se suman. Esta lección cierra el módulo con el documento que hace que Chichiltote, Lapa, Gavilán, Golondrina, Garza, Chocoyo, Guardabarranco y Urraca trabajen bajo las mismas reglas, sin que cada uno improvise las suyas.

La tabla de aprobación

Cada empleado necesita tres columnas claras: qué puede hacer solo, qué necesita tu visto bueno antes de salir, y qué nunca debe hacer bajo ninguna circunstancia. Escribir esto una sola vez y pegarlo en tu Proyecto evita que la regla se repita distinto en cada skill.

Empleado	Hace solo	Necesita tu visto bueno	Nunca hace
Chichiltote (contenido)	Borradores de ganchos y guiones	Publicar cualquier pieza	Inventar datos o resultados
Lapa (publicación)	Armar el calendario propuesto	Confirmar cada publicación	Publicar sin aprobación
Gavilán (prospectos)	Limpiar y puntuar listas	Usar una lista nueva de origen dudoso	Raspar redes o comprar listas
Golondrina (contacto)	Redactar secuencias	Enviar cualquier mensaje	Contactar sin base de consentimiento
Garza (propuestas)	Armar el borrador con la tabla de precios	Enviar la propuesta o el contrato	Inventar un precio o alcance
Chocoyo (atención)	Redactar respuestas y calificar	Enviar cualquier respuesta	Resolver quejas o pagos por su cuenta
Guardabarranco (números)	Calcular y armar el reporte	Ninguna decisión de negocio	Decidir una acción sin mostrar el cálculo
Urraca (postventa)	Armar mensajes según el calendario	Enviar cualquier mensaje	Ofrecer algo a cambio de una reseña

Esta tabla es un punto de partida. Ajústala a tu negocio, pero no elimines la columna de "nunca hace": es la que evita el error que cuesta caro.

La regla de [FALTA]

A lo largo del módulo viste el mismo patrón repetido en cada empleado: cuando falta un dato, se marca con corchetes en vez de inventarse. Esta regla merece estar escrita una sola vez, de forma explícita, para que todos los empleados la sigan igual:

Si un dato necesario no está disponible en el Proyecto ni en la información que se te dio para esta tarea, escríbelo como [FALTA: qué dato específico falta] en el lugar exacto donde debería ir. Nunca completes ese hueco con un supuesto, un promedio ni una cifra inventada, aunque suene razonable.

Un [FALTA] visible es fácil de corregir antes de enviar algo. Un dato inventado que pasa desapercibido es mucho más caro, porque el error solo aparece cuando ya salió del negocio.

Quién revisa a quién

La revisión no puede depender de la memoria de una sola persona ocupada. Define, por escrito, quién revisa el trabajo de cada empleado antes de que salga del negocio. En un negocio pequeño, suele ser el mismo dueño para todo; en uno con más personas, cada área revisa lo suyo:

• El dueño o el responsable comercial revisa todo lo que Garza prepara antes de enviarlo a un cliente.
• Quien atiende al cliente revisa las respuestas de Chocoyo antes de mandarlas.
• El responsable de marketing revisa el contenido de Chichiltote y el calendario de Lapa.
• El dueño revisa el reporte de Guardabarranco cada semana, incluyendo al menos un cálculo a mano.

Si nadie tiene asignada la revisión de un empleado en particular, ese empleado en la práctica no tiene control, aunque la skill diga lo contrario.

Dónde se guardan las correcciones y qué hacer cuando un empleado se equivoca

Cada vez que corriges algo que un empleado de IA produjo mal, esa corrección vale más si queda guardada que si se queda solo en tu cabeza. Un archivo de aprendizajes en el Proyecto, igual al que armaste con Guardabarranco en la lección anterior, sirve para todo el equipo: una línea con la fecha, qué salió mal, y qué regla se agregó o se ajustó en la skill correspondiente para que no vuelva a pasar.

Cuando un empleado se equivoca, el procedimiento es siempre el mismo, sin importar cuál sea:

1. Corrige el resultado antes de que salga del negocio (para eso existe la revisión humana).
2. Entiende por qué pasó: ¿faltaba un dato en el Proyecto? ¿la skill no tenía la regla clara? ¿la instrucción que le diste era ambigua?
3. Ajusta la skill o la información del Proyecto para que ese error específico no se repita.
4. Anota lo que pasó y lo que corregiste en el archivo de aprendizajes.

Ejemplo

Un negocio de catering en Guatemala tiene su tabla de precios en el Proyecto, pero un mes atrás subieron el precio del servicio por persona y nadie actualizó esa tabla. Garza mandó una propuesta a un cliente nuevo con el precio viejo, porque nadie revisó el número antes de enviarla; el dueño solo se dio cuenta cuando el cliente aceptó y ya era tarde para subir el precio sin quedar mal.

Al revisar qué pasó, el dueño encuentra dos fallas: la tabla de precios estaba desactualizada, y nadie tenía asignada la revisión de las propuestas de Garza antes de enviarlas, porque el negocio había crecido y la tarea se había quedado sin dueño claro. La corrección queda así: la tabla de precios se actualiza el mismo día que cambia cualquier precio, sin excepciones, y se asigna a la encargada de eventos como responsable de revisar cada propuesta de Garza antes de que salga. En la skill de Garza se agrega una línea explícita: "Antes de armar cualquier propuesta, confirma la fecha de la última actualización de la tabla de precios; si tiene más de treinta días, avisa que conviene revisarla." El aprendizaje queda anotado en el archivo del Proyecto con la fecha y la causa raíz, no solo el síntoma.

Errores comunes

• Escribir la regla de aprobación distinta en cada skill, en vez de tener un documento único. Eso hace que un empleado quede con reglas más laxas que otro sin que nadie lo haya decidido a propósito.
• Dejar la revisión "para quien tenga tiempo" en vez de asignarla a una persona específica. Sin dueño claro de la revisión, en la práctica nadie revisa.
• Corregir un error una vez y no ajustar la skill ni el Proyecto. El mismo error vuelve a aparecer semanas después porque la causa nunca se corrigió.
• Confundir "nunca hace" con una restricción opcional. Esa columna es la que protege al negocio de un daño real; no se negocia caso por caso.
• No revisar la tabla de aprobación cuando el equipo crece o cambian los procesos. Una tabla vieja deja de reflejar cómo funciona realmente el negocio.

Tu tarea

1. Escribe la tabla de aprobación completa de tu equipo, con las tres columnas (hace solo, necesita visto bueno, nunca hace) para cada empleado que ya configuraste en este módulo.
2. Copia este documento de reglas, complétalo con los nombres asignados a cada revisión, y pégalo en tu Proyecto "Mi negocio" para que todos los empleados lo tengan disponible:

REGLAS DEL EQUIPO DE IA — [nombre del negocio]

1. Regla de [FALTA]
Si un dato necesario no está disponible, se marca como
[FALTA: qué dato] en el lugar exacto donde debería ir. Nunca se
completa con un supuesto ni una cifra inventada.

2. Regla de oro
Lo que compromete al negocio (publicar, enviar a un cliente,
cotizar, cobrar, prometer) siempre lo aprueba una persona antes de
salir.

3. Quién revisa a quién
- Propuestas y contratos (Garza): revisa [nombre]
- Respuestas a clientes (Chocoyo): revisa [nombre]
- Contenido y calendario (Chichiltote, Lapa): revisa [nombre]
- Reporte semanal (Guardabarranco): revisa [nombre], verificando al
  menos un cálculo a mano
- Mensajes de postventa (Urraca): revisa [nombre]
- Listas y contacto en frío (Gavilán, Golondrina): revisa [nombre]

4. Tabla de aprobación por empleado
[Pega aquí tu tabla completa de la sección anterior]

5. Qué hacer cuando un empleado se equivoca
a) Corregir antes de que salga del negocio
b) Entender la causa (dato faltante, skill incompleta, instrucción
   ambigua)
c) Ajustar la skill o el Proyecto
d) Anotar el aprendizaje con fecha y causa

3. Pega el documento completo en tu Proyecto "Mi negocio" y revisa que cada skill que creaste en este módulo mencione la regla de oro y la regla de [FALTA].