Un ticket es un caso de proveedor que el sistema detectó (leyendo los 6 buzones
2×/día, el Registry y el Drive) y que necesita acción humana. El sistema arma el ticket con 🎯 contexto
y 💡 propuesta, reparte subtareas por equipo (CL = Carlos/Lisneth · MD = Daniel/Marianella ·
SYS = automáticas) y solo administración envía correos. Nada se envía sin veredicto + gates.
👷 (a) EQUIPO — tu parte del ciclo Zelwork
🐣 Nace el ticket→el sistema detectó algo: respuesta de un proveedor, lead nuevo, correo faltante,
catálogo incoherente…→🧩 Tareas CL en Zelwork (por prioridad P1-P4)
🧩 Tareas CL→tipos: llenar formularios/crear cuentas · buscar-correo · QC de leads ·
corroborar catálogo · revisar borrador→acciones: ✅ Completar · 🟡 Parcial · 🔀 Diferir · 🚫 Sin solución · 💤 No requiere
(comentario donde es obligatorio; ⏪ deshacer ≤1h)
🔎 REVISIÓN DE BORRADOR→la tarjeta te muestra: situación + razonamiento + el borrador. Tu auditoría =
4 chequeos + veredicto + comentario
① Registry: ¿G/Q/T/H/W coherentes con lo que el correo propone? ·
② Comunicaciones: ¿tiene sentido AHORA? (hilo real + col T, sin repetir solicitudes) ·
③ Catálogos: ¿U y Drive no lo contradicen? · ④ Redacción: correcta, sin Amazon/marketplace/reseller,
volumen siempre Pallets, saludo y cierre
Veredicto: ✅ Aprobar · ✏️ Con cambios (di QUÉ) ·
❌ Rechazar (di POR QUÉ). Comentario obligatorio si no apruebas o marcaste algún «No»
🤖 El sistema corrobora tu veredicto→coherente → se ejecuta solo (aprobado → listo para enviar · cambios → el borrador
se regenera con tu comentario)/dudoso → escala a 🔍 DECISIÓN MD con todo el contexto
🛰️ Banner de radar→si ves un banner 🛰️: el radar de vigencia detectó contexto NUEVO del proveedor
(escribió de nuevo, cambió algo) y reabrió el ticket para regenerar el borrador. NO es un bug —
es el sistema evitando enviar un correo viejo
🧑💼 (b) ADMINISTRACIÓN — del veredicto al envío Wholezel
📝 Por revisar→desde el flujo 07/17 aquí llegan SOLO: (1) disputas 🔍 DECISIÓN MD — tarjeta especial
con 4 secciones: 📖 La situación · 🧑💼 Qué dijo el empleado (veredicto + chequeos + comentario) ·
🤖 Qué opina el sistema y por qué · 💡 Propuesta del sistema — y (2) casos de decisión directa (marcados DECISIÓN DANIEL,
crédito, sensibles). El resto ya lo filtró la revisión del equipo + el árbitro
Veredicto guiado→3 botones (aprobar/cambios/rechazar) + 2 preguntas; el sistema deduce el caso y crea
las subtareas CL/MD/SYS; terminales (no responder / abandonar) → casos_cerrados→🟢 listo_envio
🟢 listo_envio→entra al 🗓️ PLAN DE ENVÍOS con cupos de warm-up configurables (los vigentes se ven
en ⚙️ Límites; tope canónico 30 correos/día por buzón); fin de semana bloqueado salvo excepción de administración; orden por prioridad→agendado en su día
📤 Botón «Enviar todos los de hoy»→gate MillionVerifier EN VIVO por destinatario: ✅/🟡 pasa · 🔴 se bloquea
(bloqueado_gate) · freno duro por cupos del día→✉️ ENVIADO
✉️ Enviado→post-envío automático: R/S/G/P se reflejan en el Registry · la reconciliación
detecta también envíos manuales desde Gmail→🛰️ el radar SIGUE vigilando el hilo: si el proveedor responde, nace el
siguiente ticket y el ciclo continúa
🎨 Colores por estado del ticket
pendiente / por revisaresperando tareas · en revisión CLcambios_pendientes (corrigiendo)⏳ esperando_insumo — esperan nuestra lista (panel en la home desde 13/08)🔍 DECISIÓN MD · bloqueado_gatelisto_envioagendado en el planenviadoresuelto / caso cerrado (no_responder · descartado_proveedor)
⚡ Reglas de oro del ciclo
El sistema JAMÁS envía solo. Todo correo es un borrador hasta que un humano de
administración lo aprueba y pulsa 📤 (o lo envía desde Gmail — la reconciliación lo detecta igual).
Todo borrador nuevo pasa primero por revisión del equipo (fase 2, 07/16).
Excepciones: los ya listo_envio no se tocan, y lo marcado DECISIÓN DANIEL va directo a MD.
Anti-bucle: a las 2 vueltas de regeneración, el caso sube a MD.
Subtareas de correo/borrador/envío JAMÁS van al equipo CL (guard de casos
A/B/C): responder correos, redactar y enviar es de administración; el equipo acciona formularios, cuentas,
correos a cavar y catálogos.
Dedup antes de solicitar. Nunca se le repite a un proveedor una solicitud
equivalente (catálogo, documento): el sistema revisa T/Q + hilos reales; si ya se pidió → follow-up en el
MISMO hilo.
El estado G dicta el tipo de borrador. Catálogo solo a 🟢 Cliente Activo; a
En Espera/Estancado se les da seguimiento de apertura; a Sin Contactar, primer contacto; a Red Flag, nada.
🛰️ Banner = el radar te cuidó la espalda. Un ticket reabierto por contexto
nuevo no es error tuyo ni bug: revisa el contexto nuevo y sigue el flujo normal.
Comenta con sustancia. Tu comentario (en veredictos y al diferir) es el insumo
con el que el sistema regenera el borrador o decide el siguiente paso. «No me convence» no ayuda;
«ya enviamos esto el 07/02 por mm@» sí.
Los cupos existen por deliverability. Son configurables en ⚙️ Límites del Plan
(tope canónico 30 correos/día por buzón) y protegen la reputación de los buzones en warm-up. Si hoy no salió, el plan lo
re-agenda al próximo día hábil.