Canon oficial · Registry (fuente de verdad) · para equipo y administración
La columna Estado de Relación (G) pinta el color de TODA la fila y define qué
puede hacerse con ese proveedor: qué borradores proceden, si entra en seguimientos y si debe armonizarse con
el Blacklist/Database. Solo se usan los valores canónicos del dropdown — nunca inventes un estado.
🎨 Los estados, uno por uno
🟢 Cliente Activo
Ya tenemos una cuenta ABIERTA y activa con el proveedor.
Se entra en fase de catálogo (Marianella agradece + pide catálogo).
Es el ÚNICO estado al que procede una solicitud de catálogo.
Si dieron usuario/contraseña del portal → van en columnas I/J.
🟡 En Espera
Acabamos de hacer sign up / enviar aplicación o correo; pendiente (menos de 2 semanas).
También al enviar el primer correo frío (Sin Contactar → En Espera).
Registrar K (fecha de registro/aplicación), P y nota en Q.
🟠 Estancado
Pasaron MÁS de 2 semanas sin lograr abrir la cuenta.
Una fila «En Espera» se vuelve naranja SOLA a los 14 días.
Dispara el Follow-up #1; el FU#2 va ~1 semana después.
FU#2 sin respuesta → el caso se CIERRA con nota (no más toques).
🔵 Descartado · Precio/Volumen
NOSOTROS abandonamos: su mínimo de compra/volumen/inversión era demasiado alto.
⛔ La variante genérica «🔵 Descartado» YA NO EXISTE (canon de Daniel del
08/02/2026: «en ningún momento autoricé un status que se llame Descartado en el Accounts
Registry ni en el Suppliers Database»). Nunca la escribas.
Nosotros abandonamos por precio o volumen mínimo inviable → este estado
(«· Precio/Volumen»): además se ELIMINA del Suppliers Database, se AGREGA al Blacklist y el
motivo va en Q (aunque parezca implícito en el estado).
Nosotros abandonamos por cualquier otro motivo (no es mayorista, no encaja,
duplicado, rubro que no nos sirve…) → 🔴 Solo Referencia o Red Flag, con el motivo
SIEMPRE en Q.
🟣 Nos Rechazaron
El PROVEEDOR nos rechazó la solicitud o la aplicación.
→ Blacklist + fuera del Suppliers Database SOLO si el rechazo es por razón de negocio permanente
(canon 08/02). Si fue por FIT (ej. exigen tienda online) → NUNCA Blacklist (ver la regla «Rechazo por FIT ≠ Red
Flag» abajo). Y si la Q trae literal «NO va a la Blacklist», se respeta la exención.
Se conserva en el Registry como historial.
Nota OBLIGATORIA en Q explicando por qué.
🔴 Solo Referencia o Red Flag
Red flag real durante el proceso, O abrimos cuenta pero NO vamos a comprar (solo referencia).
→ Blacklist + fuera del Suppliers Database (ver flujo abajo).
Sirve como referencia comercial al aplicar con otros (escalera de Trade References).
Nota OBLIGATORIA en Q explicando por qué.
⚪ Sin Contactar
Aún sin trabajar. Es el estado por defecto.
Desde aquí nace todo: sign up (equipo) o primer correo frío (administración).
⏰ El reloj de seguimientos (transiciones típicas)
⚪ Sin Contactar→sign up / aplicación / primer correo enviado→🟡 En Espera
🟡 En Espera→+2 semanas sin respuesta (automático a los 14 días)→🟠 Estancado + Follow-up #1
🟠 Estancado→FU#1 sin respuesta → Follow-up #2 (~1 semana después; ≈3 semanas del inicial)→FU#2 sin respuesta → PARAR y cerrar el caso con nota en Q
🟡/🟠 cualquiera→nos confirman la cuenta (o dan credenciales → I/J)→🟢 Cliente Activo → fase de catálogo
🟡/🟠 cualquiera→nos rechazan explícitamente→🟣 Nos Rechazaron
cualquier estado→nosotros abandonamos por CUALQUIER otro motivo (motivo obligatorio en Q)→🔴 Solo Referencia o Red Flag
🚫 Flujo Blacklist — y el flujo INVERSO (revivir)
🔴 Red Flag🟣 Nos Rechazaron→(0) ANTES de nada, revisa la Q: si contiene literal «NO va
a la Blacklist», NO se blacklistea (exención canon 08/02) — Blacklist solo por razón de negocio permanente ·
(1) agregar al Blacklist (nombre + website) ·
(2) ELIMINAR del Suppliers Database · (3) nota en Q con el porqué→queda en el Registry como historial
⤴️ INVERSO — revivir un proveedor mal clasificado (ej.: los marcados
Red Flag solo por usar Shopify, corregidos el 07/16): administración corrige la col G al estado real, lo SACA del
Blacklist y lo restaura en el Suppliers Database (la armonización del sistema ayuda). Siempre con nota en Q.
Esta corrección la decide administración — si crees que un proveedor está mal clasificado, repórtalo
(consultar a Zendy).
❌ Qué NO es cada estado (errores frecuentes)
Shopify NO es red flag (canon 07/16). Ni que el proveedor use Shopify como portal B2B,
ni que pida login o pregunte por nuestra tienda. Miles de mayoristas legítimos operan así (ej. interno:
Eastern Industrial SUP-1732, Cliente Activo). Jamás descartar ni blacklistear por Shopify.
Rechazo por FIT ≠ Red Flag. Si el proveedor no acepta nuestro perfil (ej. exige tienda
online y no la tenemos) → se difiere a administración y se cierra como «Nos Rechazaron» —
NUNCA Red Flag ni Blacklist por un problema de fit. ⚠️ Este caso choca con el canon del 08/02
(que manda todo cierre nuestro a Red Flag): mientras Daniel no lo zanje, este caso se cierra
solo como «Nos Rechazaron» y si no aplica, se pregunta antes de tocar la col G.
«Nos Rechazaron» = ELLOS · el resto lo cerramos NOSOTROS. Si el proveedor dijo
que no → morado. Si nosotros abandonamos: por precio/volumen mínimo → azul «· Precio/Volumen»; por cualquier
otro motivo (rubro, duplicado, no es mayorista…) → 🔴 Solo Referencia o Red Flag. No los mezcles, y el motivo
SIEMPRE en Q.
Silencio ≠ rechazo. Que no respondan no es «Nos Rechazaron»: corre el reloj
(En Espera → Estancado → FU#1 → FU#2 → cierre por silencio con nota).
Red Flag SÍ aplica a inviables reales: signup roto/bugueado, exigen un invoice
previo para aplicar, exigen ya tener cuenta para crear cuenta, o la web no funciona → Q explicando por qué +
Red Flag + Blacklist + fuera del Database.
Nota en Q SIEMPRE en rojos y morados. Ningún Red Flag ni Nos Rechazaron puede
quedar sin la explicación del porqué en Notas Personales (Q).
Proveedor sin correo válido y búsqueda agotada = 🧊 congelado, no rojo. Se congela
automáticamente con nota en Q (no se borra, no va al Blacklist); el radar lo reactiva si aparece un canal nuevo.
El color lo pinta el sistema. El formato condicional colorea la fila según el valor
de G; tu trabajo es elegir el valor canónico correcto del dropdown.
🔗 Fusión de proveedores (raro, pero real — canon 07/17)
¿Cómo se detecta? La web de uno REDIRIGE a la del otro (la prueba reina) · el proveedor lo avisa por correo · aparece "duplicado" al registrar. Verifica: web + hilos de correo de AMBOS + catálogos en Drive.
¿Cuál sobrevive? El de la relación VIGENTE: web viva · correos válidos · hilos reales · catálogo real · portal operativo. (Caso real: Worldwide Perfumes → Miami Trading Zone, 07/17.)
Tú NUNCA borras filas. Documenta la evidencia en la Q de ambos → avisa a Daniel/Marianella con tu recomendación → ellos aprueban → se ejecuta el procedimiento de 5 pasos (consolidar Q+categorías en el sobreviviente · borrar la fila del retirado en Registry y Database · re-etiquetar catálogos · el sistema cierra sus tickets con nota).
El retirado NO va al Blacklist — no hizo nada malo: dejó de existir. El respaldo nocturno preserva su fila.