PageSourceSearch

https://www.bodylogicglobal.com/spa-assets/practice-detail-C01.generated-dR6KEID5.js

js bodylogicglobal.com collected 2026-10-02 11:28:47 UTC 472,135 bytes, 1 lines download raw bytes

1const e=JSON.parse(`[{"practiceId":"C01-01-PR-01","processId":"C01","temaId":"c01-reclutamiento-y-captacion","nombre":"Generación y captación de prospectos multicanal","pregunta":"¿Generamos y capturamos los prospectos de todos los canales de reclutamiento en un registro único, sin depender de que cada representante los administre por su cuenta?","enunciado":"La organización genera y captura el flujo de prospectos a través de canales de reclutamiento definidos (referidos de la fuerza de ventas, eventos, presencia digital personalizada por cada representante) consolidando cada prospecto en un registro único desde el primer contacto. De este modo ningún prospecto se pierde entre el canal y el flujo de alta, y cada punto de entrada aporta la información mínima para calificar y enrutar al interesado, en lugar de depender de que cada representante administre sus contactos por su cuenta.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin proceso de captación; los prospectos los administra cada representante por su cuenta sin registro central."},{"nivel":1,"ancla":"1 Captación ad-hoc; algunos prospectos se anotan informalmente según el canal y la persona."},{"nivel":2,"ancla":"2 Captación repetible con un formato de registro básico, aplicado de forma parcial entre canales."},{"nivel":3,"ancla":"3 Proceso de captación definido y documentado con captura estandarizada por canal y registro único del prospecto."},{"nivel":4,"ancla":"4 Captación gestionada con KPIs por canal (volumen, calidad, costo) y SLA de ingreso del prospecto al flujo de alta."},{"nivel":5,"ancla":"5 Ningún canal de captación conserva presupuesto o prioridad de un periodo comercial a otro sin una revisión documentada de su conversión y calidad medidas en ese periodo."}]},"sistemas":{"referenciaMp":"§5 (sitios replicados), §4 (2.1 Lead y atribución)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; prospectos en agendas personales, chats o cuadernos sin repositorio."},{"nivel":1,"ancla":"1 Hoja de cálculo o formulario aislado por campaña; sin consolidación entre canales."},{"nivel":2,"ancla":"2 CRM o formulario de captura especializado, sin integración con los canales ni con el flujo de alta."},{"nivel":3,"ancla":"3 CRM integrado con formularios y presencia digital personalizada por representante (sitios replicados); el prospecto queda en registro único."},{"nivel":4,"ancla":"4 Plataforma que consolida en tiempo real prospectos de todos los canales con tablero de origen y calidad."},{"nivel":5,"ancla":"5 Ecosistema de captación integrado (canales→CRM→flujo de alta) sin transferencias manuales entre etapas."}]},"agentico":{"referenciaMp":"§6 (IA)","anclas":[{"nivel":0,"ancla":"0 Sin IA; toda la prospección y el registro se hacen manualmente."},{"nivel":1,"ancla":"1 Asistencia puntual de IA para redactar mensajes de prospección bajo demanda."},{"nivel":2,"ancla":"2 Copiloto que sugiere respuestas y clasifica el interés del prospecto dentro del flujo de captación."},{"nivel":3,"ancla":"3 Agente supervisado que captura prospectos de múltiples canales, los normaliza y crea el registro para revisión humana."},{"nivel":4,"ancla":"4 Múltiples agentes coordinan captación, enriquecimiento y enrutamiento del prospecto con supervisión global."},{"nivel":5,"ancla":"5 Captación autónoma que ajusta canales y prioriza prospectos según objetivos definidos, con intervención solo por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Captación multicanal y sitios replicados","tipo":"S4DS","categoria":"CRM de captación y presencia digital del representante","coberturaS4DS":"módulo Reclutamiento · sitios replicados por representante · MCP lead-capture tools","nota":"Consolida en un registro único los prospectos de referidos, eventos y sitios replicados desde el primer contacto, con el canal y el origen capturados como atributos del prospecto."},{"nombre":"Plataforma DMS/MLM con réplica web","tipo":"tercero","categoria":"Distributor Management System — captación y sitios replicados","ejemplos":["Exigo","Epixel","DirectScale","ByDesign (Freedom)","InfoTrax FlexCloud"],"nota":"Alternativa o complemento cuando la réplica web y la captación de leads viven en el DMS núcleo en vez de en el CRM transaccional; Epixel es el vendor con mayor ritmo de lanzamientos de áreas editables controladas en sitios replicados."},{"nombre":"Marketing automation / formularios de campaña","tipo":"tercero","categoria":"Captura de leads y automatización de marketing","ejemplos":["HubSpot","Marketo","Zapier (integraciones de formularios)"],"nota":"Cuando eventos o campañas digitales corporativas generan leads que deben fluir hacia el mismo registro único en vez de quedar aislados por campaña."},{"nombre":"Social listening / gestión de redes","tipo":"tercero","categoria":"Monitoreo y gestión de social selling","ejemplos":["Hootsuite","Sprout Social"],"nota":"Da visibilidad sobre el canal primario de reclutamiento (social selling) y permite medir volumen y calidad de prospección por representante en redes."}],"agentesYUseCase":[{"useCase":"Agente de captura y normalización: consolida prospectos entrantes de múltiples canales (formularios, sitios replicados, referidos) en el registro único, normalizando campos y detectando duplicados antes de crear el registro para revisión.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — normaliza y crea; el humano revisa excepciones","valor":"elimina la pérdida de prospectos entre el canal y el flujo de alta y evita duplicidad"},{"useCase":"Copiloto de prospección: sugiere mensajes de primer contacto y respuestas a partir de plantillas aprobadas, adaptadas al canal (redes, evento, referido) para el representante.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — sugiere; el representante decide y envía","valor":"estandariza el primer contacto sin depender del estilo individual de cada representante"},{"useCase":"Analítica de mezcla de canales: agente que correlaciona canal de origen con conversión y calidad del prospecto, y recomienda reasignar esfuerzo/inversión entre canales.","tipo":"tercero","nivelAutonomia":"copiloto (nivel 2) — recomienda; marketing/field ops decide","ejemplos":["Rallyware next-best-action (aplicado a mezcla de canales)"],"valor":"reemplaza la intuición sobre qué canal funciona con evidencia de conversión real"}],"metadata":{"evidenciaEsperada":"Registro único de prospectos de la última campaña de reclutamiento con canal de origen y fecha de primer contacto.","dolorAsociado":"Prospectos dispersos en canales y agendas personales; pérdida de leads entre el primer contacto y el alta; sin visibilidad de qué canal funciona.","frenteRecomendacion":"Tecnología e Integración","fuente":"MASTER-C01 §2 (Reclutamiento/captación), §4 (2.1 Lead y atribución), §5 (sitios replicados), §9 (social selling como canal primario)"},"camposFaltantes":[]},{"practiceId":"C01-01-PR-02","processId":"C01","temaId":"c01-reclutamiento-y-captacion","nombre":"Calificación y scoring del prospecto","pregunta":"¿Calificamos cada prospecto con criterios objetivos antes de inscribirlo, distinguiendo al cliente potencial del constructor de negocio?","enunciado":"El prospecto se califica antes de avanzar a la inscripción mediante criterios explícitos y consistentes que estiman 
1su potencial y su ajuste (interés como cliente frente a constructor de negocio), de modo que el esfuerzo se prioriza hacia prospectos con intención real y los dos embudos —cliente y vendedor— se separan desde el origen en lugar de mezclarse. La calificación hace defendible y repetible la decisión de a quién acompañar hacia el alta.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin calificación; todo prospecto se empuja al alta por igual sin evaluar intención ni ajuste."},{"nivel":1,"ancla":"1 Calificación intuitiva según el criterio de cada representante, sin criterios comunes."},{"nivel":2,"ancla":"2 Criterios de calificación conocidos pero aplicados de forma desigual y sin registro del resultado."},{"nivel":3,"ancla":"3 Criterios de scoring definidos y documentados, aplicados de forma consistente y registrados por prospecto."},{"nivel":4,"ancla":"4 Scoring gestionado con datos de conversión; se mide la precisión del score y se separan los funnels cliente/constructor."},{"nivel":5,"ancla":"5 Ningún criterio de scoring permanece vigente sin haber sido validado contra los resultados reales de activación y conversión del periodo comercial anterior."}]},"sistemas":{"referenciaMp":"§7 (funnel dual), §5","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; la calificación, si ocurre, es mental y no queda registrada."},{"nivel":1,"ancla":"1 Planilla con criterios básicos llenada manualmente por prospecto."},{"nivel":2,"ancla":"2 CRM con campos de calificación, sin cálculo automático de score."},{"nivel":3,"ancla":"3 CRM con scoring configurado y reglas de calificación integradas al registro del prospecto."},{"nivel":4,"ancla":"4 Plataforma que calcula el score con datos de comportamiento y conversión en tiempo casi real."},{"nivel":5,"ancla":"5 Scoring integrado al ecosistema (captación→calificación→alta) con datos que retroalimentan el modelo automáticamente."}]},"agentico":{"referenciaMp":"§6 (predicción de churn / next-best-action)","anclas":[{"nivel":0,"ancla":"0 Sin IA; el score se calcula manualmente si acaso."},{"nivel":1,"ancla":"1 Fórmula asistida o IA que sugiere una clasificación básica bajo demanda."},{"nivel":2,"ancla":"2 Copiloto que propone un score y una recomendación de siguiente paso para revisión."},{"nivel":3,"ancla":"3 Modelo supervisado que puntúa cada prospecto y prioriza la lista para el equipo."},{"nivel":4,"ancla":"4 Agente que integra señales de múltiples fuentes y ajusta la priorización de forma coordinada."},{"nivel":5,"ancla":"5 Scoring autónomo que aprende de los resultados de conversión y activación y prioriza prospectos, con intervención humana solo por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Scoring y calificación del prospecto","tipo":"S4DS","categoria":"Módulo de calificación dentro del CRM de reclutamiento","coberturaS4DS":"módulo Reclutamiento · reglas de scoring configurables · MCP scoring tools","nota":"Aplica criterios de calificación consistentes al prospecto y separa desde el origen el registro como cliente/preferred customer del registro como builder/vendedor."},{"nombre":"CRM con lead scoring","tipo":"tercero","categoria":"Scoring de leads y priorización comercial","ejemplos":["HubSpot","Salesforce Sales Cloud"],"nota":"Cuando el scoring inicial corre en el CRM corporativo antes de pasar al DMS/MLM."},{"nombre":"Plataforma de engagement/onboarding con analítica predictiva","tipo":"tercero","categoria":"Predicción de comportamiento del vendedor","ejemplos":["Rallyware","Exigo AI"],"nota":"Modelos que correlacionan señales tempranas con probabilidad de activación real como builder, útil para calibrar y validar los criterios de scoring con datos de conversión."},{"nombre":"BI / analítica de conversión de funnel","tipo":"tercero","categoria":"Analítica de embudo dual","ejemplos":["Power BI","Tableau","Looker"],"nota":"Mide la conversión de cada funnel (cliente vs. builder) por separado, no combinada."}],"agentesYUseCase":[{"useCase":"Copiloto de scoring: propone un score y una recomendación de siguiente paso (cliente vs. builder) para cada prospecto nuevo, con la evidencia que sustenta la clasificación, para revisión del equipo de campo.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — sugiere; el humano confirma la clasificación","valor":"hace explícito y auditable un criterio que antes vivía en el juicio informal del sponsor"},{"useCase":"Modelo supervisado de priorización: puntúa cada prospecto entrante con señales de comportamiento e interacción, y ordena la lista de seguimiento del equipo por probabilidad de conversión real.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — puntúa y prioriza; el humano ejecuta el contacto","valor":"concentra el esfuerzo de seguimiento en los prospectos con mayor intención real"},{"useCase":"Predicción de churn / next-best-action aplicada a la calificación temprana: identifica patrones asociados a abandono antes de la primera acción y sugiere el journey adecuado (cliente vs. builder) de
1sde el scoring inicial.","tipo":"tercero","nivelAutonomia":"agente supervisado (nivel 3)","ejemplos":["Rallyware next-best-action","Exigo AI (detección de anomalías tempranas)"],"valor":"conecta la calificación de entrada con la intervención de retención antes de que el prospecto se pierda"}],"metadata":{"evidenciaEsperada":"Criterios de scoring del prospecto vigentes + ejemplo de prospectos calificados de la última campaña con su resultado.","dolorAsociado":"Esfuerzo repartido por igual entre prospectos sin intención real; funnels de cliente y constructor mezclados que inflan la conversión.","frenteRecomendacion":"Modelos Agénticos/IA","fuente":"MASTER-C01 §7 (funnel dual, definición de activo), §6 (predicción de churn / next-best-action), §9 (calidad de activación)"},"camposFaltantes":[]},{"practiceId":"C01-01-PR-03","processId":"C01","temaId":"c01-reclutamiento-y-captacion","nombre":"Atribución determinística del prospecto al sponsor","pregunta":"¿Cada prospecto queda atribuido a su sponsor mediante un identificador único y trazable desde el primer contacto, sin ambigüedad para la genealogía y las comisiones?","enunciado":"Cada prospecto queda ligado desde el primer contacto al sponsor que lo originó mediante un identificador único y trazable, de manera que la colocación en la genealogía y las comisiones resultantes se atribuyen correctamente y las disputas sobre la titularidad del prospecto se resuelven con evidencia y no de memoria ni por acuerdos verbales. La atribución es el cimiento de la integridad de la genealogía y del cálculo de comisiones de terceros.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin atribución formal; el sponsor se asigna de memoria o por acuerdo verbal al momento del alta."},{"nivel":1,"ancla":"1 Atribución informal; se anota el sponsor a mano y las disputas se resuelven caso a caso."},{"nivel":2,"ancla":"2 Atribución con un método repetible (código de referido) pero sin garantía de unicidad ni trazabilidad."},{"nivel":3,"ancla":"3 Atribución determinística definida: identificador único por sponsor capturado desde el primer contacto y registrado."},{"nivel":4,"ancla":"4 Atribución gestionada con medición de leads sin sponsor y regla clara para prospectos huérfanos o auto-registrados."},{"nivel":5,"ancla":"5 Atribución optimizada; trazabilidad completa del recorrido del prospecto y disputas resueltas con evidencia del sistema."}]},"sistemas":{"referenciaMp":"§4 (2.1 atribución a sponsor), §5","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; el sponsor se registra en un campo libre editable sin control."},{"nivel":1,"ancla":"1 Campo de sponsor en planilla o formulario, sin validación de unicidad."},{"nivel":2,"ancla":"2 Códigos de referido gestionados manualmente; riesgo de duplicidad o reutilización."},{"nivel":3,"ancla":"3 Enlaces, códigos o QR únicos por sponsor generados por el sistema y ligados al registro del prospecto."},{"nivel":4,"ancla":"4 Plataforma que traza el origen del prospecto extremo a extremo y bloquea altas sin atribución válida."},{"nivel":5,"ancla":"5 Atribución integrada con genealogía y motor de comisiones; la asignación fluye sin intervención manual."}]},"agentico":{"anclas":[{"nivel":0,"ancla":"0 Sin IA; la verificación de atribución es completamente manual."},{"nivel":1,"ancla":"1 Alertas simples cuando un prospecto llega sin código de sponsor."},{"nivel":2,"ancla":"2 Copiloto que sugiere el sponsor probable ante atribución ambigua para revisión."},{"nivel":3,"ancla":"3 Agente supervisado que detecta conflictos de atribución (doble sponsor, cross-lining) y los reporta."},{"nivel":4,"ancla":"4 Agentes que reconcilian la atribución entre canales y proponen resolución de disputas de forma coordinada."},{"nivel":5,"ancla":"5 Resolución autónoma de atribución dentro de políticas definidas, con escalamiento solo por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Atribución y genealogía","tipo":"S4DS","categoria":"Motor de atribución y genealogía del CRM transaccional","coberturaS4DS":"módulo Genealogía · enlaces/códigos únicos por sponsor · MCP attribution/genealogy tools","nota":"Genera el identificador único por sponsor, lo liga al registro del prospecto desde el primer contacto y lo propaga sin recálculo local hacia comisiones."},{"nombre":"Plataforma DMS/MLM (genealogía núcleo)","tipo":"tercero","categoria":"Distributor Management System — motor de genealogía y comisiones","ejemplos":["Exigo","InfoTrax FlexCloud","Epixel","DirectScale"],"nota":"Cuando la atribución vive en el DMS núcleo que también calcula comisiones; InfoTrax FlexCloud y Exigo destacan por motores de genealogía diseña
1dos para árboles multi-plan a escala."},{"nombre":"Detección de anomalías / fraude estructural","tipo":"tercero","categoria":"Scoring de anomalías de velocidad/geografía y fraude interno","ejemplos":["Sardine.ai (adaptable a scoring de anomalías)","módulos anti-fraude de DMS (Epixel)"],"nota":"Complementa la atribución determinística con detección de patrones de cross-lining o spillover abuse."}],"agentesYUseCase":[{"useCase":"Copiloto de atribución ambigua: cuando un prospecto llega sin código de sponsor válido o con señales conflictivas, sugiere el sponsor probable con la evidencia (canal, referido, historial de interacción) para que un humano confirme.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — sugiere; el humano decide","valor":"reduce el tiempo de resolución de casos de atribución ambigua sin asignar de forma automática"},{"useCase":"Agente supervisado de detección de conflictos: revisa continuamente las nuevas altas buscando cross-lining, doble sponsor o reutilización de códigos, y abre un caso de excepción para compliance/field ops.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — detecta y reporta; el humano resuelve","valor":"detiene el cross-lining antes de que corrompa la genealogía y las comisiones de dos líneas"},{"useCase":"Reconciliación coordinada de atribución: agentes que correlacionan atribución entre canales (sitio replicado, evento, referido manual) y proponen la resolución de disputas de sponsor con la evidencia consolidada.","t
1ipo":"S4DS","nivelAutonomia":"multi-agente (nivel 4) — coordina evidencia; comité de compliance decide","valor":"convierte una disputa de sponsor en una decisión basada en evidencia trazable, no en memoria"}],"metadata":{"evidenciaEsperada":"Mecanismo de atribución (enlace/código/QR único) por sponsor + trazabilidad de la asignación de un prospecto reciente.","dolorAsociado":"Disputas de sponsor resueltas de memoria; cross-lining y cuentas huérfanas que corrompen la genealogía y las comisiones.","frenteRecomendacion":"Tecnología e Integración","fuente":"MASTER-C01 §4 (2.1 Lead y atribución al sponsor), §3 (SoD / cambios de sponsor), §8 (fraude interno: cross-lining)"},"camposFaltantes":[]},{"practiceId":"C01-01-PR-04","processId":"C01","temaId":"c01-reclutamiento-y-captacion","nombre":"Toolkits de social selling aprobados y versionados","pregunta":"¿La fuerza de ventas dispone de toolkits de reclutamiento aprobados y versionados, y podemos saber qué versión usa cada representante?","enunciado":"La fuerza de ventas dispone de toolkits de contenido de reclutamiento y producto previamente aprobados y versionados, de modo que los representantes promueven la oportunidad con material ya revisado contra las reglas de cumplimiento, y la organización puede saber qué versión aprobada usa cada representante y retirar el material que deja de ser conforme. El objetivo es habilitar la promoción de campo con material seguro en lugar de dejar que cada persona improvise el suyo.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin toolkits; cada representante crea su propio material de reclutamiento sin revisión."},{"nivel":1,"ancla":"1 Algún material compartido informalmente, sin aprobación ni control de versión."},{"nivel":2,"ancla":"2 Biblioteca de material repetible, pero sin revisión de cumplimiento sistemática ni versionado."},{"nivel":3,"ancla":"3 Toolkits aprobados por cumplimiento, versionados y publicados como material oficial de reclutamiento."},{"nivel":4,"ancla":"4 Uso gestionado: se mide la adopción del material oficial y se retira o actualiza el material vencido con re-difusión."},{"nivel":5,"ancla":"5 Ningún representante distribuye una versión retirada del toolkit: la versión vigente por pieza y la que efectivamente circula coinciden siempre, verificado por versión."}]},"sistemas":{"referenciaMp":"§10 (compliance gating de sitios replicados/UGC), §5","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; material disperso en chats y dispositivos personales."},{"nivel":1,"ancla":"1 Carpeta compartida con archivos sin control de versión ni permisos."},{"nivel":2,"ancla":"2 Repositorio documental con versionado básico del material aprobado."},{"nivel":3,"ancla":"3 Gestor de activos digitales (DAM) con material aprobado, versión vigente y control de acceso por rol."},{"nivel":4,"ancla":"4 Plataforma que distribuye los toolkits y registra qué versión descarga o usa cada representante."},{"nivel":5,"ancla":"5 Ecosistema donde el material aprobado se propaga a sitios replicados y canales, retirando versiones obsoletas automáticamente."}]},"agentico":{"referenciaMp":"§6 (IA generativa / riesgo de earnings claims)","anclas":[{"nivel":0,"ancla":"0 Sin IA; la creación y revisión de material es totalmente manual."},{"nivel":1,"ancla":"1 IA generativa usada puntualmente para redactar borradores de contenido bajo demanda."},{"nivel":2,"ancla":"2 Copiloto que genera contenido a partir de plantillas aprobadas y marca lenguaje riesgoso."},{"nivel":3,"ancla":"3 Agente supervisado que revisa el material contra reglas de cumplimiento y sugiere correcciones antes de aprobar."},{"nivel":4,"ancla":"4 Agentes que generan, versionan y verifican toolkits de forma coordinada con supervisión humana."},{"nivel":5,"ancla":"5 Generación y curaduría autónoma de toolkits conformes, dentro de políticas, con revisión solo por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Toolkits y compliance gating de contenido","tipo":"S4DS","categoria":"Gestión de activos de reclutamiento del CRM","coberturaS4DS":"módulo Contenido/Toolkits · versión vigente por pieza · compliance gating de sitios replicados · MCP content tools","nota":"Publica el material aprobado con versión vigente, retira ver
1siones obsoletas y controla las áreas editables de los sitios replicados por representante."},{"nombre":"DAM (Digital Asset Management)","tipo":"tercero","categoria":"Gestión de activos digitales y versionado","ejemplos":["Bynder","Widen","Brandfolder"],"nota":"Cuando el toolkit vive en un DAM corporativo separado del CRM/DMS de reclutamiento."},{"nombre":"Plataforma DMS/MLM con sitios replicados controlados","tipo":"tercero","categoria":"Distributor Management System — réplica web con áreas editables limitadas","ejemplos":["Epixel","Exigo","ByDesign (Freedom)"],"nota":"Epixel destaca por controlar explícitamente qué áreas del sitio replicado son editables por el representante."},{"nombre":"Gestión de biblioteca de contenido / LMS de habilitación","tipo":"tercero","categoria":"Distribución y adopción de material de campo","ejemplos":["Rallyware","Seismic"],"nota":"Distribuye el toolkit y registra qué versión descarga o usa cada representante."}],"agentesYUseCase":[{"useCase":"Copiloto de generación de contenido: genera borradores de material de reclutamiento a partir de plantillas ya aprobadas, marcando lenguaje riesgoso (claims de ingreso, promesas implícitas) antes de que llegue a revisión.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — genera y marca riesgo; compliance aprueba","valor":"acelera la producción de material de campo sin abrir la puerta a earnings claims no revisados"},{"useCase":"Agente supervisado de revisión de cumplimiento: evalúa cada pieza propuesta contra las reglas de compliance vigentes (lenguaje de ingresos, disclaimers requeridos) y sugiere correcciones antes de aprobar.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — revisa y sugiere; compliance aprueba la versión final","valor":"estandariza la revisión de cumplimiento y reduce el tiempo entre creación y publicación"},{"useCase":"Agentes coordinados de versionado y distribución: generan, versionan y verifican que el toolkit vigente se propague a todos los canales (sitios replicados, redes, apps) retirando automáticamente versiones obsoletas.","tipo":"S4DS","nivelAutonomia":"multi-agente (nivel 4) — coordina distribución; supervisión humana en cambios de política","valor":"garantiza que ningún representante siga usando una versión retirada del material"}],"metadata":{"evidenciaEsperada":"Biblioteca de toolkits de reclutamiento aprobados con versión vigente + registro de aprobación de cumplimiento.","dolorAsociado":"Material de reclutamiento no oficial que circula sin revisión; imposibilidad de saber qué versión usa cada representante.","frenteRecomendacion":"Gobierno/Roles/Tercerización","fuente":"MASTER-C01 §2 (Reclutamiento/captación: separación contenido/IDS, UGC compliance), §10 (compliance gating de sitios replicados y UGC)"},"camposFaltantes":[]},{"practiceId":"C01-01-PR-05","processId":"C01","temaId":"c01-reclutamiento-y-captacion","nombre":"Trazabilidad del claim de ingreso mostrado antes de firmar","pregunta":"¿Podemos reconstruir exactamente qué afirmación de ingresos vio cada prospecto antes de firmar, con su versión y fecha?","enunciado":"Antes de que el prospecto firme, la organización registra qué afirmación de ingresos o ganancias se le mostró y puede reconstruirla después —capturando la versión, el momento y el contenido exactos de cualquier claim de ingreso presentado— de modo que pueda demostrar qué sustentación vio el prospecto, en defensa ante el escrutinio de afirmaciones de ingresos. La capacidad no es guardar un archivo suelto sino poder acreditar, por cada alta, qué vio esa persona y cuándo.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin trazabilidad; no queda registro de qué se le mostró al prospecto sobre ingresos antes de firmar."},{"nivel":1,"ancla":"1 Registro anecdótico; a veces se guarda el material, sin sistematizar ni fechar."},{"nivel":2,"ancla":"2 Se conserva el material mostrado de forma repetible, pero sin ligarlo al prospecto ni a la versión exacta."},{"nivel":3,"ancla":"3 Proceso definido: se registra qué claim de ingreso (versión y fecha) vio cada prospecto antes de firmar."},{"nivel":4,"ancla":"4 Trazabilidad gestionada con retención documentada (p. ej. 3 años) y auditoría de la sustentación por prospecto."},{"nivel":5,"ancla":"5 Trazabilidad optimizada; la sustentación del claim se enlaza automáticamente al expediente y se audita de forma continua."}]},"sistemas":{"referenciaMp":"§2 (sustentación de earnings claims), §4 (2.1 divulgación precontractual)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta;
1 lo mostrado al prospecto no queda en ningún sistema."},{"nivel":1,"ancla":"1 Capturas o archivos sueltos guardados manualmente sin vínculo al prospecto."},{"nivel":2,"ancla":"2 Repositorio del material presentado, sin timestamp ni versión ligada al prospecto."},{"nivel":3,"ancla":"3 Sistema que registra versión, fecha y contenido del claim mostrado y lo liga al registro del prospecto."},{"nivel":4,"ancla":"4 Plataforma con log inmutable y retención configurable de la sustentación por prospecto y versión."},{"nivel":5,"ancla":"5 Ecosistema donde cada claim mostrado queda trazado extremo a extremo y disponible para auditoría sin intervención manual."}]},"agentico":{"anclas":[{"nivel":0,"ancla":"0 Sin IA; la reconstrucción de qué vio el prospecto es manual, si es posible."},{"nivel":1,"ancla":"1 IA que ayuda a etiquetar o resumir el material mostrado bajo demanda."},{"nivel":2,"ancla":"2 Copiloto que verifica que el claim presentado corresponde a una versión aprobada."},{"nivel":3,"ancla":"3 Agente supervisado que detecta claims de ingreso no aprobados o vencidos mostrados a prospectos y alerta."},{"nivel":4,"ancla":"4 Agentes que correlacionan el material mostrado con la sustentación y arman el expediente de defensa de forma coordinada."},{"nivel":5,"ancla":"5 Detección autónoma y continua de riesgo de earnings claim en el material que circula, dentro de políticas, con escalamiento a compliance solo por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Trazabilidad del claim de ingreso","tipo":"S4DS","categoria":"Log de sustentación y audit trail del CRM","coberturaS4DS":"módulo Compliance · registro versión/fecha/contenido del claim ligado al prospecto · MCP audit tools","nota":"Enlaza automáticamente el claim de ingreso mostrado a la firma del prospecto, con versión, fecha y contenido exacto, disponible para auditoría sin reconstrucción manual."},{"nombre":"Firma electrónica con audit trail","tipo":"tercero","categoria":"e-Signature certificada","ejemplos":["DocuSign eSignature"],"nota":"Estándar de facto para vincular el certificado de firma a la versión exacta del documento (incluido el IDS) vigente al momento del enrolamiento."},{"nombre":"Gestión documental con control de versiones","tipo":"tercero","categoria":"Versionado y retención documental","ejemplos":["SharePoint","Box Governance"],"nota":"Para retener versiones históricas del IDS y del material de ingreso con fecha de vigencia."},{"nombre":"Log inmutable / append-only storage","tipo":"tercero","categoria":"Almacenamiento de auditoría a prueba de manipulación","ejemplos":["AWS QLDB","soluciones de blockchain ligero para audit trail"],"nota":"Para garantizar que el registro de qué se mostró no pueda alterarse retroactivamente."}],"agentesYUseCase":[{"useCase":"Copiloto de verificación de versión: antes de que el claim de ingreso se presente al prospecto, verifica que corresponde a una versión aprobada y vigente del IDS o material de sustentación.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — verifica y alerta; el representante confirma","valor":"evita mostrar sin querer una versión desactualizada o no aprobada del claim de ingreso"},{"useCase":"Agente supervisado de detección de claims no aprobados: rastrea el material efectivamente mostrado (incluido contenido de video o redes) y alerta cuando detecta un claim de ingreso vencido o no aprobado presentado a un prospecto.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — detecta y alerta; compliance investiga","valor":"cierra la brecha entre lo que corporate aprobó y lo que efectivamente circuló en el campo"},{"useCase":"Agentes coordinados de armado de expediente: correlacionan el material mostrado con su sustentación documental y ensamblan el expediente de defensa por prospecto ante una solicitud de auditoría o disputa.","tipo":"S4DS","nivelAutonomia":"multi-agente (nivel 4) — ensambla evidencia; legal/compliance la valida","valor":"convierte una auditoría que tomaría semanas de búsqueda manual en un expediente reconstruible en minutos"}
1],"metadata":{"evidenciaEsperada":"Registro, para una muestra de altas recientes, del claim de ingreso mostrado (versión, fecha, contenido) antes de la firma.","dolorAsociado":"Imposibilidad de demostrar qué afirmación de ingresos vio el prospecto; exposición ante el escrutinio de earnings claims (FTC) sin sustentación reconstruible.","frenteRecomendacion":"Gobierno/Roles/Tercerización","fuente":"MASTER-C01 §2 (trazabilidad del claim de ingreso pre-firma), §4 (2.1 divulgación precontractual), §8 (income claims indebidos)"},"camposFaltantes":[]},{"practiceId":"C01-01-PR-06","processId":"C01","temaId":"c01-reclutamiento-y-captacion","nombre":"Separación contenido-IDS y control del marketing de campo no oficial","pregunta":"¿Mantenemos separado el contenido promocional del disclosure oficial de ingresos y controlamos (aprobación o sanción) el material de reclutamiento que genera la fuerza de ventas?","enunciado":"La organización mantiene una separación gobernada entre el contenido promocional de producto y oportunidad y la divulgación oficial de ingresos, y captura, aprueba o sanciona el material de reclutamiento que genera la fuerza de ventas (publicaciones en redes, grupos, videos), de modo que el marketing de campo no oficial no tergiverse la oportunidad ni sustituya a la divulgación oficial. La capacidad cierra la brecha entre el cumplimiento corporativo y lo que efectivamente se comunica en el campo.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin separación ni control; el contenido de campo mezcla promoción con afirmaciones de ingreso sin supervisión."},{"nivel":1,"ancla":"1 Reglas informales conocidas; el marketing de campo no oficial circula sin flujo de aprobación ni sanción."},{"nivel":2,"ancla":"2 Política enunciada de separación contenido/disclosure, aplicada de forma inconsistente."},{"nivel":3,"ancla":"3 Separación definida entre contenido promocional y divulgación oficial + flujo de aprobación del material de campo."},{"nivel":4,"ancla":"4 Control gestionado: monitoreo de UGC, aprobación documentada y régimen de sanción por incumplimiento aplicado."},{"nivel":5,"ancla":"5 Ningún contenido de campo no conforme permanece visible tras ser detectado: la vigilancia de canales es continua, no solo por denuncia, y la corrección o sanción sigue siempre el régimen de escalamiento definido."}]},"sistemas":{"referenciaMp":"§10 (compliance gating de UGC), §2","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; no hay forma de capturar ni revisar el contenido que publica la fuerza de ventas."},{"nivel":1,"ancla":"1 Reportes manuales de material problemático detectado por casualidad."},{"nivel":2,"ancla":"2 Buzón o formulario para reportar material de campo, sin flujo estructurado."},{"nivel":3,"ancla":"3 Herramienta de captura y aprobación de creatividades con flujo de cumplimiento y registro de la decisión."},{"nivel":4,"ancla":"4 Social listening + flujo de aprobación integrados; detección de contenido de campo no conforme con alertas."},{"nivel":5,"ancla":"5 Ecosistema que monitorea canales, enruta material a aprobación y bloquea o retira contenido no conforme de forma integrada."}]},"agentico":{"referenciaMp":"§6 (detección con IA)","anclas":[{"nivel":0,"ancla":"0 Sin IA; la detección de contenido no oficial es manual y reactiva."},{"nivel":1,"ancla":"1 Alertas simples por palabras clave de riesgo en el contenido reportado."},{"nivel":2,"ancla":"2 Copiloto que clasifica el material de campo y marca posibles infracciones para revisión."},{"nivel":3,"ancla":"3 Agente supervisado que rastrea canales, detecta earnings claims no oficiales y los enruta a cumplimiento."},{"nivel":4,"ancla":"4 Agentes que monitorean, clasifican y priorizan el UGC no conforme de forma coordinada con supervisión."},{"nivel":5,"ancla":"5 Monitoreo autónomo del marketing de campo con enforcement dentro de políticas y escalamiento por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Compliance gating de contenido y UGC","tipo":"S4DS","categoria":"Gobierno de contenido de campo del CRM","coberturaS4DS":"módulo Compliance · separación contenido/IDS · flujo de aprobación/sanción de UGC · MCP compliance tools","nota":"Mantiene la separación funcional entre contenido promocional y disclosure oficial, y registra el flujo de aprobación o sanción del material de reclutamiento generado por la fuerza de ventas."},{"nombre":"Social listening / monitoreo de UGC","tipo":"tercero","categoria":"Vigilancia proactiva de redes y contenido generado por usuarios","ejemplos":["Brandwatch","Meltwater","Talkwalker"],"nota":"Detecta contenido de campo (earnings claims no oficiales, lenguaje riesgoso) publicado en redes por la fuerza de ventas, de forma proactiva y no solo por denuncia."},{"nombre":"Autorregulación sectorial / referido cross-empresa","tipo":"tercero","categoria":"Monitoreo sectorial y enforcement de código de ética","ejemplos":["DSSRC (BBB National Programs) — programa de monitoreo, no producto de softw
1are"],"nota":"Referencia de estándar: el DSSRC monitorea proactivamente redes sociales de la fuerza de ventas del sector y refiere casos a la FTC/AG estatal; ilustra el nivel de vigilancia esperado."},{"nombre":"Gestión de casos de compliance","tipo":"tercero","categoria":"Flujo de sanción y escalamiento documentado","ejemplos":["ServiceNow GRC","NAVEX"],"nota":"Para documentar el patrón de escalamiento progresivo (advertencia → suspensión → terminación) con trazabilidad."}],"agentesYUseCase":[{"useCase":"Copiloto de clasificación de UGC: revisa el material de campo reportado o monitoreado y lo clasifica por tipo de riesgo (earnings claim implícito, lenguaje de ingreso, disclaimer faltante) para priorizar la revisión de compliance.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — clasifica; compliance decide la acción","valor":"convierte un volumen inabordable de contenido de campo en una cola priorizada por riesgo real"},{"useCase":"Agente supervisado de rastreo de canales: monitorea de forma continua redes y grupos conocidos de la fuerza de ventas, detecta earnings claims no oficiales y los enruta automáticamente a compliance con la evidencia capturada.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — detecta y enruta; compliance investiga y sanciona","valor":"pasa de vigilancia reactiva por denuncia a detección sistemática y proactiva"},{"useCase":"Agentes coordinados de monitoreo y priorización: combinan social listening, clasificación de riesgo y seguimiento del historial de infracciones del representante para priorizar casos con supervisión de compliance.","tipo":"S4DS","nivelAutonomia":"multi-agente (nivel 4) — coordina detección y priorización; comité de compliance decide sanción","valor":"sostiene un régimen de enforcement consistente y escalable sin crecer linealmente el equipo de revisión"}],"metadata":{"evidenciaEsperada":"Política de separación contenido/IDS + registro de casos de material de campo revisados, aprobados o sancionados.","dolorAsociado":"Brecha entre el cumplimiento corporativo y el marketing de campo no oficial (redes/grupos) — vector de settlements FTC (AdvoCare, LuLaRoe, Neora).","frenteRecomendacion":"Gobierno/Roles/Tercerización","fuente":"MASTER-C01 §2 (separación contenido/IDS, UGC compliance), §8.1 (income claims indebidos), §10 (compliance gating de UGC)"},"camposFaltantes":[]},{"practiceId":"C01-02-PR-01","processId":"C01","temaId":"c01-inscripcion-y-alta-contractual","nombre":"Sign-up digital de pocos pasos y escalable","pregunta":"¿El alta contractual se completa en un flujo digital de pocos pasos, en autoservicio y capaz de sostener picos de altas masivas sin degradarse?","enunciado":"La organización realiza el alta del nuevo vendedor mediante un flujo de inscripción digital de pocos pasos guiados que el candidato completa en autoservicio, sin recaptura manual ni papel, y que sostiene los picos de altas (lanzamientos, convenciones, promociones) sin degradarse. De este modo el alta deja de ser una tarea administrativa lenta y depen
1diente de quién acompañe al candidato, y se convierte en un proceso repetible que reduce la fricción hasta el inicio real de la actividad.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin flujo definido; el alta se hace en papel o por captura manual caso a caso."},{"nivel":1,"ancla":"1 Alta digital ad-hoc; los pasos varían según quién acompañe al candidato."},{"nivel":2,"ancla":"2 Flujo de alta repetible con pasos básicos, aplicado de forma parcial y no siempre en autoservicio."},{"nivel":3,"ancla":"3 Flujo de inscripción digital definido, documentado y estandarizado, de pocos pasos y en autoservicio."},{"nivel":4,"ancla":"4 Alta gestionada con KPIs (tasa de finalización, tiempo de alta, abandono por paso) y capacidad probada en picos."},{"nivel":5,"ancla":"5 Ningún paso del flujo de alta se mantiene sin rediseño cuando la fricción medida supera el objetivo del periodo; el desempeño se sostiene sin degradación verificada en altas masivas (picos, lanzamientos)."}]},"sistemas":{"referenciaMp":"§4 (2.2 Inscripción), §5 (sitios replicados/DMS), §8 (7 escalabilidad de altas masivas)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; formularios en papel o documentos sueltos digitalizados a mano."},{"nivel":1,"ancla":"1 Formulario web aislado o planilla; sin conexión con el resto del flujo de alta."},{"nivel":2,"ancla":"2 Portal o formulario especializado de alta, sin integración con verificación, genealogía ni back-office."},{"nivel":3,"ancla":"3 Portal de alta integrado con el registro del vendedor y los pasos siguientes del flujo."},{"nivel":4,"ancla":"4 Plataforma de alta con datos en tiempo real y arquitectura que absorbe picos de demanda sin caídas."},{"nivel":5,"ancla":"5 Ecosistema de alta desacoplado (comercio/identidad/comisiones escalan por separado) con alta disponibilidad en picos y cero recaptura manual."}]},"agentico":{"referenciaMp":"§6 (onboarding conversacional)","anclas":[{"nivel":0,"ancla":"0 Sin IA; el candidato completa el alta sin asistencia automatizada."},{"nivel":1,"ancla":"1 Asistencia puntual de IA que responde dudas del alta bajo demanda."},{"nivel":2,"ancla":"2 Copiloto que guía al candidato paso a paso y precompleta campos para su confirmación."},{"nivel":3,"ancla":"3 Agente supervisado que conduce el alta de principio a fin y deja la ejecución lista para revisión humana."},{"nivel":4,"ancla":"4 Múltiples agentes coordinan alta, verificación y provisión con supervisión global."},{"nivel":5,"ancla":"5 Alta conversacional autónoma que se adapta al candidato y a la carga, con intervención solo por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Inscripción digital (sign-up de autoservicio)","tipo":"S4DS","categoria":"Alta y onboarding del CRM transaccional","coberturaS4DS":"módulo Inscripción · flujo guiado de pocos pasos · precompletado desde enlace de sponsor · MCP onboarding tools","nota":"Ejecuta el alta en autoservicio sin recaptura manual, con validación en línea de cada paso."},{"nombre":"Plataforma DMS/MLM (motor de alta y sign-up nativo)","tipo":"tercero","categoria":"Distributor Management System","ejemplos":["Exigo","DirectScale","ByDesign (Freedom)","Epixel"],"nota":"Sign-up integrado con genealogía y comisiones desde el mismo alta, sin transferencia manual entre sistemas."}
1,{"nombre":"Infraestructura cloud auto-escalable","tipo":"tercero","categoria":"Escalabilidad e infraestructura","ejemplos":["AWS Auto Scaling","Azure App Service scale-out","Cloudflare"],"nota":"Absorbe picos de altas masivas en lanzamientos/convenciones sin degradar tiempos de respuesta del formulario."},{"nombre":"Analítica de embudo y abandono","tipo":"tercero","categoria":"Product analytics","ejemplos":["Amplitude","Mixpanel"],"nota":"Mide tasa de finalización, tiempo de alta y abandono por paso para recalibrar el flujo continuamente."}],"agentesYUseCase":[{"useCase":"Copiloto de guiado del alta: acompaña al candidato paso a paso, precompleta campos a partir del enlace de sponsor y valida datos en línea antes de avanzar.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — guía y sugiere; el candidato confirma","valor":"reduce el abandono del formulario y elimina la dependencia de que el patrocinador dicte los datos"},{"useCase":"Agente supervisado de recuperación de abandono: detecta altas incompletas por paso y dispara un recordatorio o retoma la sesión donde quedó, reportando el patrón a Field Ops.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — actúa y reporta; el humano revisa el patrón agregado","valor":"convierte el abandono de un dato perdido en una oportunidad de conversión recuperada"},{"useCase":"Guardián de capacidad: monitorea la demanda del flujo de alta en tiempo real y dispara el auto-escalado de infraestructura antes de que un pico de convención degrade el sign-up.","tipo":"tercero","nivelAutonomia":"agente supervisado (nivel 3)","ejemplos":["AWS Auto Scaling con alarmas predictivas","Datadog Watchdog"],"valor":"evita que el éxito de un lanzamiento se traduzca en caídas del sistema de alta"},{"useCase":"Chatbot conversacional de sign-up: resuelve dudas del candidato sobre requisitos y pasos del alta sin intervención humana, disponible 24/7 durante campañas de reclutamiento masivo.","tipo":"tercero","nivelAutonomia":"agente supervisado (nivel 3)","ejemplos":["Epixel AI onboarding chatbot","Rallyware"],"valor":"sostiene el volumen de consultas de un pico de altas sin escalar soporte humano proporcionalmente"}],"metadata":{"evidenciaEsperada":"Flujo de sign-up digital vigente (pasos y pantallas) + métricas de finalización y tiempo de alta de la última campaña de reclutamiento.","dolorAsociado":"Altas lentas o en papel con recaptura manual; abandono en el formulario; caídas del alta durante lanzamientos y convenciones.","frenteRecomendacion":"Eficiencia/Simplificación de Proceso","fuente":"MASTER-C01 §2.2 (Inscripción), §5 (sitios replicados/DMS), §8.7 (escalabilidad de altas masivas), §10 quick-win"},"camposFaltantes":[]},{"practiceId":"C01-02-PR-02","processId":"C01","temaId":"c01-inscripcion-y-alta-contractual","nombre":"Aceptación auditable y separada de los instrumentos contractuales","pregunta":"¿La aceptación de cada instrumento (acuerdo de distribución, política y procedimientos, y divulgación de ingresos) se registra por separado, con versión exacta, sello de tiempo e identidad, en lugar de un único 'acepto todo'?","enunciado":"Al inscribirse, el candidato acepta cada instrumento contractual —el acuerdo de distribución, la política y procedimientos, y la divulgación de ingresos— mediante un acto de aceptación distinto y separado para cada uno (no un único \\"acepto todo\\"), y cada aceptación deja registrada la versión exacta aceptada, el sello de tiempo y la identidad de quien acepta. Así la organización puede demostrar qué divulgación vio y aceptó cada vendedor, en lugar de depender de un consentimiento global que no distingue entre documentos.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin aceptación estructurada; se firma un único bloque o nada queda registrado por instrumento."},{"nivel":1,"ancla":"1 Aceptación informal; a veces se guarda un 'acepto todo' sin distinguir instrumentos."},{"nivel":2,"ancla":"2 Aceptación repetible pero conjunta; los tres instrumentos se aceptan en un solo acto sin separar la divulgación de ingresos."},{"nivel":3,"ancla":"3 Aceptación definida y separada por instrumento (acuerdo, política y procedimientos, divulgación de ingresos) con versión, sello de tiempo e identidad registrados."},{"nivel":4,"ancla":"4 Aceptación gestionada con auditoría de que cada vendedor aceptó cada instrumento por separado y trazabilidad completa del acto."},{"nivel":5,"ancla":"5 Aceptación optimizada; la evidencia por instrumento se concilia y audita de forma continua sin intervención manual."}]},"sistemas":{"referenciaMp":"§2 (aceptación auditable), §5 (firma electrónica ligada a versión), §4 (2.2)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta;
1 la aceptación no queda en ningún sistema o es un documento firmado a mano."},{"nivel":1,"ancla":"1 Casilla única de aceptación en un formulario, sin registro de versión ni de identidad."},{"nivel":2,"ancla":"2 Firma electrónica del acuerdo, sin acto separado para la divulgación de ingresos ni vínculo a la versión exacta."},{"nivel":3,"ancla":"3 Sistema que captura aceptación separada por instrumento con versión, sello de tiempo, identidad e IP/dispositivo."},{"nivel":4,"ancla":"4 Plataforma con registro inmutable de cada aceptación ligada al certificado de firma y a la versión vigente al enrolarse."},{"nivel":5,"ancla":"5 Ecosistema donde cada acto de aceptación queda trazado extremo a extremo y disponible para auditoría sin transferencias manuales."}]},"agentico":{"anclas":[{"nivel":0,"ancla":"0 Sin IA; la verificación de que se aceptó cada instrumento es manual."},{"nivel":1,"ancla":"1 Alertas simples cuando falta la aceptación de algún instrumento."},{"nivel":2,"ancla":"2 Copiloto que verifica que cada instrumento fue aceptado por separado y en su versión vigente antes de completar el alta."},{"nivel":3,"ancla":"3 Agente supervisado que detecta altas con aceptación incompleta o conjunta y las reporta."},{"nivel":4,"ancla":"4 Agentes que reconcilian la evidencia de aceptación entre instrumentos y arman el expediente de forma coordinada."},{"nivel":5,"ancla":"5 Verificación autónoma de la aceptación separada dentro de políticas definidas, con escalamiento solo por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Aceptación auditable de instrumentos contractuales","tipo":"S4DS","categoria":"Contratos y firma del CRM transaccional","coberturaS4DS":"módulo Contratos/Firma · registro de aceptación separado por instrumento (Agreement/P&P/IDS) con versión, timestamp e identidad · MCP compliance tools","nota":"Registra cada instrumento como acto de aceptación independiente, listo para exhibirse en auditoría."},{"nombre":"Firma electrónica (e-signature)","tipo":"tercero","categoria":"e-signature con audit trail","ejemplos":["DocuSign eSignature","Adobe Sign"],"nota":"Estándar de facto para firma con certificado y audit trail; el criterio de madurez es que el certificado quede vinculado a la versión exacta del documento."},{"nombre":"Plataforma DMS/MLM (módulo de aceptación de acuerdos)","tipo":"tercero","categoria":"Distributor Management System","ejemplos":["Exigo","DirectScale","ByDesign (Freedom)","Epixel"],"nota":"Muchas plataformas ofrecen captura de aceptación nativa; el gap típico es que no separan el IDS del acuerdo comercial por defecto."}],"agentesYUseCase":[{"useCase":"Verificador de aceptación completa: antes de cerrar el alta, comprueba que existan los tres actos de aceptación separados (acuerdo, P&P, IDS) con versión vigente y bloquea la finalización si alguno falta o quedó conjunto.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — verifica y bloquea; no decide contenido","valor":"impide que un alta se complete con consentimiento incompleto o ambiguo"},{"useCase":"Agente supervisado de auditoría de aceptación: revisa altas ya cerradas y detecta patrones de aceptación conjunta o incompleta que se filtraron, reportando el lote a compliance.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — detecta y reporta; el humano corrige","valor":"encuentra huecos de sustentación antes de que aparezcan en una auditoría externa"},{"useCase":"Compilador de expediente de aceptación: ante una solicitud de auditoría o litigio, ensambla el paquete de evidencia (documento, versión, timestamp, identidad, IP/dispositivo) de un vendedor específico.","tipo":"tercero","nivelAutonomia":"copiloto (nivel 2)","ejemplos":["DocuSign Insights / Certificate of Completion"],"valor":"reduce de días a minutos el tiempo de respuesta ante una solicitud de sustentación"}],"metadata":{"evidenciaEsperada":"Registro de aceptación de una muestra de altas recientes que muestre firma/aceptación separada del acuerdo, la política y procedimientos y la divulgación de ingresos, cada una con versión, fecha e identidad.","dolorAsociado":"Un único 'acepto todo' que impide demostrar qué divulgación de ingresos vio y aceptó cada vendedor; exposición ante el escrutinio de earnings claims sin consentimiento separado del IDS.","frenteRecomendacion":"Gobierno/Roles/Tercerización","fuente":"MASTER-C01 §2 (Inscripción y aceptación auditable: firma separada del IDS), §4.2.2, §5 (firma electrónica ligada a la versión exacta), §10 quick-win"},"camposFaltantes":[]},{"practiceId":"C01-02-PR-03","processId":"C01","temaId":"c01-inscripcion-y-alta-contractual","nombre":"Versionado de documentos legales y re-aceptación al cambiar de versión","pregunta":"¿Los documentos legales están versionados y, al cambiar de versión, forzamos la re-aceptación de la nueva ver
1sión antes de que el vendedor siga operando?","enunciado":"Los documentos contractuales (acuerdo, política y procedimientos, y divulgación de ingresos) están versionados formalmente, y cuando una versión cambia se exige al vendedor afectado re-aceptar la nueva versión antes de continuar operando, con vigencia prospectiva y una ventana de notificación. De esta forma el consentimiento corresponde siempre a la versión en vigor y nadie opera bajo un documento que nunca aceptó, en lugar de comunicar los cambios sin dejar constancia de la aceptación.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin versionado; los documentos cambian sin control de versión ni re-aceptación."},{"nivel":1,"ancla":"1 Versionado informal; los cambios se comunican sin exigir re-aceptación."},{"nivel":2,"ancla":"2 Versionado repetible pero la re-aceptación es opcional o solo se pide en la renovación."},{"nivel":3,"ancla":"3 Versionado definido de cada documento con re-aceptación forzada al cambiar de versión, vigencia prospectiva y ventana de notificación."},{"nivel":4,"ancla":"4 Re-aceptación gestionada con medición de cobertura y bloqueo de operación a quien no re-acepta la versión vigente."},{"nivel":5,"ancla":"5 Ningún vendedor opera con una versión de instrumento legal retirada: publicar una nueva versión dispara la re-aceptación y bloquea la operación hasta confirmarla, con trazabilidad de la versión aceptada por cada vendedor."}]},"sistemas":{"referenciaMp":"§3 (versionado de P&P: enmiendas vinculantes a 30 días y prospectivas), §2.8 (renovación revalida disclosure)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; una sola copia del documento sin historial de versiones."},{"nivel":1,"ancla":"1 Documentos versionados a mano en una carpeta; sin vínculo con la aceptación del vendedor."},{"nivel":2,"ancla":"2 Repositorio documental con versionado, sin forzar re-aceptación al publicar una nueva versión."},{"nivel":3,"ancla":"3 Sistema que liga cada versión publicada a la aceptación del vendedor y solicita re-aceptación al cambiar."},{"nivel":4,"ancla":"4 Plataforma que bloquea la operación hasta re-aceptar la versión vigente y registra la re-aceptación con sello de tiempo."},{"nivel":5,"ancla":"5 Ecosistema donde publicar una versión propaga la re-aceptación requerida y retira la vigencia de la anterior sin intervención manual."}]},"agentico":{"anclas":[{"nivel":0,"ancla":"0 Sin IA; el control de quién opera bajo una versión obsoleta es manual."},{"nivel":1,"ancla":"1 Recordatorios automáticos de que hay una nueva versión pendiente de aceptar."},{"nivel":2,"ancla":"2 Copiloto que resume los cambios de versión al vendedor y verifica su re-aceptación."},{"nivel":3,"ancla":"3 Agente supervisado que identifica vendedores operando bajo versiones vencidas y los enruta a re-aceptación."},{"nivel":4,"ancla":"4 Agentes que gestionan la campaña de re-aceptación y concilian la cobertura de forma coordinada."},{"nivel":5,"ancla":"5 Gestión autónoma del ciclo versión→re-aceptación dentro de políticas, con escalamiento por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Versionado documental y ciclo de re-aceptación","tipo":"S4DS","categoria":"Contratos y gestión de versiones del CRM transaccional","coberturaS4DS":"módulo Contratos · versionado de Agreement/P&P/IDS · disparo de campaña de re-aceptación y bloqueo de operación bajo versión vencida · MCP tools","nota":"Liga cada versión publicada a la re-aceptación requerida y retira la vigencia de la anterior sin intervención manual."},{"nombre":"CLM (Contract Lifecycle Management)","tipo":"tercero","categoria":"Gestión del ciclo de vida contractual","ejemplos":["Ironclad","DocuSign CLM"],"nota":"Gestiona el historial de versiones de documentos legales y su vínculo con cada firma/aceptación asociada."},{"nombre":"Plataforma DMS/MLM (control de versión de P&P nativo)","tipo":"tercero","categoria":"Distributor Management System","ejemplos":["Exigo","ByDesign (Freedom)","Epixel"],"nota":"Algunos DMS incluyen repositorio versionado de políticas; el gap típico es que no fuerzan re-aceptación automática al publicar."}],"agentesYUseCase":[{"useCase":"Copiloto de resumen de cambios: al publicar una nueva ver
1sión, resume al vendedor qué cambió respecto a la versión anterior y guía su re-aceptación.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — sugiere y explica; el vendedor decide y re-acepta","valor":"reduce la fricción de leer documentos legales completos en cada actualización"},{"useCase":"Agente supervisado de versión vencida: identifica vendedores que siguen operando bajo una versión que ya no está vigente y los enruta al flujo de re-aceptación, alertando a compliance si el vencimiento supera un umbral de días.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — detecta y enruta; compliance decide sanciones","valor":"cierra la ventana entre publicar una versión y que efectivamente rija sobre toda la red"},{"useCase":"Orquestador de campaña de re-aceptación: coordina el envío escalonado de recordatorios (email/SMS/in-app) hasta cerrar la cobertura de re-aceptación de la versión publicada.","tipo":"tercero","nivelAutonomia":"agente supervisado (nivel 3)","ejemplos":["Klaviyo workflows","HubSpot workflows"],"valor":"acelera la cobertura de re-aceptación sin depender de seguimiento manual por lote"}],"metadata":{"evidenciaEsperada":"Historial de versiones de los documentos legales + evidencia de una re-aceptación forzada tras un cambio de versión (quién re-aceptó, versión y fecha).","dolorAsociado":"Vendedores operando bajo versiones que nunca aceptaron; imposibilidad de demostrar consentimiento a la versión vigente al cambiar la política o la divulgación de ingresos.","frenteRecomendacion":"Gobierno/Roles/Tercerización","fuente":"MASTER-C01 §2 (versionado y re-certificación anual del IDS), §3 (versionado de P&P: enmiendas vinculantes 30 días, prospectivas), §2.8 (renovación revalida disclosure)"},"camposFaltantes":[]},{"practiceId":"C01-02-PR-04","processId":"C01","temaId":"c01-inscripcion-y-alta-contractual","nombre":"Retención y recuperabilidad de la evidencia de aceptación","pregunta":"¿Conservamos la evidencia de aceptación por un periodo definido (p. ej. ~3 años) y podemos recuperarla íntegra por vendedor para auditoría o defensa legal?","enunciado":"La evidencia de aceptación —qué versión aceptó cada vendedor, cuándo y con qué identidad— se conserva durante un periodo definido (p. ej. ~3 años) y puede recuperarse íntegra para auditoría o defensa legal, de modo que la organización pueda reconstruir en cualquier momento, por cada alta, el consentimiento y la divulgación exactos. La capacidad no es guardar archivos sueltos sino poder acreditar y localizar esa evidencia cuando se necesita, en lugar de descubrir que no existe o no aparece.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin retención definida; la evidencia se pierde o se sobrescribe."},{"nivel":1,"ancla":"1 Retención anecdótica; algunos registros se guardan sin política ni plazo."},{"nivel":2,"ancla":"2 Retención repetible pero sin plazo formal ni prueba de recuperabilidad."},{"nivel":3,"ancla":"3 Política de retención definida (p. ej. ~3 años) con evidencia archivada y recuperable por vendedor."},{"nivel":4,"ancla":"4 Retención gestionada con pruebas periódicas de recuperación y auditoría de integridad de la evidencia."},{"nivel":5,"ancla":"5 Retención optimizada; la evidencia se archiva, conserva y recupera de forma automática y verificada de extremo a extremo."}]},"sistemas":{"referenciaMp":"§1 (listo para la regla: retención 3 años), §2 (registro inmutable), §4 (2.9 archivo recuperable)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; la evidencia vive en archivos sueltos o correos sin respaldo."},{"nivel":1,"ancla":"1 Copias guardadas manualmente en carpetas, sin control de acceso ni plazo de retención."},{"nivel":2,"ancla":"2 Repositorio documental con la evidencia, sin inmutabilidad ni recuperación por vendedor garantizada."},{"nivel":3,"ancla":"3 Sistema con almacenamiento de la evidencia por vendedor, con control de acceso y plazo de retención configurado."},{"nivel":4,"ancla":"4 Plataforma con log inmutable y retención configurable, con recuperación indexada por vendedor y versión."},{"nivel":5,"ancla":"5 Ecosistema donde la evidencia se archiva y recupera para auditoría sin intervención manual, con integridad verificable."}]},"agentico":{"anclas":[{"nivel":0,"ancla":"0 Sin IA; localizar y recuperar la evidencia es un esfuerzo manual."},{"nivel":1,"ancla":"1 IA que ayuda a buscar o etiquetar la evidencia bajo demanda."},{"nivel":2,"ancla":"2 Copiloto que arma el paquete de evidencia de un vendedor a solicitud."},{"nivel":3,"ancla":"3 Agente supervisado que detecta evidencia faltante o próxima a vencer su retención y alerta."},{"nivel":4,"ancla":"4 Agentes que compilan el expediente de defensa (aceptación, versión, sustentación) de forma coordinada."},{"nivel":5,"ancla":"5 Gestión autónoma del ciclo de retención y recuperación dentro de políticas, con escalamiento por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Archivo de evidencia y retención de compliance","tipo":"S4DS","categoria":"Compliance y archivo del CRM transaccional","coberturaS4DS":"módulo Compliance · archivo inmutable de evidencia de aceptación · retención configurable por tipo de documento y jurisdicción · MCP compliance tools","nota":"Indexa la evidencia por vendedor y versión, permitiendo recuperación íntegra sin transferencias manuales."},{"nombre":"Almacenamiento inmutable (WORM)","tipo":"tercero","categoria":"Archivo y retención a largo plazo","ejemplos":["AWS S3 Object Lock","Azure Immutable Blob Storage","Iron Mountain"],"nota":"Garantiza que la evidencia archivada no pueda alterarse ni borrarse antes de que expire el plazo de retención."},{"nombre":"Firma electrónica (certificado y audit trail)","tipo":"tercero","categoria":"e-signature con evidencia probatoria","ejemplos":["DocuSign eSignature","Adobe Sign"],"nota":"El certificado de finalización y su audit trail son parte de la evidencia que debe retenerse y poder exhibirse."},{"nombre":"eDiscovery / gestión de litigios","tipo":"tercero","categoria":"Recuperación forense de evidencia","ejemplos":["Relativity","Everlaw"],"nota":"Para compañías con exposición litigiosa recurrente, estructura la recuperación de evidencia bajo estándares de admisibilidad legal."}],"agentesYUseCase":[{"useCase":"Vigía de vencimiento de retención: monitorea la evidencia archivada y alerta cuando está próxima a cumplir su plazo de retención mínimo o cuando falta evidencia esperada de un alta.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — detecta y alerta; compliance decide extender o liberar","valor":"evita perder evidencia relevante por vencimiento silencioso de una política de retención"},{"useCase":"Compilador de expediente de defensa: ante una solicitud de auditoría o litigio, ensambla el paquete completo de un vendedor —aceptación, versión, comunicaciones asociadas— listo para revisión legal.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — arma el paquete; legal lo valida antes de usarlo","valor":"reduce de semanas a minutos el tiempo de respuesta ante una solicitud de sustentación"},{"useCase":"Auditor de integridad de archivo: ejecuta pruebas periódicas de recuperación sobre muestras de evidencia archivada para confirmar que sigue siendo íntegra y recuperable, no solo almacenada.","t
1ipo":"tercero","nivelAutonomia":"agente supervisado (nivel 3)","ejemplos":["herramientas de verificación de integridad de archivo WORM"],"valor":"convierte la retención de una promesa de política a una capacidad verificada"}],"metadata":{"evidenciaEsperada":"Política de retención documentada + prueba de recuperación íntegra de la evidencia de aceptación de un alta pasada (versión, fecha, identidad).","dolorAsociado":"Evidencia de aceptación no localizable cuando se necesita; incapacidad de reconstruir el consentimiento por vendedor en una auditoría o litigio.","frenteRecomendacion":"Tecnología e Integración","fuente":"MASTER-C01 §1 (listo para la regla: logging de sustentación, retención 3 años), §2 (registro inmutable de aceptación), §4.2.9 (archivo recuperable de comunicaciones)"},"camposFaltantes":[]},{"practiceId":"C01-02-PR-05","processId":"C01","temaId":"c01-inscripcion-y-alta-contractual","nombre":"Colocación en genealogía al momento del alta con registro auditable","pregunta":"¿El nuevo vendedor queda colocado en la genealogía al momento del alta con un registro auditable (atribuible, visible y reversible), sin ediciones silenciosas de posición o sponsor?","enunciado":"Al momento del alta, el nuevo vendedor queda colocado en el árbol de genealogía en la posición que determina el sponsor, las comisiones y las reglas de compresión, roll-up o spillover, y esa colocación queda con un registro auditable —atribuible, visible y reversible—, de modo que la integridad del árbol y las comisiones de terceros se sustentan en evidencia y cualquier cambio de posición o de sponsor sigue un procedimiento controlado, en lugar de resolverse de memoria o mediante una edición silenciosa.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin colocación formal al alta; la posición y el sponsor se asignan después, de memoria."},{"nivel":1,"ancla":"1 Colocación informal; se anota la posición a mano y los cambios no dejan rastro."},{"nivel":2,"ancla":"2 Colocación repetible pero sin registro auditable ni regla clara de posición y spillover."},{"nivel":3,"ancla":"3 Colocación definida al momento del alta con sponsor y posición registrados y regla de placement documentada."},{"nivel":4,"ancla":"4 Colocación gestionada con control de cambios de posición/sponsor (aprobación dual) y audit trail de cada cambio."},{"nivel":5,"ancla":"5 Colocación optimizada; la integridad de la genealogía se audita de forma continua y los cambios son atribuibles, visibles y reversibles."}]},"sistemas":{"referenciaMp":"§4 (2.2 placement), §3 (SoD: cambios de sponsor con aprobación dual, audit log inmutable), §5 (DMS/genealogía)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; la posición en el árbol se lleva en planilla o se define fuera de sistema."},{"nivel":1,"ancla":"1 Registro de sponsor y posición en un campo editable sin control ni historial."},{"nivel":2,"ancla":"2 Software de genealogía que registra la posición, sin control de cambios ni maker-checker."},{"nivel":3,"ancla":"3 Sistema que fija la colocación al alta y registra sponsor, posición y regla de placement con historial."},{"nivel":4,"ancla":"4 Plataforma con control de cambios de genealogía (aprobación dual, simulación de impacto) y audit log inmutable."},{"nivel":5,"ancla":"5 Ecosistema donde la colocación fluye del alta al motor de comisiones sin intervención manual y todo cambio queda trazado."}]},"agentico":{"referenciaMp":"§6 (detección de fraude estructural/genealogía)","anclas":[{"nivel":0,"ancla":"0 Sin IA; la verificación de la colocación es completamente manual."},{"nivel":1,"ancla":"1 Alertas simples cuando un alta queda sin posición o sin sponsor."},{"nivel":2,"ancla":"2 Copiloto que sugiere la posición según la regla de placement para confirmación."},{"nivel":3,"ancla":"3 Agente supervisado que detecta anomalías de colocación (cross-lining, spillover indebido) y las reporta."},{"nivel":4,"ancla":"4 Agentes que reconcilian la genealogía y proponen resolución de conflictos de posición de forma coordinada."},{"nivel":5,"ancla":"5 Colocación autónoma dentro de políticas, con audit trail y escalamiento de excepciones por revisión humana."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Motor de genealogía y colocación al alta","tipo":"S4DS","categoria":"Genealogía del CRM transaccional","coberturaS4DS":"módulo Genealogía · colocación automática con regla de placement/spillover · audit log inmutable de cambios de posición y sponsor · MCP genealogy tools","nota":"Fija sponsor y posición en el mismo acto del alta y alimenta directamente el motor de comisiones sin transferencia manual."},{"nombre":"Plataforma DMS/MLM (motor de genealogía nativo)","tipo":"tercero","categoria":"Distributor Management System","ejemplos":["Exigo","DirectScale","Epixel","InfoTrax FlexCloud"],"nota":"Soporta los arquetipos de plan (unilevel, binario, matriz, board) con reglas de placement y spillover configurables."},{"nombre":"Control de cambios con aprobación dual (maker-checker)","tipo":"tercero","categoria":"Segregación de funciones (SoD) sobre datos sensibles","ejemplos":["flujos de aprobación de plataformas de workflow/BPM"],"nota":"Implementa la aprobación en dos factores y la simulación de impacto antes de confirmar un cambio de posición o sponsor."}],"agentesYUseCase":[{"useCase":"Copiloto de colocación: sugiere la posición y el sponsor correctos según la regla de placement/spillover vigente, para confirmación humana antes de fijar la genealogía del alta.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — sugiere; el humano confirma antes de fijar la posición","valor":"reduce el error de colocación manual sin quitarle al equipo el control final"},{"useCase":"Agente supervisado de anomalías de colocación: detecta patrones de cross-lining, spillover indebido o posiciones fantasma en altas recientes y las reporta a compliance con el detalle del desvío.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — detecta y reporta; el humano investiga y corrige","valor":"expone fraude estructural de genealogía antes de que distorsione varios periodos de comisión"},{"useCase":"Agentes de reconciliación de genealogía: comparan el árbol vigente contra el histórico de cambios y proponen resolución cuando dos fuentes (front-end de alta y motor de comisiones) divergen sobre la posición de un vendedor.","tipo":"tercero","nivelAutonomia":"multi-agente (nivel 4) — coordina detección y propuesta; aprobación humana final","ejemplos":["módulos de detección de fraude/compliance de Epixel"],"valor":"cierra la brecha entre lo que el árbol dice y lo que el motor de comisiones efectivamente calculó"}],"metadata":{"evidenciaEsperada":"Registro de colocación en genealogía de un alta reciente (sponsor, posición, fecha) + evidencia del audit trail de un cambio de posición o de sponsor.","dolorAsociado":"Colocación tardía o editada silenciosamente que corrompe la genealogía y las comisiones de terceros; disputas de posición o sponsor resueltas sin evidencia.","frenteRecomendacion":"Tecnología e Integración","fuente":"MASTER-C01 §2 (Colocación en genealogía al alta: compresión/roll-up/spillover), §4.2.2 (placement), §3 (SoD: cambios de sponsor con aprobación dual, audit log inmutable), §5 (DMS como sistema de registro)"},"camposFaltantes":[]},{"practiceId":"C01-02-PR-06","processId":"C01","temaId":"c01-inscripcion-y-alta-contractual","nombre":"Provisión automática del back-office al completar el alta","pregunta":"¿Al completar el alta, el nuevo vendedor recibe automáticamente su back-office/cuenta y su presencia de venta, sin espera ni intervención manual?","enunciado":"Al completar el alta, el nuevo vendedor recibe de forma automática los recursos que le permiten empezar a operar —su cuenta y back-office, su presencia de venta personal y el acceso a los materiales oficiales— sin intervención manual ni espera, de modo que la aceptación desemboca en una identidad operativa en un solo paso continuo en lugar de quedar como una tarea administrativa desconectada que posterga el inicio de la actividad.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin provisión definida; la cuenta y el acceso se crean a mano días después, si acaso."},{"nivel":1,"ancla":"1 Provisión ad-hoc; alguien crea manualmente los accesos según recuerde."},{"nivel":2,"ancla":"2 Provisión repetible con pasos manuales; el back-office se habilita con demora variable."},{"nivel":3,"ancla":"3 Provisión definida y estandarizada que habilita back-office, tienda y materiales al completar el alta."},{"nivel":4,"ancla":"4 Provisión gestionada con SLA de disponibilidad del back-office y medición del tiempo alta→operativo."},{"nivel":5,"ancla":"5 Provisión optimizada; el aprovisionamiento es inmediato, medido y mejorado continuamente sin intervención manual."}]},"sistemas":{"referenciaMp":"§5 (storefronts replicados, DMS), §4 (hand-off 2.2→2.5/2.6)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; los accesos se crean manualmente en cada sistema por separado."},{"nivel":1,"ancla":"1 Creación manual de la cuenta en una herramienta aislada tras el alta."},{"nivel":2,"ancla":"2 Alta y back-office en sistemas separados; el aprovisionamiento requiere transferencia manual de datos."},{"nivel":3,"ancla":"3 Sistema que aprovisiona back-office y sitio replicado a partir del registro del alta."},{"nivel":4,"ancla":"4 Plataforma que provisiona en tiempo real cuenta, tienda y materiales al confirmarse el alta."},{"nivel":5,"ancla":"5 Ecosistema donde el alta dispara el aprovisionamiento end-to-e
1nd (cuenta→tienda→materiales→onboarding) sin transferencias manuales."}]},"agentico":{"referenciaMp":"§6 (onboarding orquestado)","anclas":[{"nivel":0,"ancla":"0 Sin IA; el aprovisionamiento es completamente manual."},{"nivel":1,"ancla":"1 IA que asiste en la creación de la cuenta bajo demanda."},{"nivel":2,"ancla":"2 Copiloto que prepara el paquete de aprovisionamiento para confirmación."},{"nivel":3,"ancla":"3 Agente supervisado que aprovisiona los accesos y verifica que quedaron habilitados, listo para revisión."},{"nivel":4,"ancla":"4 Agentes que coordinan aprovisionamiento, activación de tienda y arranque del onboarding con supervisión global."},{"nivel":5,"ancla":"5 Aprovisionamiento autónomo al completarse el alta, con reintentos y escalamiento por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Provisión automática de back-office al completar el alta","tipo":"S4DS","categoria":"Onboarding y aprovisionamiento del CRM transaccional","coberturaS4DS":"módulo Onboarding · aprovisionamiento en tiempo real de cuenta/back-office/tienda replicada al confirmarse el alta · MCP provisioning tools","nota":"Dispara el aprovisionamiento end-to-end desde el evento de alta, sin transferencia manual entre sistemas."},{"nombre":"Plataforma DMS/MLM (storefronts replicados nativos)","tipo":"tercero","categoria":"Distributor Management System / sitios replicados","ejemplos":["Exigo","DirectScale","ByDesign (Freedom)","Epixel"],"nota":"Genera automáticamente el sitio replicado y el back-office del vendedor a partir del registro del alta."},{"nombre":"Gestión de identidad y accesos (IAM)","tipo":"tercero","categoria":"Provisión de cuentas y accesos","ejemplos":["Okta","Auth0"],"nota":"Automatiza la creación de credenciales y accesos del vendedor al completar el alta, sin intervención manual de IT."}],"agentesYUseCase":[{"useCase":"Agente supervisado de aprovisionamiento: al confirmarse el alta, ejecuta la creación de cuenta, tienda replicada y accesos a materiales, y verifica que las tres piezas quedaron efectivamente habilitadas antes de marcar el alta como operativa.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — ejecuta y verifica; escala si algo falla","valor":"cierra la brecha entre alta administrativa e identidad operativa sin espera manual"},{"useCase":"Agentes coordinados de arranque: orquestan en paralelo el aprovisionamiento del back-office, la activación de la tienda replicada y el disparo del primer contacto del journey de onboarding, con supervisión global del hand-off.","tipo":"S4DS","nivelAutonomia":"multi-agente (nivel 4) — coordinación autónoma con supervisión global; excepción a revisión humana","valor":"sostiene el mismo tiempo de activación aun cuando cientos de altas se completan simultáneamente tras un evento"},{"useCase":"Agente de activación de tienda replicada: configura y publica el storefront personal del vendedor con su enlace de referido y catálogo vigente inmediatamente tras el alta.","tipo":"tercero","nivelAutonomia":"agente supervisado (nivel 3)","ejemplos":["orquestación de onboarding de Epixel/Rallyware"],"valor":"el vendedor puede compartir su tienda y generar su primera orden el mismo día del alta"}],"metadata":{"evidenciaEsperada":"Evidencia de que un alta reciente quedó con back-office, tienda/sitio replicado y materiales habilitados automáticamente + tiempo alta→operativo.","dolorAsociado":"Vendedor que completa el alta pero no puede operar por demoras de aprovisionamiento manual; fricción entre la aceptación y el inicio real de la actividad.","frenteRecomendacion":"Eficiencia/Simplificación de Proceso","fuente":"MASTER-C01 §5 (storefronts replicados, DMS), §4 (hand-off inscripción→activación/onboarding), §2.6 (onboarding 0-90d)"},"camposFaltantes":[]},{"practiceId":"C01-03-PR-01","processId":"C01","temaId":"c01-verificacion-identidad-y-elegibilidad","nombre":"Verificación de identidad en capas con códigos de razón","pregunta":"¿Verificamos la identidad del candidato en capas (datos + documento + persona real y presente) y registramos el resultado con códigos de razón, en lugar de una revisión visual del documento?","enunciado":"La organización verifica la identidad de cada candidato en capas complementarias antes de habilitarlo: validando los datos declarados contra fuentes oficiales, contrastando el documento de identidad presentado y confirmando que quien se enrola es una persona real y presente. Cada verificación deja un resultado con códigos de razón que explican la aprobación, el rechazo o la derivación a revisión, de modo que la decisión es reconstruible y defendible en lugar de depender de una inspección visual del documento. La verificación en capas cierra la puerta a identidades falsas o sintéticas justo en el punto de mayor riesgo, que es el alta.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin verificación de identidad; se acepta lo declarado por el candidato sin contrastar contra ninguna fuente."},{"nivel":1,"ancla":"1 Verificación ad-hoc; alguien revisa el documento a ojo según el caso, sin criterio uniforme."},{"nivel":2,"ancla":"2 Verificación repetible de una sola capa (datos o documento), aplicada de forma parcial y sin registrar el motivo del resultado."}
1,{"nivel":3,"ancla":"3 Verificación en capas definida (datos declarados + documento + persona real y presente) con códigos de razón registrados por resultado."},{"nivel":4,"ancla":"4 Verificación gestionada con KPIs (aprobación en primer intento, tiempo de verificación, fraude detectado) y umbrales por nivel de riesgo."},{"nivel":5,"ancla":"5 Ningún umbral de verificación permanece vigente sin una revisión documentada contra el fraude detectado y los falsos positivos del periodo anterior."}]},"sistemas":{"referenciaMp":"§5 (verificación de identidad integrada por API), §4 (2.3 KYC/verificación: OCR + verificación documental)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; la identidad se revisa manualmente sobre copias o fotos enviadas por chat."},{"nivel":1,"ancla":"1 Captura del documento en un formulario aislado; la revisión sigue siendo visual y manual."},{"nivel":2,"ancla":"2 Herramienta especializada de verificación documental (OCR), sin biometría ni conexión con el flujo de alta."},{"nivel":3,"ancla":"3 Servicio de verificación de identidad (IDV) integrado por API al alta que combina validación de datos, OCR documental y biometría/liveness, con códigos de razón."},{"nivel":4,"ancla":"4 Plataforma que orquesta las capas en tiempo real, ajusta el rigor por país/monto del kit y expone el resultado al flujo de alta."},{"nivel":5,"ancla":"5 Ecosistema donde la verificación en capas fluye del alta al sistema de registro y al payout sin transferencias manuales, con anti-deepfake activo."}]},"agentico":{"referenciaMp":"§6 (KYC con IA: OCR + biometría facial + liveness)","anclas":[{"nivel":0,"ancla":"0 Sin IA; toda la comprobación documental y de la persona es manual."},{"nivel":1,"ancla":"1 Asistencia puntual de IA para leer o extraer los datos de un documento bajo demanda."},{"nivel":2,"ancla":"2 Copiloto que extrae los datos del documento, detecta inconsistencias y propone el resultado para revisión."},{"nivel":3,"ancla":"3 Agente supervisado que ejecuta las capas (datos, documento, liveness), asigna códigos de razón y deja el caso listo para decisión humana."},{"nivel":4,"ancla":"4 Agentes que coordinan verificación documental, biometría y detección de identidad sintética/deepfake con supervisión global."},{"nivel":5,"ancla":"5 Verificación autónoma en capas dentro de políticas definidas, con re-verificación y escalamiento de casos ambiguos solo por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Verificación de identidad integrada al alta (IDV por capas)","tipo":"S4DS","categoria":"Verificación de identidad del CRM transaccional","coberturaS4DS":"módulo Enrolamiento · orquestación de capas (datos + documento + liveness) vía API en el flujo de alta · MCP kyc/identity tools","nota":"Orquesta las tres capas en el momento del alta y expone el resultado con código de razón directamente al flujo de decisión, evitando la revisión visual aislada."},{"nombre":"Servicio de verificación de identidad (IDV) especializado","tipo":"tercero","categoria":"KYC/IDV — validación de datos + OCR documental + biometría/liveness","ejemplos":["Trulioo","Onfido","Entrust","Jumio","Persona"],"nota":"Ningún DMS de venta directa construye IDV nativo de nivel bancario; el patrón correcto es integrar por API en el paso de firma/alta. Jumio y Persona destacan por detección de deepfakes y *passive liveness*; Trulioo cubre KYC+KYB en 195 países (útil si el candidato se enrola como entidad/LLC)."},{"nombre":"DMS / plataforma núcleo de venta directa","tipo":"tercero","categoria":"Distributor Management System (sistema de registro del alta)","ejemplos":["Exigo","DirectScale","ByDesign (Freedom)","Epixel"],"nota":"Punto de integración donde el resultado de la capa IDV debe aterrizar como parte del expediente del candidato antes de habilitarlo, no en un sistema paralelo desconectado."},{"nombre":"OCR documental especializado","tipo":"tercero","categoria":"Extracción y validación de documento de identidad","ejemplos":["ID R&D","Regula","IDnow"],"nota":"Cuando se requiere una capa de OCR/validación de documento independiente del proveedor de liveness."}],"agentesYUseCase":[{"useCase":"Copiloto de extracción documental: lee el documento de identidad presentado, extrae los campos clave (nombre, número, fecha de vencimiento, país emisor) y detecta inconsistencias evidentes (formato inválido, documento vencido, foto alterada
1) antes de pasar a biometría.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — extrae y sugiere; el humano confirma","valor":"reduce el tiempo de captura manual y detecta errores obvios antes de gastar la capa de liveness"},{"useCase":"Agente supervisado de verificación en capas: ejecuta secuencialmente la validación de datos contra fuentes oficiales, la verificación documental y el chequeo de persona real/liveness, y compone el resultado final con su código de razón, dejando el caso listo para decisión humana en los bordes de riesgo.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — ejecuta las capas y reporta; el humano decide en casos límite","valor":"convierte tres verificaciones dispersas en una decisión única, trazable y con motivo explícito"},{"useCase":"Detección de identidad sintética / anti-deepfake: analiza la señal de liveness en busca de indicios de rostro generado o manipulado por IA, coordinando con la verificación documental cuando ambas señales son inconsistentes entre sí.","tipo":"tercero","nivelAutonomia":"agente supervisado (nivel 3) — señala y explica; compliance resuelve el caso ambiguo","ejemplos":["Jumio anti-deepfake","Reality Defender","Persona liveness"],"valor":"cierra el vector de fraude que un OCR documental aislado ya no puede detectar por sí solo"}],"metadata":{"evidenciaEsperada":"Configuración de las capas de verificación (datos, documento, persona real) + muestra de altas recientes con su resultado y código de razón.","dolorAsociado":"Identidades falsas o sintéticas que superan una verificación de una sola capa para cobrar bonos de reclutamiento o abrir posiciones fantasma; el momento de mayor riesgo es el alta.","frenteRecomendacion":"Tecnología e Integración","fuente":"MASTER-C01 §2 (KYC y elegibilidad: verificación OCR contra bases oficiales), §4.2.3 (KYC/verificación: OCR + verificación documental), §5 (verificación de identidad integrada por API: liveness/anti-deepfake), §6 (KYC con IA: OCR + biometría + liveness)"},"camposFaltantes":[]},{"practiceId":"C01-03-PR-02","processId":"C01","temaId":"c01-verificacion-identidad-y-elegibilidad","nombre":"Cribado de elegibilidad y control de duplicados/multi-cuenta","pregunta":"¿Cribamos la elegibilidad (edad mínima, geografía permitida, exclusión de empleados y menores) y detectamos duplicados/multi-cuenta antes de habilitar al candidato?","enunciado":"La organización criba la elegibilidad de cada candidato antes de habilitarlo, verificando que cumple la edad mínima, que reside en una geografía o país permitido, que no es un empleado ni un menor excluido, y que no existe ya como registro duplicado o multi-cuenta. Así solo se enrolan personas efectivamente elegibles y se evita que cuentas repetidas o partes no admitidas entren al árbol de vendedores y contaminen la genealogía y las comisiones, en lugar de descubrir la inelegibilidad después de haber pagado.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin cribado de elegibilidad; se enrola a cualquiera que complete el alta."},{"nivel":1,"ancla":"1 Cribado informal; algunos criterios (edad, país) se revisan a criterio de quien atiende."},{"nivel":2,"ancla":"2 Criterios de elegibilidad conocidos pero aplicados de forma desigual y sin verificar duplicados."},{"nivel":3,"ancla":"3 Cribado definido y documentado (edad mínima, geografía permitida, exclusión de empleados y menores, detección de duplicados/multi-cuenta) aplicado a cada alta."},{"nivel":4,"ancla":"4 Cribado gestionado con medición de rechazos por causal y reglas claras para casos límite (mismo domicilio, dispositivo o cuenta bancaria compartida)."},{"nivel":5,"ancla":"5 Ninguna regla de elegibilidad o de duplicidad permanece vigente sin una revisión documentada contra los patrones de fraude y abuso detectados en el periodo anterior."}]},"sistemas":{"referenciaMp":"§8 (fraude interno: cuentas fantasma / multi-cuenta), §4 (2.3 verificación de elegibilidad)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; la elegibilidad no se comprueba o se revisa sobre planillas a mano."},{"nivel":1,"ancla":"1 Lista de criterios en un documento; verificación manual campo por campo."},{"nivel":2,"ancla":"2 Reglas básicas en el formulario de alta (validación de edad/país), sin cruce contra otros registros."},{"nivel":3,"ancla":"3 Motor de reglas de elegibilidad integrado al alta con deduplicación contra el padrón de vendedores y de empleados."},{"nivel":4,"ancla":"4 Plataforma que cruza en tiempo real señales de duplicidad (documento, domicilio, dispositivo, cuenta bancaria) y bloquea altas no elegibles."},{"nivel":5,"ancla":"5 Ecosistema donde las reglas de elegibilidad y la deduplicación operan de extremo a extremo sobre datos maestros unificados sin intervención manual."}]},"agentico":{"anclas":[{"nivel":0,"ancla":"0 Sin IA; la detección de duplicados y no elegibles es completamente manual."},{"nivel":1,"ancla":"1 Alertas simples por reglas fijas (edad fuera de rango, país no permitido)."},{"nivel":2,"ancla":"2 Copiloto que marca posibles duplicados o cuentas relacionadas para revisión."},{"nivel":3,"ancla":"3 Agente supervisado que detecta clústeres de multi-cuenta y vínculos con empleados/menores y los reporta."},{"nivel":4,"ancla":"4 Agentes que correlacionan señales (identidad, dispositivo, geografía, pago) para detectar redes de cuentas fantasma de forma coordinada."},{"nivel":5,"ancla":"5 Cribado autónomo de elegibilidad y duplicidad dentro de políticas, con escalamiento de casos dudosos por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Motor de reglas de elegibilidad y deduplicación","tipo":"S4DS","categoria":"Elegibilidad y deduplicación del CRM transaccional","coberturaS4DS":"módulo Enrolamiento · reglas de edad/geografía/exclusión integradas al alta · deduplicación contra el padrón de vendedores y empleados · MCP eligibility tools","nota":"Aplica los criterios de elegibilidad y cruza contra el padrón completo en el momento del alta, antes de habilitar al candidato, en lugar de descubrir la inelegibilidad después de pagar."},{"nombre":"DMS / plataforma núcleo de venta directa","tipo":"tercero","categoria":"Distributor Management System (padrón de vendedores)","ejemplos":["Exigo","DirectScale","ByDesign (Freedom)","Epixel"],"nota":"Fuente del padrón de vendedores activos contra el que debe correr la deduplicación de cada alta nueva."},{"nombre":"Herramienta de detección de identidad/dispositivo duplicado","tipo":"tercero","categoria":"Fraude / fingerprinting de dispositivo","ejemplos":["Sift","Seon","Sardine"],"nota":"Correlaciona señales de dispositivo, domicilio o cuenta bancaria compartida entre altas distintas para detectar multi-cuenta más allá del nombre."},{"nombre":"HRIS / sistema de nómina corporativo","tipo":"tercero","categoria":"Fuente de exclusión de empleados","ejemplos":["Workday","SAP SuccessFactors","ADP"],"nota":"Fuente de verdad para cruzar el padrón de empleados vigentes contra cada alta y excluirlos automáticamente."}],"agentesYUseCase":[{"useCase":"Copiloto de elegibilidad: revisa cada alta contra los criterios vigentes (edad, geografía, exclusión de empleados/menores) y marca posibles duplicados o cuentas relacionadas para revisión antes de habilitar al candidato.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — marca y explica; el humano confirma","valor":"adelanta a la vista del analista los casos dudosos que antes solo se descubrían después del alta"},{"useCase":"Agente supervisado de detección de multi-cuenta: correlaciona documento, domicilio, dispositivo y datos de pago entre altas para identificar clústeres de cuentas relacionadas o vínculos con empleados/menores excluidos, y reporta el hallazgo con evidencia.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — detecta y reporta; compliance decide el bloqueo","valor":"expone redes de cuentas fantasma o cross-lining que un cribado campo por campo no puede ver"},{"useCase":"Agentes coordinados de correlación de señales de fraude estructural (identidad, dispositivo, geografía, medio de pago) que priorizan por riesgo los clústeres de cuentas más sospechosos para revisión de compliance.","tipo":"tercero","nivelAutonomia":"agente supervisado → multi-agente (nivel 3-4)","ejemplos":["Sift","Seon"],"valor":"escala la detección de duplicidad más allá de lo que un analista puede correlacionar manualmente"}],"metadata":{"evidenciaEsperada":"Reglas de elegibilidad vigentes (edad, geografía, exclusiones) + registro de altas rechazadas por causal y de duplicados detectados.","dolorAsociado":"Empleados, menores o personas de geografías no permitidas que se enrolan; cuentas duplicadas/fantasma que corrompen la genealogía y las comisiones.","frenteRecomendacion":"Gobierno/Roles/Tercerización","fuente":"MASTER-C01 §2 (KYC y elegibilidad: edad, geografía, exclusión de empleados/menores; distinguir KYC de verificación continua de elegibilidad), §8 (fraude interno sobre la estructura: cuentas fantasma, cross-lining, dual enrollment)"},"camposFaltantes":[]},{"practiceId":"C01-03-PR-03","processId":"C01","temaId":"c01-verificacion-identidad-y-elegibilidad","nombre":"Cribado de sanciones/PEP en tiempo real y re-cribado continuo","pregunta":"¿Contrastamos a cada candidato y a quienes reciben pagos contra listas de sanciones y PEP en tiempo real, y los re-cribamos de forma continua al cambiar las listas?","enunciado":"La organización contrasta a cada candidato y a cada parte que recibe pagos contra listas de sanciones, personas expuestas políticamente y otras listas de vigilancia, tanto en el momento del alta como de forma recurrente ante cambios en esas listas. De este modo evita habilitar o liquidar a partes sancionadas o de alto riesgo —una responsabilidad de cumplimiento que no admite excepción— en lugar de tratar el contraste como un chequeo único y aislado del ciclo de pagos.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin cribado de sanciones/PEP; nadie contrasta a candidatos ni a beneficiarios de pago contra listas de vigilancia."},{"nivel":1,"ancla":"1 Cribado esporádico y manual contra alguna lista, sin cobertura garantizada ni registro."},{"nivel":2,"ancla":"2 Cribado repetible en el alta contra listas de sanciones, sin re-cribado posterior ni cobertura de PEP."},{"nivel":3,"ancla":"3 Cribado definido de sanciones/PEP/listas de vigilancia en el alta, con criterio de coincidencia 
1y gestión de falsos positivos documentada."},{"nivel":4,"ancla":"4 Cribado gestionado en tiempo real en el alta y en la habilitación de pagos, con re-cribado recurrente y trazabilidad de cada resolución."},{"nivel":5,"ancla":"5 Cribado optimizado; el re-cribado continuo se dispara por cambios de lista y por eventos, con métricas de cobertura y de precisión."}]},"sistemas":{"referenciaMp":"§5 (screening de sanciones/PEP — la capa menos madura), §10 (OFAC/PEP en el motor de payout)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; no existe forma sistemática de contrastar contra listas."},{"nivel":1,"ancla":"1 Búsquedas manuales puntuales en portales públicos de listas."},{"nivel":2,"ancla":"2 Herramienta de screening por lotes contra listas de sanciones, desconectada del alta y del pago."},{"nivel":3,"ancla":"3 Servicio de screening integrado al alta que contrasta contra sanciones (OFAC/SDN), PEP y listas de vigilancia con gestión de coincidencias."},{"nivel":4,"ancla":"4 Plataforma que criba en tiempo real en el alta y en el motor de payout, con re-screening automático al actualizarse las listas."},{"nivel":5,"ancla":"5 Ecosistema donde el screening y el re-screening operan de extremo a extremo (alta→wallet→payout) sin intervención manual, con audit trail inmutable."}]},"agentico":{"anclas":[{"nivel":0,"ancla":"0 Sin IA; la resolución de coincidencias es completamente manual."},{"nivel":1,"ancla":"1 Alertas simples cuando un nombre coincide textualmente con una lista."},{"nivel":2,"ancla":"2 Copiloto que puntúa la similitud de la coincidencia y descarta falsos positivos evidentes para revisión."},{"nivel":3,"ancla":"3 Agente supervisado que resuelve coincidencias con contexto (fuzzy matching, homónimos) y escala las verdaderas a compliance."},{"nivel":4,"ancla":"4 Agentes que monitorean cambios de lista y re-criban la base de forma coordinada, priorizando por riesgo."},{"nivel":5,"ancla":"5 Cribado autónomo con re-screening continuo dentro de políticas, con escalamiento de coincidencias verdaderas por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Screening de sanciones/PEP integrado al alta y al payout","tipo":"S4DS","categoria":"Compliance screening del CRM transaccional","coberturaS4DS":"módulo Enrolamiento/Payout · contraste contra listas de sanciones (OFAC/SDN)/PEP en el alta y en la habilitación de pago · re-screening automático por actualización de lista · MCP compliance/screening tools","nota":"Cierra la capa menos madura del sector integrando el cribado tanto al alta como al motor de payout, con re-cribado disparado por cambios de lista."},{"nombre":"Servicio de screening de sanciones/PEP especializado","tipo":"tercero","categoria":"AML / watchlist screening","ejemplos":["LexisNexis Risk Solutions","Refinitiv World-Check","ComplyAdvantage","Dow Jones Risk & Compliance"],"nota":"Fuente actualizada de listas OFAC/SDN, PEP y de vigilancia, con motor de fuzzy matching para resolver homónimos."},{"nombre":"Herramienta pública de screening OFAC","tipo":"tercero","categoria":"Consulta directa de lista SDN","ejemplos":["OFAC Sanctions List Search (Treasury)"],"nota":"Referencia primaria para validar coincidencias reportadas por el servicio de screening principal."},{"nombre":"Motor de comisiones / payout","tipo":"S4DS","categoria":"Motor de payout del CRM transaccional","coberturaS4DS":"módulo Comisiones · consulta el estado de screening antes de liberar cada liquidación · MCP payout tools","nota":"Punto donde el resultado del screening debe bloquear o permitir el desembolso, no solo informarlo."}],"agentesYUseCase":[{"useCase":"Copiloto de resolución de coincidencias: puntúa la similitud de cada coincidencia contra listas de sanciones/PEP (nombre, fecha de nacimiento, país) y descarta automáticamente los falsos positivos evidentes, dejando solo los casos ambiguos para revisión.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — puntúa y filtra; el humano confirma el descarte","valor":"reduce la carga de revisión manual sobre miles de coincidencias textuales sin bajar la cobertura de riesgo real"},{"useCase":"Agente supervisado de resolución con contexto: aplica fuzzy matching y contexto (homónimos, geografía, fecha de nacimiento) para distinguir coincidencias verdaderas de falsos positivos, y escala solo las verdaderas a compliance con la evidencia armada.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — resuelve y escala;
1 compliance decide el caso real","valor":"acelera la resolución sin perder el rigor que exige la responsabilidad estricta de OFAC"},{"useCase":"Agentes de monitoreo de cambios de lista: detectan actualizaciones en las listas de sanciones/PEP y re-criban de forma coordinada la base completa de vendedores y beneficiarios de pago, priorizando por exposición (monto liquidado, geografía).","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3-4)","valor":"convierte el re-screening de un evento manual y esporádico en un proceso continuo disparado por evento"}],"metadata":{"evidenciaEsperada":"Evidencia de cribado de sanciones/PEP de una muestra de altas y de beneficiarios de pago + registro de re-cribado y de resolución de coincidencias.","dolorAsociado":"Pago o liquidación a partes sancionadas o de alto riesgo (responsabilidad estricta OFAC); especialmente top earners con estructuras offshore no verificadas.","frenteRecomendacion":"Gobierno/Roles/Tercerización","fuente":"MASTER-C01 §5 (screening de sanciones/PEP — la capa menos madura; OFAC de responsabilidad estricta para todo US person), §10 (screening OFAC/PEP en el motor de payout, no solo signup; re-screening continuo por disparadores), §8 (esquemas piramidales usados para lavado de dinero)"},"camposFaltantes":[]},{"practiceId":"C01-03-PR-04","processId":"C01","temaId":"c01-verificacion-identidad-y-elegibilidad","nombre":"Re-KYC continuo por disparadores y periódico","pregunta":"¿Revisamos la vigencia de la verificación de forma continua —por disparadores de riesgo y periódicamente (~12 meses)— en lugar de tratarla como un evento único de alta?","enunciado":"La organización trata la verificación de identidad y elegibilidad como una condición que se mantiene viva y no como un evento único del alta: re-verifica de forma periódica y, sobre todo, ante disparadores de riesgo (cambios de datos, de geografía, de comportamiento o de volumen), de modo que el perfil de riesgo de cada vendedor refleja su situación actual y no la del día en que se enroló. Así la verificación no queda obsoleta frente a suplantaciones o cambios de circunstancia, en lugar de confiar indefinidamente en un chequeo hecho una sola vez.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin re-verificación; la identidad se comprueba una vez al alta y nunca más."},{"nivel":1,"ancla":"1 Re-verificación anecdótica, solo cuando surge un problema evidente."},{"nivel":2,"ancla":"2 Re-verificación periódica básica, sin criterio de disparadores ni cobertura garantizada."},{"nivel":3,"ancla":"3 Re-verificación definida: periódica (~12 meses) y por disparadores de riesgo (cambios de datos, país, volumen, alertas), con registro del resultado."},{"nivel":4,"ancla":"4 Re-verificación gestionada con perfiles de r
1iesgo refrescados por evento, cobertura medida y bloqueo de operación al vencer la vigencia."},{"nivel":5,"ancla":"5 Re-verificación continua (perpetua) optimizada; los perfiles se refrescan por disparadores en tiempo casi real y el ciclo se ajusta con el fraude detectado."}]},"sistemas":{"referenciaMp":"§6 (validación continua anti-deepfake), §10 (KYC continuo/perpetual por disparadores)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; no hay forma de saber qué verificaciones están vencidas."},{"nivel":1,"ancla":"1 Recordatorios manuales o planilla de vencimientos de verificación."},{"nivel":2,"ancla":"2 Sistema que marca la fecha de última verificación, sin disparadores ni re-verificación automática."},{"nivel":3,"ancla":"3 Plataforma que agenda re-verificación periódica y la dispara por eventos definidos, ligada al registro del vendedor."},{"nivel":4,"ancla":"4 Plataforma de validación continua que refresca perfiles de riesgo por disparadores en tiempo real y expone la vigencia al motor de payout."},{"nivel":5,"ancla":"5 Ecosistema de perpetual KYC donde la vigencia se recalcula por eventos de extremo a extremo sin intervención manual, con anti-deepfake continuo."}]},"agentico":{"referenciaMp":"§6 (migrar de KYC puntual a validación continua)","anclas":[{"nivel":0,"ancla":"0 Sin IA; la detección de verificaciones vencidas o en riesgo es manual."},{"nivel":1,"ancla":"1 Alertas por fecha de vencimiento de la verificación."},{"nivel":2,"ancla":"2 Copiloto que prioriza qué vendedores re-verificar según señales de riesgo."},{"nivel":3,"ancla":"3 Agente supervisado que detecta disparadores (cambio de datos/geografía/comportamiento) y lanza la re-verificación para revisión."},{"nivel":4,"ancla":"4 Agentes que monitorean señales de riesgo en continuo y coordinan re-verificación y re-cribado de forma priorizada."},{"nivel":5,"ancla":"5 Re-verificación autónoma dirigida por riesgo dentro de políticas, con escalamiento de casos ambiguos por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Vigencia y re-verificación continua (perpetual KYC)","tipo":"S4DS","categoria":"Gestión de vigencia de verificación del CRM transaccional","coberturaS4DS":"módulo Enrolamiento · agenda re-verificación periódica y la dispara por evento definido, ligada al registro del vendedor · expone la vigencia al motor de payout · MCP kyc-lifecycle tools","nota":"Refresca el perfil de riesgo por disparadores y periodicidad, y hace visible la vigencia vigente a cualquier sistema consumidor sin transferencia manual."},{"nombre":"Servicio de IDV con re-verificación / validación continua","tipo":"tercero","categoria":"KYC continuo / anti-deepfake","ejemplos":["Jumio","Persona","Sardine","Onfido"],"nota":"Provee la capacidad de re-chequeo de liveness y detección de identidad sintética como servicio recurrente, no solo en el alta inicial."},{"nombre":"Plataforma de gestión de riesgo/casos","tipo":"tercero","categoria":"Case management de compliance","ejemplos":["ComplyAdvantage","Actimize","SAS AML"],"nota":"Prioriza y agenda qué vendedores re-verificar primero según señales de riesgo agregadas."},{"nombre":"DMS / plataforma núcleo de venta directa","tipo":"tercero","categoria":"Distributor Management System (registro de vigencia)","ejemplos":["Exigo","DirectScale","ByDesign (Freedom)","Epixel"],"nota":"Sistema de registro donde la fecha de última verificación y su vigencia deben quedar ligadas al perfil del vendedor."}],"agentesYUseCase":[{"useCase":"Copiloto de priorización de re-verificación: analiza señales de riesgo (cambio de datos, geografía, comportamiento, volumen) y prioriza qué vendedores re-verificar primero, en lugar de aplicar el mismo calendario a toda la base.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — prioriza y sugiere; el humano agenda","valor":"concentra el esfuerzo de re-verificación donde el riesgo real está cambiando, no donde el calendario dice"},{"useCase":"Agente supervisado de detección de disparadores: monitorea cambios de datos personales, geografía o comportamiento transaccional, identifica cuándo constituyen un disparador válido de re-verificación y lanza el caso para revisión con el motivo documentado.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — detecta y lanza; el humano revisa el caso","valor":"cierra el hueco entre el evento de riesgo y su detección, en lugar de esperar al ciclo anual"},{"useCase":"Agentes coordinados de monitoreo continuo de riesgo que combinan señales de identidad, comportamiento y geografía para disparar re-verificación y re-cribado de forma priorizada a escala de toda la base de vendedores.","tipo":"tercero","nivelAutonomia":"agente supervisado → multi-agente (nivel 3-4)","ejemplos":["Sardine.ai","plataformas de continuous KYC / perpetual monitoring"],"valor":"sostiene el re-KYC continuo a escala sin que el costo operativo crezca linealmente con la base activa"}],"metadata":{"evidenciaEsperada":"Política de re-verificación (periodicidad y dis
1paradores) + evidencia de re-verificaciones ejecutadas por evento y por vencimiento en el último periodo.","dolorAsociado":"Verificación tratada como evento único de alta; deepfakes e identidades sintéticas que vuelven insuficiente el chequeo puntual; perfiles de riesgo desactualizados.","frenteRecomendacion":"Modelos Agénticos/IA","fuente":"MASTER-C01 §2 (re-KYC periódico ≈12 meses; tendencia a perpetual KYC con perfiles refrescados por disparadores), §6 (KYC con IA: migrar de KYC puntual a validación continua anti-deepfake), §10 (KYC continuo/perpetual con re-screening por disparadores)"},"camposFaltantes":[]},{"practiceId":"C01-03-PR-05","processId":"C01","temaId":"c01-verificacion-identidad-y-elegibilidad","nombre":"Verificación como gate del pago de comisiones","pregunta":"¿La verificación de identidad y elegibilidad es un gate del PAGO de comisiones (con estados y bloqueos auditables), y no solo un gate de la inscripción?","enunciado":"La organización condiciona el pago de comisiones a que la verificación de identidad y elegibilidad del beneficiario esté vigente y aprobada, aplicando estados y bloqueos auditables sobre la liquidación —no solo sobre la inscripción—. De este modo la verificación deja de friccionar la conversión inicial y se convierte en el control efectivo del desembolso: ninguna parte no verificada recibe un pago, y toda retención o liberación queda trazada, en lugar de bloquear el alta pero pagar después sin comprobar.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin gate; se pagan comisiones sin comprobar el estado de verificación del benef
1iciario."},{"nivel":1,"ancla":"1 Gate informal; a veces se retiene un pago dudoso a criterio de quien liquida."},{"nivel":2,"ancla":"2 Gate repetible solo en el alta; una vez inscrito, el pago no vuelve a validar la verificación."},{"nivel":3,"ancla":"3 Gate definido: el pago de comisiones exige verificación vigente y aprobada, con estados (pendiente/aprobado/retenido) sobre la liquidación."},{"nivel":4,"ancla":"4 Gate gestionado con hold automático de comisión a beneficiarios no verificados, medición de montos retenidos y liberación auditable al resolverse."},{"nivel":5,"ancla":"5 Gate optimizado; el estado de verificación gobierna el payout en tiempo real y la retención/liberación se audita de forma continua."}]},"sistemas":{"referenciaMp":"§4 (2.3 KYC como gate de payout / hold de comisión), §8 (KYC como gate previo a cualquier pago), §5 (screening en el motor de payout)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; el estado de verificación no está disponible al momento de liquidar."},{"nivel":1,"ancla":"1 Verificación y liquidación en sistemas separados; el bloqueo, si ocurre, es manual."},{"nivel":2,"ancla":"2 El motor de comisiones registra un flag de verificación, sin bloquear el pago automáticamente."},{"nivel":3,"ancla":"3 Motor de comisiones integrado con la verificación que retiene el payout de beneficiarios no verificados con estados auditables."},{"nivel":4,"ancla":"4 Plataforma donde el estado de verificación y el screening bloquean/liberan la liquidación en tiempo real con audit trail inmutable."},{"nivel":5,"ancla":"5 Ecosistema donde verificación→elegibilidad→payout operan como eventos encadenados sin intervención manual y todo hold queda trazado."}]},"agentico":{"anclas":[{"nivel":0,"ancla":"0 Sin IA; decidir qué pagos retener por verificación es manual."},{"nivel":1,"ancla":"1 Alertas cuando un beneficiario con pago pendiente no está verificado."},{"nivel":2,"ancla":"2 Copiloto que lista los pagos a retener por verificación vencida o faltante para revisión."},{"nivel":3,"ancla":"3 Agente supervisado que aplica holds de comisión por estado de verificación y prepara la liberación para aprobación."},{"nivel":4,"ancla":"4 Agentes que coordinan verificación, elegibilidad y cribado con el motor de payout y gestionan los holds de forma priorizada."},{"nivel":5,"ancla":"5 Gate de payout autónomo dentro de políticas, con retención/liberación automática y escalamiento de excepciones por revisión."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Gate de verificación en el motor de payout","tipo":"S4DS","categoria":"Motor de comisiones / payout del CRM transaccional","coberturaS4DS":"módulo Comisiones · consulta el estado de verificación vigente antes de liberar cada liquidación · estados pendiente/aprobado/retenido con hold y liberación auditables · MCP payout/hold tools","nota":"Convierte la verificación en el control efectivo del desembolso, permitiendo que el alta sea de baja fricción mientras el pago queda protegido con estados explícitos."},{"nombre":"DMS / plataforma núcleo de venta directa","tipo":"tercero","categoria":"Distributor Management System (motor de comisiones integrado)","ejemplos":["Exigo","DirectScale","ByDesign (Freedom)","Epixel"],"nota":"Punto donde debe residir la integración entre el estado de verificación y el cálculo/liberación de la comisión."},{"nombre":"Servicio de IDV / screening integrado al payout","tipo":"tercero","categoria":"KYC/AML aplicado al desembolso","ejemplos":["Trulioo","Persona","LexisNexis Risk Solutions"],"nota":"Fuente del estado de verificación/screening que el motor de payout debe consultar antes de cada liquidación."},{"nombre":"Plataforma de e-wallet / pagos a vendedores","tipo":"tercero","categoria":"Disbursement / payout rails","ejemplos":["Tipalti","Hyperwallet (PayPal)","Nium"],"nota":"Capa de desembolso que debe respetar el hold aplicado por el estado de verificación antes de ejecutar la transferencia."}],"agentesYUseCase":[{"useCase":"Copiloto de pagos a retener: lista, antes de cada corrida de comisión, los beneficiarios cuya verificación está vencida, retenida o incompleta, para que el equipo de payout los revise antes de liberar la liquidación general.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — lista y explica; el humano decide la retención","valor":"evita que un pago a una parte no verificada se cuele en una corrida masiva de comisión"},{"useCase":"Agente supervisado de aplicación de holds: aplica automáticamente el estado de retención a la comisión de beneficiarios sin verificación vigente en el momento del cálculo, y prepara el expediente de liberación para aprobación cuando la verificación se resuelve.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — aplica el hold y prepara la liberación; el humano aprueba","valor":"hace del gate de pago un control sistemático en cada corrida, no una excepción manual ocasional"},{"useCase":"Agentes coordinados de verificación-elegibilidad-payout: sincronizan el estado de las tres capas de control con el motor de liquidación y gestionan los holds de forma priorizada por monto y por riesgo del benef
1iciario.","tipo":"S4DS","nivelAutonomia":"agente supervisado → multi-agente (nivel 3-4)","valor":"sostiene el gate de pago a escala sin que cada corrida de comisión requiera revisión manual exhaustiva"}],"metadata":{"evidenciaEsperada":"Regla que condiciona el payout a la verificación vigente + registro de comisiones retenidas por estado de verificación y su liberación auditable.","dolorAsociado":"Fricción en el alta cuando el KYC es gate de inscripción; y pagos liberados a partes no verificadas cuando la verificación no es gate del payout.","frenteRecomendacion":"Tecnología e Integración","fuente":"MASTER-C01 §4.2.3 (best-in-class: KYC como gate de payout/hold de comisión más que de inscripción, para no friccionar la conversión inicial), §8 (KYC como gate previo a cualquier pago), §10 (screening OFAC/PEP integrado al motor de payout para bloquear liquidación a partes no verificadas)"},"camposFaltantes":[]},{"practiceId":"C01-03-PR-06","processId":"C01","temaId":"c01-verificacion-identidad-y-elegibilidad","nombre":"Gobierno de las decisiones de verificación (maker-checker y remediación)","pregunta":"¿Las decisiones de verificación (aprobación, rechazo, revisión manual, remediación) tienen roles separados, criterios explícitos y trazabilidad, con un segundo control en los casos de alto riesgo?","enunciado":"La organización gobierna las decisiones de verificación —aprobar, rechazar, derivar a revisión manual y remediar— con roles separados, criterios explícitos y trazabilidad completa de cada decisión y su motivo. Las decisiones de alto riesgo requieren un segundo control antes de habilitar a una persona o liberar un pago retenido, de modo que ninguna aprobación sensible dependa de una sola mano ni se resuelva sin dejar rastro, en lugar de que quien atiende el alta decida por su cuenta y sin registro.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin gobierno; quien atiende el alta aprueba o rechaza la verificación sin criterio ni registro."},{"nivel":1,"ancla":"1 Decisiones informales caso a caso; sin separación de roles ni registro de por qué se aprobó o rechazó."},{"nivel":2,"ancla":"2 Criterios de decisión conocidos pero sin segregación de funciones ni trazabilidad completa."},{"nivel":3,"ancla":"3 Gobierno definido: criterios de aprobación/rechazo/derivación documentados, con revisión manual para casos de alto riesgo y registro de la decisión."},{"nivel":4,"ancla":"4 Gobierno gestionado con maker-checker (aprobación dual) en decisiones sensibles, cola de revisión con SLA y remediación documentada."},{"nivel":5,"ancla":"5 Ninguna decisión de verificación queda fuera de la auditoría de calidad: el 100% pasa por revisión, y los criterios de decisión solo cambian cuando esa auditoría documenta la necesidad."}]},"sistemas":{"referenciaMp":"§3 (SoD: maker-checker en aprobación de KYC y liberación de comisión retenida; audit log inmutable), §5","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; las decisiones de verificación no quedan registradas."},{"nivel":1,"ancla":"1 Decisiones anotadas en correo o planilla, sin control de acceso ni historial."},{"nivel":2,"ancla":"2 Registro básico de la decisión, sin flujo de revisión ni separación de roles."},{"nivel":3,"ancla":"3 Sistema con cola de revisión manual, roles diferenciados y registro de cada decisión con su motivo."},{"nivel":4,"ancla":"4 Plataforma con maker-checker (aprobación dual), audit log inmutable de aprobaciones/rechazos y flujo de remediación."},{"nivel":5,"ancla":"5 Ecosistema donde el gobierno de decisiones se integra al ciclo (verificación→payout) con trazabilidad extremo a extremo y sin ediciones silenciosas."}]},"agentico":{"anclas":[{"nivel":0,"ancla":"0 Sin IA; la priorización y documentación de casos de revisión es manual."},{"nivel":1,"ancla":"1 IA que resume el caso de verificación para el revisor bajo demanda."},{"nivel":2,"ancla":"2 Copiloto que arma el expediente de decisión (evidencia, coincidencias, códigos de razón) para el revisor."},{"nivel":3,"ancla":"3 Agente supervisado que prioriza la cola de revisión por riesgo y propone la decisión con su justificación."},{"nivel":4,"ancla":"4 Agentes que coordinan la revisión, la remediación y la reconciliación de decisiones con supervisión humana."},{"nivel":5,"ancla":"5 Gobierno de decisiones asistido de forma autónoma dentro de políticas, con maker-checker preservado y escalamiento por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Maker-checker y audit trail de decisiones de verificación","tipo":"S4DS","categoria":"Gobierno y trazabilidad del CRM transaccional","coberturaS4DS":"módulo Enrolamiento/Compliance · cola de revisión con roles diferenciados · aprobación dual (maker-checker) en decisiones sensibles · audit log inmutable · MCP governance/audit tools","nota":"Aplica segregación de funciones a la aprobación de KYC y a la liberación de comisión retenida, con registro inmutable de cada decisión y su motivo."},{"nombre":"DMS / plataforma núcleo de venta directa","tipo":"tercero","categoria":"Distributor Management System (roles y flujo de aprobación)","ejemplos":["Exigo","DirectScale","ByDesign (Freedom)","Epixel"],"nota":"Sistema donde debe residir el flujo de cola de revisión y el registro de decisión ligado al expediente del candidato/beneficiario."},{"nombre":"Plataforma de GRC / gestión de casos de compliance","tipo":"tercero","categoria":"Governance, Risk & 
1Compliance case management","ejemplos":["ServiceNow GRC","Archer","MetricStream"],"nota":"Para organizaciones con volumen alto de casos de revisión manual que requieren SLA, escalamiento y reporting formal."},{"nombre":"Herramienta de audit log inmutable / trazabilidad","tipo":"tercero","categoria":"Logging inmutable y evidencia","ejemplos":["AWS CloudTrail","Splunk","Datadog Audit Trail"],"nota":"Garantiza que ninguna decisión de verificación o liberación de pago se pueda editar sin dejar rastro."}],"agentesYUseCase":[{"useCase":"Copiloto de expediente de decisión: arma automáticamente el paquete de evidencia (documento verificado, coincidencias de screening, códigos de razón de las capas anteriores) para que el revisor decida con toda la información sin reconstruirla manualmente caso por caso.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — arma el expediente; el humano decide","valor":"reduce el tiempo de revisión y evita que una decisión sensible se tome con información incompleta"},{"useCase":"Agente supervisado de priorización de cola: ordena la cola de revisión manual por nivel de riesgo (monto retenido, tipo de coincidencia, antigüedad del caso) y propone la decisión con su justificación para que el revisor confirme o corrija.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — prioriza y propone; el humano decide con maker-checker","valor":"asegura que los casos de mayor riesgo se resuelvan primero, sin sustituir el segundo control humano"},{"useCase":"Agentes coordinados de remediación y reconciliación: dan seguimiento a las decisiones tomadas (rechazos, derivaciones) hasta su cierre, detectan casos estancados sin resolución y reconcilian el registro de decisiones contra el estado real del expediente del vendedor.","tipo":"S4DS","nivelAutonomia":"agente supervisado → multi-agente (nivel 3-4) — con supervisión humana constante en retail, ecommerce y venta directa","valor":"evita que casos de alto riesgo queden abiertos indefinidamente sin resolución ni escalamiento"}],"metadata":{"evidenciaEsperada":"Matriz de roles y criterios de decisión de verificación + audit trail de una muestra de casos (aprobación, rechazo, revisión manual, remediación) con maker-checker donde aplica.","dolorAsociado":"Aprobaciones o rechazos de verificación sin criterio, sin segundo control ni trazabilidad; decisiones de alto riesgo (aprobación de KYC, liberación de comisión retenida) tomadas por una sola persona.","frenteRecomendacion":"Gobierno/Roles/Tercerización","fuente":"MASTER-C01 §3 (SoD: maker-checker en decisiones de alto riesgo — aprobación de KYC, liberación de comisión retenida; audit log inmutable), §1 (co-propiedad Finance/Compliance del KYC), §5 (verificación como capa integrada al sistema de registro)"},"camposFaltantes":[]},{"practiceId":"C01-04-PR-01","processId":"C01","temaId":"c01-kits-de-inicio-y-activacion","nombre":"Diseño de kit de inicio escalonado, modular y de valor acotado","pregunta":"¿El kit de inicio es escalonado/modular y de valor acotado y razonable, orientado a habilitar la operación y no a forzar una compra inicial excesiva ni a ser vehículo de margen?","enunciado":"La organización diseña el kit de inicio como una oferta escalonada y modular de valor acotado y razonable, orientada a habilitar la operación del nuevo vendedor (muestras de producto, herramientas de venta y materiales de formación) y no a forzar una compra inicial excesiva ni a operar como vehículo de margen encubierto. El ticket de entrada ofrece niveles para que cada persona adquiera solo lo que realmente usará, de modo que empezar no obliga a acumular inventario para calificar, en lugar de un kit único, caro y sobredimensionado que traslada el costo del reclutamiento al recién llegado.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin criterio de kit; el monto de entrada se fija de forma arbitraria o se empuja el kit más caro a todos."},{"nivel":1,"ancla":"1 Kit definido informalmente; su valor y contenido varían a criterio de quien enrola, sin justificación."},{"nivel":2,"ancla":"2 Kit único y estándar aplicado de forma repetible, sin escalonamiento ni control de que el valor sea acotado."},{"nivel":3,"ancla":"3 Kit escalonado/modular definido, con valor acotado y contenido justificado por su aporte a habilitar la operación (no a margen)."},{"nivel":4,"ancla":"4 Diseño de kit gestionado con métricas (mezcla de niveles adquiridos, recompra temprana como señal de sobre-compra) contra umbrales."},{"nivel":5,"ancla":"5 Ningún nivel del kit permanece vigente sin una revisión documentada contra el uso real y la activación posterior de ese tramo en el periodo anterior."}]},"sistemas":{"referenciaMp":"§4 (2.4 kit inicial acotado, no vehículo de margen), §9 (kits escalonados/modulares tipo starter stacks personalizables por categoría)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; el kit se arma y cobra manualmente sin catálogo ni opciones configurables."},{"nivel":1,"ancla":"1 Kit cargado como un único ítem en una hoja de cálculo o formulario aislado, sin niveles."},{"nivel":2,"ancla":"2 Catálogo/checkout especializado que ofrece variantes de kit, sin conexión con activación ni comisiones."},{"nivel":3,"ancla":"3 Configuración de kit escalonado en la plataforma de vendedores (DMS/e-commerce) integrada al alta, con niveles seleccionables."},{"nivel":4,"ancla":"4 Plataforma que ajusta la oferta de kit por país/perfil en tiempo real y expone la elección al flujo de alta y activación."}
1,{"nivel":5,"ancla":"5 Ecosistema donde el catálogo de kits, el alta y el seguimiento de uso fluyen sin transferencias manuales para recalibrar la oferta."}]},"agentico":{"referenciaMp":"§6 (next-best-action por vendedor)","anclas":[{"nivel":0,"ancla":"0 Sin IA; la elección del kit no recibe ninguna recomendación asistida."},{"nivel":1,"ancla":"1 Sugerencia puntual de kit a partir de reglas fijas (categoría de interés declarada)."},{"nivel":2,"ancla":"2 Copiloto que recomienda el nivel de kit adecuado al perfil y advierte sobre-compra para revisión."},{"nivel":3,"ancla":"3 Agente supervisado que propone la composición del kit por perfil y proyecta el riesgo de sobre-compra del candidato."},{"nivel":4,"ancla":"4 Agentes que coordinan la recomendación de kit con las señales de activación esperada y ajustan la oferta de forma priorizada."},{"nivel":5,"ancla":"5 Recomendación autónoma de kit dentro de políticas, calibrada con los resultados de activación por tramo, con intervención humana solo por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Catálogo y Kits de Inicio","tipo":"S4DS","categoria":"Catálogo/checkout de kits para vendedores","coberturaS4DS":"módulo Catálogo · configurador de kit por niveles/tramos ligado al alta · MCP catalog/kit-builder tools","nota":"Modela el kit como oferta escalonada y modular dentro del flujo de alta, con contenido y precio por tramo versionados y visibles al candidato antes de comprar."},{"nombre":"Exigo","tipo":"tercero","categoria":"DMS / storefront replicado con checkout de kit","ejemplos":["Exigo"],"nota":"PaaS con storefronts replicados y motor de comisiones configurable donde se puede parametrizar el kit por tramo sin código, con trazabilidad SOC 2 Type II del proceso de compra."},{"nombre":"Epixel","tipo":"tercero","categoria":"DMS con módulo de kit y sitio replicado","ejemplos":["Epixel MLM Software"],"nota":"Sitios replicados con áreas editables controladas y soporte a todo tipo de plan, útil para exponer el kit escalonado con presentación consistente entre mercados."},{"nombre":"ByDesign (Freedom)","tipo":"tercero","categoria":"DMS con onboarding basado en journeys","ejemplos":["ByDesign Freedom"],"nota":"Journeys de onboarding por etapa que pueden ligar la elección del kit al perfil declarado del candidato desde el primer contacto."},{"nombre":"BI / analítica de mezcla de kit","tipo":"tercero","categoria":"Analítica de producto/kit","ejemplos":["Power BI","Tableau","Looker"],"nota":"Mide la mezcla de niveles adquiridos y la recompra temprana por tramo, la señal que permite recalibrar el diseño del kit con evidencia."}],"agentesYUseCase":[{"useCase":"Copiloto de recomendación de kit: sugiere el nivel más adecuado según la categoría de interés y el perfil declarado del candidato durante el alta.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — sugiere, humano/candidato decide","valor":"orienta al candidato hacia el tramo que puede absorber, reduciendo la sobre-compra inducida por el sponsor"},{"useCase":"Agente supervisado que proyecta el riesgo de sobre-compra de un candidato dado el tramo elegido versus su perfil y actividad esperada, y lo señala para revisión antes de confirmar el pedido.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — reporta, humano decide","valor":"detecta antes del checkout kits sobredimensionados que luego derivan en recompra o abandono"},{"useCase":"Agentes que correlacionan la mezcla de niveles adquiridos con la activación posterior por tramo para recomendar ajustes al catálogo de kits.","tipo":"S4DS","nivelAutonomia":"multi-agente (nivel 4) — coordina señales, propone ajuste al catálogo","valor":"convierte el diseño del kit en una oferta que se recalibra con datos de uso real, no en una decisión congelada al lanzamiento"},{"useCase":"Recomendador de kit basado en journeys de onboarding (lógica tipo ByDesign) que ajusta la oferta sugerida por país o perfil.","tipo":"tercero","nivelAutonomia":"copiloto (nivel 2)","ejemplos":["ByDesign Freedom — onboarding journeys"],"valor":"personaliza la oferta de kit sin que cada mercado reconstruya la lógica de recomendación"}],"metadata":{"evidenciaEsperada":"Definición vigente del kit (niveles, contenido y precio de cada tramo) + justificación de que el valor es acotado y ligado a habilitar la operación, no a margen.","dolorAsociado":"Kit único, caro y sobredimensionado que funciona como vehículo de margen o de sobre-compra forzada; el costo del reclutamiento se traslada al recién llegado y dis
1para abandono y recompra temprana.","frenteRecomendacion":"Eficiencia/Simplificación de Proceso","fuente":"MASTER-C01 §2 (kit de costo acotado y razonable, no vehículo de margen encubierto), §4.2.4 (kit inicial: salvaguardas anti-inventory-loading), §9 (Amway Starter Stacks modulares/kit personalizable por categoría; doTERRA/Young Living kit escalonado)"},"camposFaltantes":[]},{"practiceId":"C01-04-PR-02","processId":"C01","temaId":"c01-kits-de-inicio-y-activacion","nombre":"Política anti inventory-loading: regla del 70% y límites de compra","pregunta":"¿Controlamos el inventory-loading exigiendo reventa/consumo real a usuario final (regla del 70%) antes de calificar a bonos, con límites de compra por periodo y detección auditable de sobre-inventario?","enunciado":"La organización impide que la compra inicial y la calificación a bonos se motiven por acumular producto en vez de por demanda real: exige que una parte significativa de lo comprado se haya vendido o consumido por usuarios finales —regla del 70%— antes de calificar al bono, fija límites de compra por periodo ligados a la reventa proyectada y hace auditable el exceso de inventario. El autoconsumo por sí solo no satisface la venta genuina, de modo que nadie califica de rango comprándose a sí mismo, en lugar de premiar la carga de inventario y descubrir el abuso solo cuando llega el reclamo o el litigio.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin control anti-loading; se puede calificar a bonos comprando inventario sin evidencia de reventa."},{"nivel":1,"ancla":"1 Existe la idea de no cargar inventario, pero se aplica a criterio y sin verificar reventa ni límites."},{"nivel":2,"ancla":"2 Regla del 70% o límites enunciados en la política, aplicados de forma desigual y sin medición."},{"nivel":3,"ancla":"3 Control definido: regla del 70% de reventa/consumo a usuario final + límites de compra por periodo antes de calificar, documentados y aplicados."},{"nivel":4,"ancla":"4 Control gestionado; se mide el ratio venta-a-usuario-final por vendedor y periodo y se bloquea la calificación basada en autocompra."},{"nivel":5,"ancla":"5 Ningún umbral de la política anti-loading permanece vigente sin una revisión documentada contra los patrones de loading, abandono y recompra detectados en el periodo anterior."}]},"sistemas":{"referenciaMp":"§4 (2.4 límite de compra por periodo, bandera de exceso de inventario auditable), §8 (bloqueo automático de calificación de rango basada en autocompra)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; no hay forma de saber cuánto revendió cada vendedor de lo que compró."},{"nivel":1,"ancla":"1 Cálculo manual del 70% o de los límites sobre planillas, sin trazabilidad."},{"nivel":2,"ancla":"2 Reporte especializado de compras vs. reventa, desconectado de la calificación de bonos."},{"nivel":3,"ancla":"3 Motor de reglas integrado que aplica la regla del 70% y los límites de compra como condición de calificación, con bandera de sobre-inventario auditable."},{"nivel":4,"ancla":"4 Plataforma que calcula en tiempo real el ratio de venta a usuario final y bloquea/retiene la calificación de rango por autocompra."},{"nivel":5,"ancla":"5 Ecosistema donde compras, reventa y calificación fluyen como eventos encadenados sin reconciliación manual, con el ratio auditable extremo a extremo."}]},"agentico":{"anclas":[{"nivel":0,"ancla":"0 Sin IA; la detección de patrones de carga de inventario es completamente manual."},{"nivel":1,"ancla":"1 Alertas simples por reglas fijas (compra que supera el límite del periodo)."},{"nivel":2,"ancla":"2 Copiloto que marca vendedores con patrón de compra sin reventa para revisión."},{"nivel":3,"ancla":"3 Agente supervisado que detecta anomalías de loading (picos de compra sin venta a terceros) y las reporta con contexto."},{"nivel":4,"ancla":"4 Agentes que correlacionan compra, reventa, calificación y recompra para detectar loading estructural de forma coordinada."},{"nivel":5,"ancla":"5 Detección autónoma de loading dentro de políticas, con bloqueo de calificación y escalamiento de casos límite por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Motor de Reglas Anti-Loading","tipo":"S4DS","categoria":"Motor de reglas de compliance sobre calificación","coberturaS4DS":"módulo Comisiones · regla del 70%/límite de compra como condición de calificación · bandera de sobre-inventario auditable · MCP compliance/rules tools","nota":"Aplica la regla del 70% y los límites de compra por periodo como gate automático antes de calificar a bono, con el ratio venta-a-usuario-final calculado por vendedor y periodo."},{"nombre":"Epixel","tipo":"tercero","categoria":"Módulo de compliance y detección de fraude","ejemplos":["Epixel MLM Software — módulo de compliance/fraude"],"nota":"Mayor ritmo público de lanzamientos de IA 2025-2026 orientados a detección de patrones de compra sin reventa de
1ntro de la propia plataforma de genealogía."},{"nombre":"Exigo","tipo":"tercero","categoria":"DMS con motor de comisiones configurable","ejemplos":["Exigo Core"],"nota":"Motor de comisiones event-driven donde el bloqueo de calificación por autocompra puede modelarse como condición del cálculo en tiempo real, no como revisión posterior."},{"nombre":"InfoTrax FlexCloud","tipo":"tercero","categoria":"Motor de genealogía/comisión a escala con audit trail","ejemplos":["InfoTrax FlexCloud","InfoTrax Evo"],"nota":"Audit trail nativo dimensionado para árboles grandes, útil para reconstruir retroactivamente el ratio venta-a-usuario-final ante una disputa o requerimiento regulatorio."},{"nombre":"BI / analítica de ratio venta-a-usuario-final","tipo":"tercero","categoria":"Analítica de compliance","ejemplos":["Power BI","Tableau","Looker"],"nota":"Expone el ratio compra-vs-reventa por vendedor/periodo como tablero de vigilancia continua, no solo como reporte ad-hoc ante una alerta."}],"agentesYUseCase":[{"useCase":"Copiloto que marca vendedores con patrón de compra sin evidencia de reventa a terceros para revisión del equipo de compliance.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — sugiere, humano revisa","valor":"adelanta la detección de posible loading antes de que llegue a la calificación de bono"},{"useCase":"Agente supervisado que detecta anomalías de carga de inventario (picos de compra sin venta a terceros) y reporta el caso con el contexto de compras/reventa del periodo.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — detecta y reporta, humano decide","valor":"convierte el ratio venta-a-usuario-final de una métrica retrospectiva en una señal de alerta operable"},{"useCase":"Agentes que correlacionan compra, reventa, calificación de rango y recompra para detectar loading estructural (no solo un pico aislado) de forma coordinada.","tipo":"tercero","nivelAutonomia":"multi-agente (nivel 4)","ejemplos":["Epixel — módulo de compliance/fraude"],"valor":"distingue un episodio aislado de un patrón sistémico de carga de inventario en toda una rama"},{"useCase":"Detección autónoma de loading dentro de políticas definidas, con bloqueo automático de la calificación por autocompra y escalamiento de casos límite a compliance.","tipo":"S4DS","nivelAutonomia":"agente supervisado → autónomo acotado (nivel 4-5) — siempre con gate humano en casos límite","valor":"cierra el vector legal central del sector sin depender de que alguien recuerde aplicar la regla manualmente"}],"metadata":{"evidenciaEsperada":"Política anti-loading vigente (regla del 70%, límites de compra por periodo) + evidencia de ratio venta-a-usuario-final calculado por vendedor y de calificaciones bloqueadas por autocompra.","dolorAsociado":"Inventory-loading: vendedores que compran para calificar a compensación en vez de por demanda real; el autoconsumo tratado como venta genuina y una buyback que no blinda un diseño que premia el reclutamiento sobre la venta.","frenteRecomendacion":"Gobierno/Roles/Tercerización","fuente":"MASTER-C01 §2 (regla del 70% DSA; el autoconsumo no basta para la venta genuina según FTC), §4.2.4 (In re Amway: regla del 70%, regla de 10 clientes/mes; límite de compra por periodo ligado a reventa proyectada), §8 (inventory loading como vector legal central; buyback no blinda; bloqueo de calificación por autocompra), §7 (ratio venta-a-usuario-final auditable por vendedor/periodo)"},"camposFaltantes":[]},{"practiceId":"C01-04-PR-03","processId":"C01","temaId":"c01-kits-de-inicio-y-activacion","nombre":"Política de recompra (buyback ≥90%) operable desde el día 1","pregunta":"¿La política de recompra/reembolso (~90% del costo neto en ≤12 meses, más reembolso incondicional a corto plazo) está publicada, reservada financieramente y operable como flujo desde el día 1, y no como gestión manual caso a caso?","enunciado":"La organización garantiza desde el enrolamiento una política de recompra y reembolso de valor generoso y previsible —reembolso incondicional a corto plazo y recompra de al menos el 90% del costo neto dentro de los doce meses— ofrecida a todo vendedor que termina y califica, publicada, reservada financieramente y ejecutable como un flujo operable, no como una cortesía manual caso a caso. La recompra se diseña desde la inscripción porque define el compromiso que el back-office honrará meses o años después, en lugar de descubrir su costo y su operativa recién cuando alguien la reclama.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin política de recompra; quien deja el negocio no tiene forma clara de devolver el kit o el producto no vendido."},{"nivel":1,"ancla":"1 Recompra concedida de forma ad-hoc y discrecional, sin porcentaje, plazo ni disponibilidad garantizada."},{"nivel":2,"ancla":"2 Política de recompra enunciada (porcentaje/plazo), pero operada manualmente y no siempre honrada."},{"nivel":3,"ancla":"3 Política definida y publicada (reembolso corto plazo + recompra ≥90% en ≤12 meses) ofrecida a todo vendedor que califica, con flujo operativo claro."},{"nivel":4,"ancla":"4 Recompra gestionada con reserva financiera de
1sde el alta, SLA de procesamiento y medición del % de kits recomprados en los primeros 90 días."},{"nivel":5,"ancla":"5 Ninguna política de recompra permanece vigente sin una revisión documentada contra la señal temprana de recompra (mala calidad de enrolamiento) y su costo real del periodo anterior."}]},"sistemas":{"referenciaMp":"§4 (2.4 flujo de recompra pre-configurado y financieramente reservado desde el día 1), §7 (% kits recomprados en primeros 90 días)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; la recompra, si ocurre, se tramita por correo sin registro ni reserva."},{"nivel":1,"ancla":"1 Solicitudes de recompra por correo o planilla, sin flujo ni provisión asociada."},{"nivel":2,"ancla":"2 Formato de recompra especializado, desconectado del alta, del inventario y de la contabilidad."},{"nivel":3,"ancla":"3 Flujo de recompra integrado al ciclo del vendedor que calcula el reembolso y deja trazado el caso, ligado al registro del kit."},{"nivel":4,"ancla":"4 Plataforma que reserva la provisión de recompra desde el alta y expone el estado y el SLA de cada solicitud en tiempo real."},{"nivel":5,"ancla":"5 Ecosistema donde alta→kit→recompra→liquidación operan como eventos encadenados sin intervención manual, con la provisión conciliada de extremo a extremo."}]},"agentico":{"anclas":[{"nivel":0,"ancla":"0 Sin IA; tramitar y priorizar las recompras es completamente manual."},{"nivel":1,"ancla":"1 Alertas por vencimiento de la ventana de recompra o de reembolso."},{"nivel":2,"ancla":"2 Copiloto que arma el expediente de recompra (kit, compras, plazo, elegibilidad) para el revisor."},{"nivel":3,"ancla":"3 Agente supervisado que valida elegibilidad, calcula el monto y prepara la recompra para aprobación."},{"nivel":4,"ancla":"4 Agentes que coordinan recompra, inventario y liquidación, y priorizan casos por riesgo y plazo."},{"nivel":5,"ancla":"5 Recompra autónoma dentro de políticas, con cálculo y ejecución del reembolso y escalamiento de excepciones por revisión."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Motor de Recompra/Buyback","tipo":"S4DS","categoria":"Flujo de recompra integrado al ciclo del vendedor","coberturaS4DS":"módulo Comisiones/Offboarding · flujo de recompra pre-configurado y financieramente reservado desde el alta · MCP buyback tools","nota":"Calcula el monto de recompra, reserva la provisión desde el día 1 y deja trazado el caso ligado al registro del kit, con SLA visible."},{"nombre":"Exigo","tipo":"tercero","categoria":"DMS con motor de comisiones/offboarding configurable","ejemplos":["Exigo"],"nota":"Permite modelar el flujo de recompra como parte del ciclo de vida del vendedor dentro de la misma plataforma que gestiona comisiones y genealogía."},{"nombre":"DirectScale","tipo":"tercero","categoria":"DMS SaaS con modelado de escenarios","ejemplos":["DirectScale"],"nota":"Soporta configuración sin código de reglas de terminación y recompra, útil para ajustar porcentaje/plazo por jurisdicción sin desarrollo a medida."},{"nombre":"ERP (reserva financiera)","tipo":"tercero","categoria":"Sistema financiero de registro","ejemplos":["SAP","Oracle NetSuite","Microsoft Dynamics 365"],"nota":"Contabiliza y concilia la provisión de recompra reservada desde el alta, evitando que el compromiso compita sin fondos con el flujo de caja del momento de la terminación."},{"nombre":"WMS / logística de devolución","tipo":"tercero","categoria":"Gestión de devoluciones e inventario físico","ejemplos":["Deposco","ShipHero","fulfillment por 3PL"],"nota":"Gestiona la recepción y el reingreso a inventario del producto devuelto en una recompra, cerrando el ciclo físico que acompaña al ciclo financiero."}],"agentesYUseCase":[{"useCase":"Copiloto que arma el expediente de recompra (kit adquirido, historial de compras, plazo transcurrido, elegibilidad) para el revisor humano.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — prepara, humano decide","valor":"reduce el tiempo de tramitación manual y evita que un caso elegible se pierda por falta de seguimiento"},{"useCase":"Agente supervisado que valida la elegibilidad, calcula el monto de recompra (≥90% del costo neto dentro de la ventana) y prepara el caso para aprobación.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — calcula y propone, humano aprueba","valor":"hace el cálculo consistente y auditable en vez de depender de la interpretación de quien atiende el caso"},{"useCase":"Agentes que coordinan recompra, inventario y liquidación financiera, priorizando casos por riesgo (plazo próximo a vencer, jurisdicción con obligación legal) y plazo.","tipo":"S4DS","nivelAutonomia":"multi-agente (nivel 4)","valor":"evita que una recompra legalmente exigida en una jurisdicción específica se retrase por falta de priorización"},{"useCase":"Recompra autónoma dentro de políticas para casos estándar (montos bajo un umbral, elegibilidad clara), con cálculo y ejecución del reembolso y escalamiento de excepciones a revisión humana.","tipo":"S4DS","nivelAutonomia":"autónomo acotado (nivel 5) — con gate humano en excepciones","valor":"convierte el SLA de recompra en un compromiso operable a escala, no en un cuello de botella manual"}],"metadata":{"evidenciaEsperada":"Política de recompra/reembolso publicada + evidencia de provisión financiera reservada desde el alta y de recompras ejecutadas por flujo (no manuales) con su SLA y el % de kits recomprados a 90 días.","dolorAsociado":"Recompra inexistente en la práctica o tramitada manualmente caso a caso; su ausencia efectiva fue exactamente lo litigado en el sector, y sin reserva desde el día 1 el compromiso se honra tarde o no se honra.","frenteRecomendacion":"Gobierno/Roles/Tercerización","fuente":"MASTER-C01 §2 (reembolso incondicional a corto plazo — 100% en 30 días — y recompra del 90% del costo neto dentro de 1 año), §4.2.4 (flujo de recompra pre-configurado y financieramente reservado desde el día 1; recompra ≥90% en terminación), §8 (la buyback debe ofrecerse a todo vendedor que termina y califica), §10 (publicar y operativizar la buyback policy como flujo ejecutable, no manual)"},"camposFaltantes":[]},{"practiceId":"C01-04-PR-04","processId":"C01","temaId":"c01-kits-de-inicio-y-activacion","nombre":"Definición de activación como umbral de volumen (PV/BV) en una ventana temporal","pregunta":"¿Definimos 'activación' como un umbral cuantitativo de volumen (PV/BV) alcanzado dentro de una ventana temporal configurable y auditable, en lugar de un estado binario o el pago del kit?","enunciado":"La organización define la activación —el paso de inscrito a activo— no como un estado binario ni como el pago del kit, sino como una condición cuantitativa de volumen: alcanzar un umbral de PV/BV dentro de una ventana temporal definida (por ejemplo los primeros 30 a 60 días), con el umbral y la ventana como parámetros configurables y auditables y no fijados de forma rígida en el código. Así la tasa de activación mide comportamiento comercial real y n
1o conversión de checkout, en lugar de llamar activo a cualquiera que completó el alta o pagó el kit.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin definición de activación; 'activo' equivale a inscrito o a haber pagado el kit."},{"nivel":1,"ancla":"1 Idea informal de 'activo' que cada área interpreta distinto, sin umbral ni ventana."},{"nivel":2,"ancla":"2 Definición repetible pero cualitativa o cambiante (p. ej. 'compró algo'), sin umbral de volumen ni ventana fija."},{"nivel":3,"ancla":"3 Activación definida como umbral cuantitativo de PV/BV dentro de una ventana temporal explícita, documentada y aplicada."},{"nivel":4,"ancla":"4 Definición gestionada con umbral y ventana como parámetros configurables y auditables; la tasa de activación se mide contra esa definición."},{"nivel":5,"ancla":"5 Ningún umbral o ventana de activación permanece vigente sin una revisión documentada contra la retención y el ingreso real observados en el periodo anterior."}]},"sistemas":{"referenciaMp":"§7 (ventana rolling 60/90 días como campo configurable y auditable, no hardcodeado), §2 (umbrales PV/BV como estándar de industria)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; no existe forma de calcular volumen acumulado en una ventana."},{"nivel":1,"ancla":"1 Cálculo manual del volumen del periodo en hoja de cálculo para decidir quién está activo."},{"nivel":2,"ancla":"2 Reporte especializado de volumen por vendedor, con la ventana fijada de forma rígida."},{"nivel":3,"ancla":"3 Definición de activación parametrizada (umbral y ventana configurables) en la plataforma de vendedores, aplicada al cálculo."},{"nivel":4,"ancla":"4 Plataforma que evalúa el umbral de PV/BV en la ventana en tiempo real y expone el estado de activación de forma auditable."},{"nivel":5,"ancla":"5 Ecosistema donde volumen, ventana y estado de activación se calculan por evento de extremo a extremo sin ajustes manuales."}]},"agentico":{"anclas":[{"nivel":0,"ancla":"0 Sin IA; nadie proyecta quién alcanzará el umbral dentro de la ventana."},{"nivel":1,"ancla":"1 Alertas simples cuando un vendedor cruza el umbral de PV/BV."},{"nivel":2,"ancla":"2 Copiloto que estima qué tan cerca está cada nuevo vendedor de activarse en su ventana."},{"nivel":3,"ancla":"3 Agente supervisado que proyecta la probabilidad de activación en la ventana y señala a quienes van rezagados."},{"nivel":4,"ancla":"4 Agentes que combinan volumen, comportamiento y perfil para anticipar activación y coordinar señales priorizadas."},{"nivel":5,"ancla":"5 Proyección autónoma de activación dentro de políticas, calibrada con los resultados observados de retención e ingreso, con escalamiento a revisión humana por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Motor de Volumen y Activación","tipo":"S4DS","categoria":"Cálculo de volumen y ventana de activación","coberturaS4DS":"módulo Comisiones · umbral de PV/BV y ventana rolling configurables y auditables · MCP volume/activation tools","nota":"Calcula el volumen acumulado por vendedor dentro de la ventana definida y expone el estado de activación como parámetro configurable, no hardcodeado."},{"nombre":"Exigo Core","tipo":"tercero","categoria":"Motor de comisiones event-driven","ejemplos":["Exigo Core"],"nota":"Arquitectura event-driven que permite evaluar el umbral de PV/BV en tiempo real conforme entra cada pedido, en vez de en un batch nocturno."},{"nombre":"Epixel","tipo":"tercero","categoria":"Motor PV/BV plan-agnóstico","ejemplos":["Epixel MLM Software"],"nota":"Soporta el cálculo de PV/BV sobre distintos arquetipos de plan, útil cuando la organización sostiene más de una definición de activación por mercado o marca."},{"nombre":"BI / analítica de funnel de activación","tipo":"tercero","categoria":"Analítica de funnel","ejemplos":["Power BI","Tableau","Looker"],"nota":"Expone el funnel Inscrito→Activo por compra→Activo con ingreso neto positivo, evitando que los primeros dos tramos sobreestimen el éxito real."}],"agentesYUseCase":[{"useCase":"Alertas simples cuando un vendedor cruza el umbral de PV/BV dentro de su ventana.","tipo":"S4DS","nivelAutonomia":"asistido
1/reglas (nivel 1)","valor":"hace visible en tiempo real el momento exacto de activación sin esperar un reporte por lote"},{"useCase":"Copiloto que estima qué tan cerca está cada nuevo vendedor de activarse dentro de su ventana, con base en el volumen acumulado a la fecha.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2)","valor":"permite intervenir antes de que la ventana se cierre, en vez de descubrir la no-activación después del hecho"},{"useCase":"Agente supervisado que proyecta la probabilidad de activación en la ventana restante y señala a los rezagados con mayor riesgo de no llegar al umbral.","tipo":"tercero","nivelAutonomia":"agente supervisado (nivel 3)","ejemplos":["Exigo AI","Rallyware"],"valor":"convierte la definición cuantitativa de activación en una señal predictiva y no solo retrospectiva"},{"useCase":"Agentes que combinan volumen, comportamiento (primera venta, primer reorder) y perfil declarado para anticipar la activación y coordinar señales priorizadas de intervención.","tipo":"tercero","nivelAutonomia":"multi-agente (nivel 4)","ejemplos":["Rallyware Intelligent Field Orchestration"],"valor":"conecta la métrica de activación con la acción operativa que puede cambiarla, no solo con el reporte"}],"metadata":{"evidenciaEsperada":"Definición documentada de 'activación' (umbral de PV/BV y ventana temporal) con evidencia de que umbral y ventana son parámetros configurables y auditables, más el cálculo de la tasa de activación sobre esa definición.","dolorAsociado":"'Activación' cosmética que mide conversión de checkout y no comportamiento comercial; la mayoría de participantes no vende ni patrocina, por lo que una tasa de activación atada al pago del kit sobreestima el éxito.","frenteRecomendacion":"Tecnología e Integración","fuente":"MASTER-C01 §2 (activación como evento medible: PV y BV alimentan comisión, bono y rango; umbrales tipo Success Builder 1.000 puntos/mes y Supervisor 4.000 VP; ventana de 30-60 días), §4.2.5 ('activo' como condición de volumen con ventana temporal, no binario), §7 (definición de 'activo' como ventana rolling configurable y auditable, no hardcodeada)"},"camposFaltantes":[]},{"practiceId":"C01-04-PR-05","processId":"C01","temaId":"c01-kits-de-inicio-y-activacion","nombre":"Desacople entre el pago del kit y la activación / derecho a comisiones","pregunta":"¿La activación y el derecho a comisiones están desacoplados del pago/compra del kit, disparándose por un evento de volumen o venta verificable y no por el checkout del kit?","enunciado":"La organización mantiene separados la adquisición y el pago del kit, por un lado, y la activación y el derecho a ganar comisiones, por otro: el derecho a comisiones se dispara por un evento de volumen o de venta verificable, no por el checkout del kit, y el paso a vendedor con beneficios depende de una acción comercial real y no de haber pagado el ticket de entrada. Así, pagar el kit no otorga por sí mismo la activación y la métrica de 'activo' no refleja carga de inventario, en lugar de convertir la compra del kit en la puerta automática a la compensación.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin desacople; pagar el kit activa automáticamente y habilita el derecho a comisiones."},{"nivel":1,"ancla":"1 El desacople se aplica de forma inconsistente; a veces el pago del kit cuenta como activación."},{"nivel":2,"ancla":"2 Se distingue en la política kit y activación, pero la operación aún ata el derecho a comisiones a la compra del kit."},{"nivel":3,"ancla":"3 Desacople definido: la activación y el derecho a comisiones se disparan por un evento de volumen/venta verificable, no por el pago del kit."},{"nivel":4,"ancla":"4 Desacople gestionado; se mide qué proporción de activaciones proviene de venta real vs. de compra de kit y se corrige la desviación."},{"nivel":5,"ancla":"5 Ninguna activación se habilita sin el evento de volumen verificable independiente del cobro del kit; la regla del evento activador se revisa contra la proporción real de venta vs. autocompra de cada periodo."}]},"sistemas":{"referenciaMp":"§4 (2.5 evento de primera calificación PV/autoship que dispara el sponsor bonus, separado del pago), §2 (activación desacoplada del pago del kit)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; el pago del kit y la habilitación de comisiones ocurren en el mismo paso de checkout."},{"nivel":1,"ancla":"1 Kit y activación en el mismo registro; separar el derecho a comisiones del pago del kit es manual."},{"nivel":2,"ancla":"2 El checkout marca 'activo' al cobrar el kit; no hay evento de volumen independiente que gobierne la comisión."},{"nivel":3,"ancla":"3 La plataforma modela la activación como un evento de volumen/venta distinto del pago del kit y condiciona la comisión a ese evento."},{"nivel":4,"ancla":"4 Plataforma que en tiempo real dispara la habilitación de comisiones solo con el evento de volumen verificable, independiente del cobro del kit."},{"nivel":5,"ancla":"5 Ecosistema donde compra de kit, activación y habilitación de comisiones son eventos separados y encadenados sin intervención manual."}]},"agentico":{"anclas":[{"nivel":0,"ancla":"0 Sin IA;
1 verificar que la activación provino de venta real y no del kit es manual."},{"nivel":1,"ancla":"1 Alertas cuando una activación coincide exactamente con el pago del kit."},{"nivel":2,"ancla":"2 Copiloto que marca activaciones sospechosas de estar atadas a la compra del kit para revisión."},{"nivel":3,"ancla":"3 Agente supervisado que distingue activaciones por venta real de las derivadas de autocompra del kit y las reporta."},{"nivel":4,"ancla":"4 Agentes que correlacionan pago de kit, volumen y comisión para detectar acoplamientos indebidos de forma coordinada."},{"nivel":5,"ancla":"5 Verificación autónoma del desacople dentro de políticas, con retención de comisión ante activación no genuina y escalamiento por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Motor de Comisiones (evento de activación desacoplado)","tipo":"S4DS","categoria":"Motor de comisiones / hand-off de activación","coberturaS4DS":"módulo Comisiones · evento de activación por volumen/venta separado del checkout del kit · MCP commission/activation-event tools","nota":"Modela la activación como un evento de volumen/venta verificable, distinto del pago del kit, y condiciona el derecho a comisiones a ese evento y no al checkout."},{"nombre":"Exigo Core","tipo":"tercero","categoria":"Motor de comisiones event-driven","ejemplos":["Exigo Core"],"nota":"Permite separar en el flujo de eventos el pago del kit del evento de calificación PV/autoship que efectivamente dispara el sponsor bonus."},{"nombre":"Epixel","tipo":"tercero","categoria":"Módulo de compliance/fraude","ejemplos":["Epixel MLM Software"],"nota":"Su módulo de compliance puede configurarse para vigilar que las reglas de activación no colapsen en la práctica al evento de checkout del kit."},{"nombre":"BI / analítica de coincidencia checkout-activación","tipo":"tercero","categoria":"Analítica de compliance","ejemplos":["Power BI","Tableau"],"nota":"Mide qué proporción de activaciones coincide en tiempo/monto con el pago del kit, el indicador más directo de si el desacople es real o solo de política."}],"agentesYUseCase":[{"useCase":"Alertas cuando una activación registrada coincide exactamente en tiempo y monto con el pago del kit.","tipo":"S4DS","nivelAutonomia":"asistido/reglas (nivel 1)","valor":"expone de inmediato el síntoma más directo de que el desacople no se está aplicando en la operación real"},{"useCase":"Copiloto que marca activaciones sospechosas de estar atadas a la compra del kit para revisión de compliance.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2)","valor":"prioriza la revisión humana hacia los casos con mayor probabilidad de acoplamiento indebido"},{"useCase":"Agente supervisado que distingue activaciones originadas en venta/volumen real de las derivadas de autocompra del kit, y reporta el patrón por sponsor o campaña.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3)","valor":"hace visible si el acoplamiento indebido es un caso aislado o un patrón sistemático de una rama o campaña de reclutamiento"},{"useCase":"Agentes que correlacionan pago de kit, volumen y comisión pagada para detectar acoplamientos indebidos de forma coordinada a través de la red.","tipo":"tercero","nivelAutonomia":"multi-agente (nivel 4)","ejemplos":["Epixel — módulo de compliance/fraude"],"valor":"detecta el problema a escala de red, no solo caso por caso"},{"useCase":"Verificación autónoma del desacople dentro de políticas, con retención automática de comisión ante activación no genuina y escalamiento de excepciones a compliance.","tipo":"S4DS","nivelAutonomia":"autónomo acotado (nivel 5) — con gate humano en excepciones","valor":"convierte el desacople de una regla de diseño en una garantía operativa verificada en cada ciclo de pago"}],"metadata":{"evidenciaEsperada":"Regla que define el evento que dispara la activación y el derecho a comisiones (volumen/venta verificable) mostrando su independencia del pago del kit + muestra de activaciones con su evento originador.","dolorAsociado":"Activación atada al pago del kit: la 'tasa de activación' mide conversión de checkout y la compensación se gatilla por comprar el kit y no por vender, alimentando el inventory-loading y el riesgo anti-pirámide.","frenteRecomendacion":"Tecnología e Integración","fuente":"MASTER-C01 §2 (la activación debe estar desacoplada del pago del kit y atada a un evento de volumen/venta verificable en una ventana), §4.2.5 (el evento de primera calificación PV/autoship dispara el sponsor bonus; hand-off al motor de comisiones), §9 (en Young Living el paso de cliente a vendedor ocurre por acción de reclutamiento, no por compra de kit), §10 (definición de activación desacoplada del pago del kit)"},"camposFaltantes":[]},{"practiceId":"C01-04-PR-06","processId":"C01","temaId":"c01-kits-de-inicio-y-activacion","nombre":"Activación como evento versionado que mide y habilita comisiones y beneficios","pregunta":"¿El estado de activación se mide y se hace visible como evento versionado (fecha, volumen, fuente) que habilita comisiones, bonos y rango, en lugar de un campo que se actualiza y se olvida?","enunciado":"La organización trata cada activación como un evento de primera clase, versionado y auditable (fecha, monto de volumen y fuente del pedido) que gobierna la habilitación de comisiones, bonos de patrocinio y avance de rango, y hace visible tanto el estado de activación de cada vendedor dentro de su ventana como la tasa de activación del conjunto. De este modo la activación dispara aguas abajo la habilitación de beneficios en vez de quedar como un campo que se actualiza y se olvida, y todos ven quién está activo, quién no y qué beneficios habilita ese estado.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin registro del evento de activación; nadie sabe con certeza quién está activo ni desde cuándo."},{"nivel":1,"ancla":"1 La activación se anota de forma informal; no dispara de manera fiable comisiones ni beneficios."},{"nivel":2,"ancla":"2 Se registra el estado activo/inactivo de forma repetible, sin versionar el evento ni hacerlo visible al conjunto."},{"nivel":3,"ancla":"3 Activación registrada como evento versionado (fecha, volumen, fuente) que habilita comisiones, bonos y rango, con estado visible por vendedor."},{"nivel":4,"ancla":"4 Activación gestionada; la tasa de activación y su efecto en la habilitación de beneficios se miden y se exponen en tablero contra objetivos."},{"nivel":5,"ancla":"5 Activación optimizada; el evento alimenta en continuo la habilitación de beneficios y la intervención temprana s
1obre quienes no activan."}]},"sistemas":{"referenciaMp":"§4 (2.5 hand-off directo al motor de comisiones versionado: fecha, monto de PV, fuente del pedido), §7 (tasa de activación y funnel de activación como KPI)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; el estado de activación no está disponible al liquidar ni al reportar."},{"nivel":1,"ancla":"1 Estado de activación en planilla, actualizado a mano y desconectado de la liquidación."},{"nivel":2,"ancla":"2 El sistema guarda un flag de activación, sin versionar el evento ni alimentar automáticamente la comisión."},{"nivel":3,"ancla":"3 La activación es un evento versionado que el motor de comisiones consume para habilitar comisiones/bonos/rango, con estado consultable."},{"nivel":4,"ancla":"4 Plataforma que expone en tiempo real el estado de activación y la tasa de activación, y habilita/retiene beneficios según ese estado."},{"nivel":5,"ancla":"5 Ecosistema donde el evento de activación fluye de la venta al motor de comisiones y al reporting sin transferencias manuales, con audit trail completo."}]},"agentico":{"referenciaMp":"§6 (predicción de churn + next-best-action; leading indicators de activación como triggers de intervención)","anclas":[{"nivel":0,"ancla":"0 Sin IA; detectar a quienes no activarán en su ventana es manual y tardío."},{"nivel":1,"ancla":"1 Alertas por proximidad del fin de la ventana sin activación alcanzada."},{"nivel":2,"ancla":"2 Copiloto que prioriza a los vendedores en riesgo de no activar para seguimiento."},{"nivel":3,"ancla":"3 Agente supervisado que monitorea el avance hacia la activación y propone la next-best-action para los rezagados."},{"nivel":4,"ancla":"4 Agentes que coordinan la lectura del estado de activación con intervenciones de onboarding priorizadas 24/7."},{"nivel":5,"ancla":"5 Orquestación autónoma dentro de políticas que dispara intervenciones de activación y ajusta la estrategia con los resultados, con escalamiento por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Motor de Comisiones (evento de activación versionado)","tipo":"S4DS","categoria":"Motor de comisiones / audit trail de activación","coberturaS4DS":"módulo Comisiones · evento de activación versionado (fecha, PV, fuente) que habilita comisiones/bonos/rango · tablero de estado y tasa de activación · MCP activation-event tools","nota":"Registra cada activación como evento de primera clase que el motor de comisiones consume directamente, con estado consultable por vendedor y tasa agregada visible en tablero."},{"nombre":"Exigo Core","tipo":"tercero","categoria":"Motor de comisiones event-driven en tiempo real","ejemplos":["Exigo Core"],"nota":"Arquitectura event-driven de referencia donde cada transición de estado, incluida la activación, se calcula en tiempo real en lugar de en batch nocturno."},{"nombre":"Rallyware","tipo":"tercero","categoria":"Orquestación de campo / next-best-action","ejemplos":["Rallyware Intelligent Field Orchestration"],"nota":"Consume el estado de activación como disparador de next-best-action por vendedor, conectando la métrica con la intervención operativa."},{"nombre":"Epixel","tipo":"tercero","categoria":"DMS con dashboards de activación","ejemplos":["Epixel MLM Software"],"nota":"Expone la tasa de activación y el funnel del conjunto en dashboards, útil como referencia visual del estado agregado del proceso."},{"nombre":"BI / analítica de funnel y tasa de activación","tipo":"tercero","categoria":"Analítica de KPI","ejemplos":["Power BI","Tableau","Looker"],"nota":"Mide y expone contra objetivo la tasa de activación y el efecto de la activación en la habilitación de beneficios a lo largo del tiempo."}],"agentesYUseCase":[{"useCase":"Alertas por proximidad del fin de la ventana de activación sin que el vendedor haya alcanzado el umbral.","tipo":"S4DS","nivelAutonomia":"asistido/reglas (nivel 1)","valor":"da tiempo de reacción antes de que la ventana cierre, en lugar de constatar la no-activación después"},{"useCase":"Copiloto que prioriza a los vendedores en riesgo de no activar para el seguimiento del sponsor o del equipo de retención.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2)","valor":"concentra el esfuerzo humano de seguimiento en quienes más lo necesitan, no en toda la cohorte por igual"},{"useCase":"Agente supervisado que monitorea el avance hacia la activación y propone la next-best-action para los rezagados de
1ntro de su ventana.","tipo":"tercero","nivelAutonomia":"agente supervisado (nivel 3)","ejemplos":["Rallyware Intelligent Field Orchestration","Exigo AI"],"valor":"convierte el leading indicator de activación en una acción concreta sugerida, no solo en una alerta"},{"useCase":"Agentes que coordinan la lectura del estado de activación con intervenciones de onboarding priorizadas de forma continua.","tipo":"tercero","nivelAutonomia":"multi-agente (nivel 4)","ejemplos":["Rallyware Intelligent Field Orchestration"],"valor":"sostiene la intervención de forma continua en vez de campañas puntuales desconectadas del estado real de cada vendedor"},{"useCase":"Orquestación autónoma dentro de políticas que dispara intervenciones de activación y ajusta la estrategia con los resultados observados, con escalamiento por excepción.","tipo":"S4DS","nivelAutonomia":"autónomo acotado (nivel 5) — con gate humano en excepciones y auditoría de earnings claims generados","valor":"escala la gestión de activación a toda la red sin perder trazabilidad ni control de compliance sobre lo que el agente comunica"}],"metadata":{"evidenciaEsperada":"Muestra de eventos de activación versionados (fecha, volumen, fuente del pedido) enlazados a la habilitación de comisiones/bonos/rango + tablero con el estado de activación por vendedor y la tasa de activación del periodo.","dolorAsociado":"Activación tratada como un campo que se actualiza y se olvida, no como evento que el motor de comisiones consume; sin visibilidad del estado y de la tasa de activación se pierde la palanca principal de LTV en los primeros 30-90 días.","frenteRecomendacion":"Modelos Agénticos/IA","fuente":"MASTER-C01 §1 (cada transición de estado como evento de primera clase que el motor de comisiones consume), §4.2.5 (evento de primera calificación PV que dispara el sponsor bonus; hand-off versionado: fecha, monto de PV, fuente del pedido), §7 (definición de 'activo', tasa de activación y funnel dual como KPI), §6 (predicción de churn y next-best-action; instrumentar leading indicators como triggers de intervención)"},"camposFaltantes":[]},{"practiceId":"C01-05-PR-01","processId":"C01","temaId":"c01-onboarding-y-habilitacion-temprana","nombre":"Journey de onboarding 0-90 días con hitos día 1/7/30/60/90 y metas escalonadas de volumen","pregunta":"¿Los primeros 90 días son un journey estructurado con hitos explícitos a día 1/7/30/60/90, responsables por hito y metas escalonadas de volumen, en lugar de un checklist informal dependiente del patrocinador?","enunciado":"La organización opera los primeros 90 días como un journey estructurado, y no como un checklist informal dependiente del patrocinador: define hitos explícitos a día 1, 7, 30, 60 y 90, cada uno con un responsable (patrocinador, corporativo, back-office) y con metas escalonadas de volumen que construyen el hábito comercial de forma progresiva, atacando el tramo de mayor abandono del primer trimestre. Así cada nuevo vendedor recorre una ruta consistente con expectativas claras por tramo, en lugar de un acompañamiento que varía según quién lo enroló y qué recuerde hacer.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin journey de onboarding; tras el alta el nuevo vendedor queda librado a sí mismo o a lo que decida el patrocinador."},{"nivel":1,"ancla":"1 Onboarding informal que depende de cada patrocinador; sin hitos ni metas definidas y con resultados inconsistentes."},{"nivel":2,"ancla":"2 Existe una guía o checklist de primeros pasos aplicada de forma parcial, sin hitos temporales ni metas escalonadas de volumen."},{"nivel":3,"ancla":"3 Journey 0-90 días documentado con hitos a día 1/7/30/60/90, responsables por hito y metas escalonadas de volumen, aplicado de forma consistente."},{"nivel":4,"ancla":"4 Journey gestionado; se mide el cumplimiento de cada hito y el avance hacia las metas por tramo contra objetivos, y se corrigen desviaciones."},{"nivel":5,"ancla":"5 Ningún hito, meta o cadencia del journey permanece vigente sin una revisión documentada contra la retención al primer trimestre observada en la cohorte anterior."}]},"sistemas":{"referenciaMp":"§4 (2.6 onboarding como flujo orquestado por evento de comportamiento), §10 (playbook 30-60-90 formalizado con gates automatizados por día)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; los hitos, si existen, se llevan de memoria o por correos sueltos sin registro del avance."},{"nivel":1,"ancla":"1 Journey documentado en una hoja de cálculo o documento estático, actualizado a mano y sin disparadores por hito."},{"nivel":2,"ancla":"2 Herramienta especializada de onboarding o de gestión de tareas que lista los hitos, desconectada del volumen y de la comisión."},{"nivel":3,"ancla":"3 Journey configurado en la plataforma de vendedores integrado al alta y al volumen, con hitos y metas por tramo consultables."},{"nivel":4,"ancla":"4 Plataforma que orquesta el journey por evento de comportamiento en tiempo real y expone el avance por hito y por tramo de forma auditable."},{"nivel":5,"ancla":"5 Ecosistema donde alta, volumen, hitos y comunicación fluyen sin transferencias manuales para ajustar el journey de extremo a extremo."}]},"agentico":{"referenciaMp":"§6 (onboarding conversacional; next-best-action por vendedor)","anclas":[{"nivel":0,"ancla":"0 Sin IA; nadie anticipa qué nuevo vendedor va rezagado en su journey ni qué paso sigue."},{"nivel":1,"ancla":"1 Recordatorios simples por regla fija al aproximarse la fecha de un hito."},{"nivel":2,"ancla":"2 Copiloto que sugiere el siguiente paso del journey y responde dudas del nuevo vendedor sobre su ruta."},{"nivel":3,"ancla":"3 Agente supervisado que guía el journey extremo a extremo, propone la next-best-action por hito y señala a quienes van rezagados."},{"nivel":4,"ancla":"4 Agentes que coordinan el avance del journey con las señales de comportamiento y priorizan intervenciones por tramo de forma orquestada 24/7."},{"nivel":5,"ancla":"5 Orquestación autónoma del journey dentro de políticas, que ajusta hitos y metas 
1según los resultados de retención con escalamiento por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Motor de Onboarding / Journey 0-90 días","tipo":"S4DS","categoria":"Orquestación de journey del vendedor","coberturaS4DS":"módulo Onboarding · hitos día 1/7/30/60/90 configurables · MCP journey/milestone tools","nota":"Define y da seguimiento a los hitos y a las metas escalonadas de volumen por tramo, con responsable asignado por hito y estado consultable por cohorte."},{"nombre":"Rallyware — Intelligent Field Orchestration","tipo":"tercero","categoria":"Orquestación de journey y engagement de campo","ejemplos":["Rallyware"],"nota":"Referencia de mercado en orquestar el onboarding por evento de comportamiento, con next-best-action por vendedor en cada tramo del journey."},{"nombre":"Exigo Core","tipo":"tercero","categoria":"Motor de genealogía/comisiones event-driven","ejemplos":["Exigo"],"nota":"Cuando el journey debe leer y disparar hitos a partir de eventos de volumen en tiempo real, en lugar de batch nocturno."},{"nombre":"Epixel","tipo":"tercero","categoria":"Plataforma de vendedor con módulo de onboarding","ejemplos":["Epixel MLM Software"],"nota":"Aporta plantillas de journey por etapa configurables sin desarrollo a medida, integradas al alta y al volumen."}],"agentesYUseCase":[{"useCase":"Agente supervisado que monitorea el avance de cada nuevo vendedor por el journey, detecta a quienes van rezagados respecto a un hito y propone la next-best-action para recuperarlos.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — señala y propone; el humano o el patrocinador actúa","valor":"convierte el rezago silencioso en una señal actuable antes de que se traduzca en abandono"},{"useCase":"Copiloto que recalibra las metas escalonadas de volumen por tramo con base en los resultados observados de cohortes anteriores, antes de fijar la meta de la siguiente cohorte.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — sugiere el ajuste; el humano decide","valor":"evita que las metas por tramo se mantengan fijas por inercia sin evidencia de que siguen siendo las correctas"},{"useCase":"Orquestación de next-best-action por vendedor a lo largo de todo el journey, integrada con señales de comportamiento comercial y disparada de forma continua.","tipo":"tercero","nivelAutonomia":"multi-agente (nivel 4) — coordina y prioriza intervenciones 24/7","ejemplos":["Rallyware Intelligent Field Orchestration"],"valor":"escala el acompañamiento personalizado a todas las cohortes sin depender de la disponibilidad humana"}],"metadata":{"evidenciaEsperada":"Playbook vigente del journey 0-90 días con los hitos a día 1/7/30/60/90, el responsable de cada hito y las metas escalonadas de volumen por tramo, más evidencia de su aplicación en las últimas cohortes de altas.","dolorAsociado":"Onboarding informal dependiente del patrocinador que deja al nuevo vendedor sin ruta ni metas en el tramo de mayor abandono; sin hitos estructurados el cliff del primer trimestre se sufre en lugar de gestionarse.","frenteRecomendacion":"Eficiencia/Simplificación de Proceso","fuente":"MASTER-C01 §2 (Onboarding 30-60-90: primeros 90 días como tramo de mayor riesgo de abandono; check-ins estructurados, metas escalonadas de PV; playbook formal con responsables y gates a día 1/7/30/60/90 vs. proceso informal dependiente del patrocinador), §4.2.6 (onboarding como flujo orquestado por evento de comportamiento), §10 (Playbook de onboarding 30-60-90 formalizado con responsables y gates automatizados por día)"},"camposFaltantes":[]},{"practiceId":"C01-05-PR-02","processId":"C01","temaId":"c01-onboarding-y-habilitacion-temprana","nombre":"Habilitación temprana en producto y en el plan de compensación","pregunta":"¿El nuevo vendedor recibe en las primeras semanas una formación estructurada en producto y en el funcionamiento del plan de compensación, en lugar de aprender por ensayo y error según lo que sepa su patrocinador?","enunciado":"La organización habilita al nuevo vendedor en las primeras semanas con una formación estructurada sobre el producto (uso, beneficios y demostración) y sobre cómo funciona realmente el plan de compensación (volumen, rangos y cómo 
1se generan las ganancias), de modo que la persona pueda vender con criterio y entienda qué esperar de su esfuerzo. La formación es un currículo definido con contenido y momento pautados, en lugar de un aprendizaje por ensayo y error que depende de lo que sepa transmitir el patrocinador que lo reclutó.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin formación temprana; el nuevo vendedor no recibe capacitación de producto ni de plan de compensación al iniciar."},{"nivel":1,"ancla":"1 Formación informal y variable, transmitida de boca en boca por el patrocinador según su propio conocimiento."},{"nivel":2,"ancla":"2 Existen materiales de producto y de plan de compensación, entregados de forma parcial y sin momento ni secuencia definidos."},{"nivel":3,"ancla":"3 Currículo de habilitación temprana en producto y plan de compensación definido, con contenido, secuencia y momento pautados en el journey."},{"nivel":4,"ancla":"4 Habilitación gestionada; se mide la finalización y la comprensión de los módulos por cohorte y se corrige lo que no se completa."},{"nivel":5,"ancla":"5 Ningún módulo o secuencia de habilitación permanece vigente sin una revisión documentada contra la venta o activación temprana real de la cohorte que lo completó."}]},"sistemas":{"referenciaMp":"§5 (LMS/habilitación como capa de la pila tecnológica), §2 (formación en producto y en plan de compensación como parte del onboarding)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; no hay repositorio ni entrega estructurada de la formación de producto y plan de compensación."},{"nivel":1,"ancla":"1 Materiales sueltos (documentos, videos) compartidos por correo o chat, sin seguimiento de quién los consumió."},{"nivel":2,"ancla":"2 Plataforma de formación especializada con los módulos de producto y comp plan, desconectada del journey y del volumen."},{"nivel":3,"ancla":"3 Formación integrada al journey de onboarding, con módulos disparados por hito y registro de finalización por vendedor."},{"nivel":4,"ancla":"4 Plataforma que expone en tiempo real el avance de habilitación por cohorte y adapta los módulos al perfil y al idioma/país."},{"nivel":5,"ancla":"5 Ecosistema donde formación, journey, volumen y comisión fluyen sin transferencias manuales para recalibrar el currículo."}]},"agentico":{"referenciaMp":"§6 (chatbots que guían al nuevo vendedor por comp plan y producto sin humano)","anclas":[{"nivel":0,"ancla":"0 Sin IA; toda duda de producto o de plan de compensación se resuelve manualmente con el patrocinador."},{"nivel":1,"ancla":"1 Respuestas puntuales a preguntas de producto o comp plan generadas bajo demanda por IA generativa."},{"nivel":2,"ancla":"2 Copiloto conversacional que guía al nuevo vendedor por el producto y el plan de compensación y arma resúmenes a su medida."},{"nivel":3,"ancla":"3 Agente supervisado que personaliza la ruta de formación según los vacíos detectados y verifica la comprensión por módulo."},{"nivel":4,"ancla":"4 Agentes que coordinan la habilitación con las señales de comportamiento comercial y priorizan el refuerzo donde más impacta."},{"nivel":5,"ancla":"5 Habilitación autónoma dentro de políticas que ajusta contenido y secuencia según los resultados de venta y activación, con escalamiento por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Habilitación/LMS integrada al journey","tipo":"S4DS","categoria":"Formación de producto y plan de compensación","coberturaS4DS":"módulo Habilitación · currículo por hito del journey · MCP training/enablement tools","nota":"Dispara los módulos de producto y comp plan por hito del journey y registra finalización y comprensión por vendedor y por cohorte."},{"nombre":"LMS especializado en formación de fuerza de ventas","tipo":"tercero","categoria":"Learning Management System","ejemplos":["Docebo","Absorb LMS","TalentLMS"],"nota":"Cuando el catálogo de contenido de producto y comp plan requiere un LMS de propósito general con reporting de finalización por cohorte."},{"nombre":"Rallyware","tipo":"tercero","categoria":"Plataforma de habilitación específica de venta directa","ejemplos":["Rallyware"],"nota":"Referencia de mercado en habilitación adaptada al journey de onboarding, con contenido disparado por comportamiento."},{"nombre":"Epixel","tipo":"tercero","categoria":"Módulo de formación de producto y comp plan","ejemplos":["Epixel MLM Software"],"nota":"Chatbots que guían al nuevo vendedor por producto y plan de compensación sin intervención humana constante."}],"agentesYUseCase":[{"useCase":"Respuestas puntuales a preguntas de producto o de plan de compensación generadas bajo demanda por IA generativa, sin flujo estructurado detrás.","tipo":"tercero","nivelAutonomia":"asistido (nivel 1) — responde bajo demanda, sin orquestación de journey","ejemplos":["chatbots de FAQ con GenAI"],"valor":"reduce el tiempo de espera para dudas simples de producto o comp plan fuera de horario del patrocinador"},{"useCase":"Copiloto conversacional que guía al nuevo vendedor por el producto y el plan de compensación y arma resúmenes a su medida según su perfil y su idioma.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — guía y resume; el humano decide qué profundizar","valor":"escala la habilitación de primer nivel sin depender de la disponibilidad ni del conocimiento del patrocinador"},{"useCase":"Agente supervisado que personaliza la ruta de formación según los vacíos de comprensión detectados en cada módulo y verifica que la comprensión —no solo la finalización— ocurrió.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — personaliza y verifica; escala dudas complejas a humano","valor":"evita que la 'finalización' del módulo sea un checkbox vacío de comprensión real"}],"metadata":{"evidenciaEsperada":"Currículo de habilitación temprana (módulos de producto y de plan de compensación con su secuencia y momento en el journey) + evidencia de finalización por cohorte de altas.","dolorAsociado":"Nuevo vendedor que no entiende el producto ni cómo se generan sus ganancias y aprende por ensayo y error según lo que sepa su patrocinador; la falta de habilitación temprana alimenta la baja antes de la primera venta.","frenteRecomendacion":"Tecnología e Integración","fuente":"MASTER-C01 §2 (Onboarding 30-60-90: habilitación temprana en producto y plan de compensación), §5 (LMS/habilitación como una de las capas de la pila; onboarding basado en journeys por etapa), §6 (chatbots que guían al nuevo vendedor por políticas, comp plan y producto sin humano; onboarding conversacional como caso más maduro), §9 (Herbalife One unifica pedidos, CRM, entrenamiento y contenido)"},"camposFaltantes":[]},{"practiceId":"C01-05-PR-03","processId":"C01","temaId":"c01-onboarding-y-habilitacion-temprana","nombre":"Formación y certificación temprana en compliance y ética (income claims y P&P)","pregunta":"¿El nuevo vendedor completa y certifica una formación en compliance/ética (income claims, P&P, cooling-off y divulgación) como condición del onboarding, en lugar de asumir que el marketing de campo se autorregula?","enunciado":"La organización forma y certifica al nuevo vendedor, antes de que opere públicamente, en las reglas de venta ética: qué puede y qué no puede afirmar sobre ingresos, las políticas y procedimientos que lo obligan, y los derechos del prospecto como el periodo de reflexión y la divulgación previa. La habilitación en compliance se completa y se registra como una condición del onboarding —una certificación auditable— en lugar de asumir que el marketing de campo se autorregula, cerrando desde el inicio el vector de earnings claims indebidos de la fuerza de ventas.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin formación de compliance; el nuevo vendedor empieza a promocionar sin conocer qué puede o no afirmar ni las P&P que lo obligan."},{"nivel":1,"ancla":"1 Advertencias informales de 'cuidado con lo que prometes', sin contenido estructurado ni registro de haberlo recibido."},{"nivel":2,"ancla":"2 Existe material de compliance/ética, entregado de forma parcial y sin certificación ni control de finalización."},{"nivel":3,"ancla":"3 Formación de compliance definida (income claims, P&P, cooling-off, divulgación) con certificación registrada como condición del onboarding."},{"nivel":4,"ancla":"4 Certificación gestionada como gate de habilitación; se mide la tasa de certificación y se restringe la operación pública de quien no la completa."},{"nivel":5,"ancla":"5 Ningún contenido de certificación de compliance permanece vigente sin una revisión documentada contra los casos de earnings claims detectados en las cohortes ya formadas."}]},"sistemas":{"referenciaMp":"§5 (LMS/habilitación), §8 (income claims: material del vendedor con sustentación documentada), §2 (aceptación auditable y firma separada del IDS)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; no hay registro de quién recibió ni completó formación de compliance."},{"nivel":1,"ancla":"1 Documento de políticas enviado por correo, sin control de lectura ni certificación."},{"nivel":2,"ancla":"2 Plataforma de formación con el módulo de compliance y su examen, desconectada del estado de habilitación del vendedor."},{"nivel":3,"ancla":"3 Certificación de compliance integrada al journey, que registra la finalización y condiciona la habilitación operativa del vendedor."},{"nivel":4,"ancla":"4 Plataforma que expone el estado de certificación en tiempo real y bloquea/habilita la operación pública según ese estado, de forma auditable."},{"nivel":5,"ancla":"5 Ecosistema donde certificación, habilitación, publicación de contenido y compliance gating fluyen encadenados sin reconciliación manual."}]},"agentico":{"referenciaMp":"§6 (riesgo regulatorio de la GenAI en earnings claims; auditar contenido generado)","anclas":[{"nivel":0,"ancla":"0 Sin IA; verificar que el nuevo vendedor entendió las reglas de income claims es manual y esporádico."},{"nivel":1,"ancla":"1 Cuestionario automatizado de compliance corregido por reglas fijas, sin retroalimentación adaptativa."},{"nivel":2,"ancla":"2 Copiloto que resuelve dudas de compliance del nuevo vendedor y marca contenido dudoso para revisión."},{"nivel":3,"ancla":"3 Agente supervisado que evalúa la comprensión de las reglas de income claims/P&P y refuerza los vacíos antes de habilitar."},{"nivel":4,"ancla":"4 Agentes que correlacionan la certificación con el contenido publicado por el vendedor para anticipar riesgo de earnings claims."},{"nivel":5,"ancla":"5 Habilitación de compliance autónoma dentro de políticas, con refuerzo adaptativo y escalamiento de casos límite a revisión humana."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Certificación de Compliance (gate de habilitación)","tipo":"S4DS","categoria":"Compliance gating del onboarding","coberturaS4DS":"módulo Compliance · certificación registrada como condición de habilitación · MCP compliance-gate tools","nota":"Registra la certificación (income claims, P&P, cooling-off, divulgación) y bloquea/habilita la operación pública del vendedor según ese estado."},{"nombre":"LMS de compliance con examen y certificación","tipo":"tercero","categoria":"Learning Management System de compliance regulado","ejemplos":["ComplianceWire","Skillsoft Compliance Solutions"],"nota":"Aporta el examen certificado y el registro de aprobación cuando el volumen regulatorio exige un LMS especializado en compliance, no un LMS comercial genérico."},{"nombre":"DocuSign eSignature","tipo":"tercero","categoria":"Firma electrónica y aceptación auditable","ejemplos":["DocuSign"],"nota":"Certifica con audit trail que la aceptación de la certificación de compliance está vinculada a la versión exacta del material vigente."},{"nombre":"Epixel","tipo":"tercero","categoria":"Módulo de compliance y detección de fraude","ejemplos":["Epixel MLM Software"],"nota":"Módulo de compliance con mayor ritmo público de lanzamientos de IA del vertical en 2025-2026 para marcar contenido dudoso."}],"agentesYUseCase":[{"useCase":"Cuestionario automatizado de compliance corregido por reglas fijas, sin retroalimentación adaptativa según el resultado del vendedor.","tipo":"tercero","nivelAutonomia":"asistido (nivel 1) — 
1corrige, no adapta","ejemplos":["exámenes de LMS con corrección automática"],"valor":"estandariza la corrección del examen de certificación sin depender de revisión manual caso por caso"},{"useCase":"Copiloto que resuelve dudas de compliance del nuevo vendedor durante la formación y marca contenido dudoso (propio o de terceros) para revisión de compliance.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — resuelve y marca; compliance humano revisa","valor":"acerca la duda de compliance al momento en que ocurre, en vez de acumularla para una revisión tardía"},{"useCase":"Agente supervisado que evalúa la comprensión real de las reglas de income claims/P&P —no solo la finalización del módulo— y refuerza los vacíos detectados antes de habilitar la operación pública.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — evalúa y refuerza; humano decide la habilitación final","valor":"eleva el estándar de 'certificado' de haber pasado un examen a haber demostrado comprensión aplicable"},{"useCase":"Agentes que correlacionan el estado de certificación de cada vendedor con el contenido que efectivamente publica (redes, videos, sitios replicados) para anticipar riesgo de earnings claims antes de que escale a un caso de compliance.","tipo":"S4DS","nivelAutonomia":"multi-agente (nivel 4) — correlaciona señales; escala casos límite a revisión humana","valor":"cierra el vector de riesgo entre 'estar certificado' y 'seguir las reglas en la práctica de campo'"}],"metadata":{"evidenciaEsperada":"Módulo de formación de compliance/ética (income claims, P&P, cooling-off, divulgación) + registro de certificación por vendedor mostrando que es condición del onboarding antes de operar públicamente.","dolorAsociado":"Fuerza de ventas que promociona sin formación de compliance y afirma ingresos indebidos; la brecha entre el compliance corporativo y el marketing de campo no oficial es el vector de riesgo más citado en los settlements recientes del sector.","frenteRecomendacion":"Gobierno/Roles/Tercerización","fuente":"MASTER-C01 §2 (Onboarding 30-60-90: formación en compliance; brecha compliance corporativo vs. marketing de campo no oficial; aceptación auditable y firma separada del IDS), §5 (LMS/habilitación), §8.1 (income claims: material generado por el vendedor no debe circular sin flujo de aprobación de compliance con sustentación documentada), §6 (riesgo regulatorio de la GenAI: earnings claims no verificados generados por IA)"},"camposFaltantes":[]},{"practiceId":"C01-05-PR-04","processId":"C01","temaId":"c01-onboarding-y-habilitacion-temprana","nombre":"Programa fast-start: incentivos por hitos tempranos de venta y patrocinio","pregunta":"¿Existe un programa fast-start que premie hitos tempranos genuinos (primera venta, primeros clientes, primer volumen/patrocinio) con incentivos acotados en el tiempo, atados a venta/volumen verificable y no a la compra de inventario?","enunciado":"La organización ofrece un programa de arranque rápido que premia logros genuinos y tempranos —la primera venta a usuario final, los primeros clientes, el primer volumen calificado o el primer patrocinio— con incentivos acotados en el tiempo, diseñados para empujar al nuevo vendedor a cruzar los umbrales de la primera orden y del primer trimestre. Los incentivos se atan a venta o volumen verificable dentro de la ventana temprana, de modo que recompensan la tracción comercial real y no la carga de inventario ni la mera compra del kit.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin programa de arranque; no hay incentivo por los primeros logros y el nuevo vendedor no recibe ningún empuje temprano."},{"nivel":1,"ancla":"1 Incentivos tempranos otorgados de forma ad-hoc y discrecional, sin hitos, montos ni ventana definidos."},{"nivel":2,"ancla":"2 Programa fast-start enunciado con algunos premios, aplicado de forma desigual y sin ligarlo claramente a venta verificable."},{"nivel":3,"ancla":"3 Programa fast-start definido: hitos tempranos, incentivo y ventana temporal explícitos, atados a venta/volumen verificable y no a compra de kit."},{"nivel":4,"ancla":"4 Programa gestionado; se mide qué proporción de nuevas altas alcanza cada hito y el efecto del incentivo sobre la activación temprana, contra objetivos."},{"nivel":5,"ancla":"5 Ningún hito, monto o ventana del programa fast-start permanece vigente sin una revisión documentada contra su impacto medido en activación y retención al primer trimestre."}]},"sistemas":{"referenciaMp":"§4 (2.5 evento de primera calificación PV/autoship que dispara el sponsor bonus, versionado), §2 (bonos de fast start por hitos tempranos)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; los incentivos de arranque, si existen, se calculan y pagan a mano sin trazabilidad."},{"nivel":1,"ancla":"1 Seguimiento del fast-start en hoja de cálculo, con el hito y el premio verificados manualmente."},{"nivel":2,"ancla":"2 Reporte especializado de hitos tempranos, desconectado del motor de comisiones y de la definición de activación."},{"nivel":3,"ancla":"3 Reglas de fast-start integradas al motor de comisiones que disparan el incentivo con el evento de venta/volumen verificable."},{"nivel":4,"ancla":"4 Plataforma que evalúa en tiempo real el cumplimiento de cada hito y habilita el incentivo solo con el evento verificable, de forma auditable."},{"nivel":5,"ancla":"5 Ecosistema donde venta, volumen, hito y liquidación del incentivo operan como eventos encadenados sin intervención manual."}]},"agentico":{"referenciaMp":"§6 (next-best-action por vendedor; onboarding conversacional para empujar hitos tempranos)","anclas":[{"nivel":0,"ancla":"0 Sin IA; nadie proyecta quién está cerca de un hito de fast-start ni qué acción lo acercaría."},{"nivel":1,"ancla":"1 Alertas simples cuando un nuevo vendedor se acerca a la fecha límite de un hito de fast-start."},{"nivel":2,"ancla":"2 Copiloto que muestra al nuevo vendedor qué le falta para el próximo hito y sug
1iere cómo alcanzarlo."},{"nivel":3,"ancla":"3 Agente supervisado que proyecta la probabilidad de alcanzar cada hito y propone la next-best-action a quienes van rezagados."},{"nivel":4,"ancla":"4 Agentes que combinan comportamiento, volumen y perfil para priorizar el empuje hacia los hitos de arranque de forma coordinada."},{"nivel":5,"ancla":"5 Empuje autónomo dentro de políticas hacia los hitos de fast-start, que ajusta la estrategia con los resultados y escala excepciones."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Reglas de Fast-Start en el Motor de Comisiones","tipo":"S4DS","categoria":"Motor de comisiones / reglas de incentivo temprano","coberturaS4DS":"módulo Comisiones · reglas de fast-start disparadas por evento de venta/volumen verificable · MCP commission-rules tools","nota":"Liga el incentivo de fast-start a la primera calificación de PV/autoship como evento versionado, no a la compra del kit."},{"nombre":"Exigo","tipo":"tercero","categoria":"Motor de comisiones configurable","ejemplos":["Exigo"],"nota":"Configura bonos de fast-start como reglas del motor de comisiones con hand-off event-driven desde el evento de calificación."},{"nombre":"DirectScale","tipo":"tercero","categoria":"Modelado de escenarios de plan de compensación","ejemplos":["DirectScale"],"nota":"Permite simular el impacto de distintos montos y ventanas de fast-start antes de comprometerlos con toda la fuerza de ventas."},{"nombre":"Epixel","tipo":"tercero","categoria":"Reglas de fast-start integradas al motor","ejemplos":["Epixel MLM Software"],"nota":"Integra las reglas de fast-start al motor de comisiones y a la definición de activación evitando el cálculo manual."}],"agentesYUseCase":[{"useCase":"Alertas simples cuando un nuevo vendedor se acerca a la fecha límite de un hito de fast-start sin haberlo alcanzado todavía.","tipo":"S4DS","nivelAutonomia":"asistido (nivel 1) — alerta por regla fija","valor":"evita que un hito próximo a vencer pase inadvertido para el vendedor o su patrocinador"},{"useCase":"Copiloto que muestra al nuevo vendedor qué le falta exactamente para el próximo hito de fast-start y sugiere cómo alcanzarlo con la venta o el volumen faltante.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — sugiere; el vendedor decide la acción","valor":"traduce el hito abstracto en una acción concreta y alcanzable en el tiempo que queda"},{"useCase":"Agente supervisado que proyecta la probabilidad de que cada nuevo vendedor alcance cada hito de fast-start y propone la next-best-action a quienes van rezagados.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — proyecta y propone; humano o patrocinador ejecuta","valor":"concentra el esfuerzo de empuje donde el incentivo aún puede cambiar el resultado"},{"useCase":"Orquestación de next-best-action por vendedor combinando comportamiento, volumen y perfil para priorizar el empuje hacia los hitos de arranque de forma coordinada.","tipo":"tercero","nivelAutonomia":"multi-agente (nivel 4) — coordina prioridades de empuje 24/7","ejemplos":["Rallyware Intelligent Field Orchestration"],"valor":"escala el empuje personalizado del fast-start a toda cohorte sin intervención manual caso por caso"}],"metadata":{"evidenciaEsperada":"Definición vigente del programa fast-start (hitos, incentivo, ventana temporal) + evidencia de que los incentivos se disparan por venta/volumen verificable y no por compra de kit, con la proporción de altas que alcanza cada hito.","dolorAsociado":"Ausencia de empuje temprano —la mayoría de las bajas ocurre antes de la primera orden— o un fast-start atado a la compra de inventario que alimenta el inventory-loading en vez de la venta genuina.","frenteRecomendacion":"Tecnología e Integración","fuente":"MASTER-C01 §2 (Onboarding 30-60-90: bonos de fast start por hitos tempranos; metas escalonadas de PV), §4.2.5 (el evento de primera calificación PV/autoship dispara el sponsor bonus; hand-off versionado al motor de comisiones), §7 (Time-to-first-order como KPI de cabecera: la mayoría de las bajas ocurre antes de la primera orden), §6 (next-best-action por vendedor)"},"camposFaltantes":[]},{"practiceId":"C01-05-PR-05","processId":"C01","temaId":"c01-onboarding-y-habilitacion-temprana","nombre":"Mentoría del sponsor/upline con asignación, cadencia de check-ins y responsabilidad explícita","pregunta":"¿La mentoría del sponsor/upline es una responsabilidad estructurada —con mentor asignado desde el alta, cadencia de check-ins alineada a los hitos y responsabilidad explícita— en lugar de depender de la buena voluntad del patrocinador?","enunciado":"La organización trata la mentoría del upline sobre el nuevo vendedor como una responsabilidad estructurada y no como una cortesía voluntaria: se asigna un mentor desde el enrolamiento, se define una cadencia de check-ins alineada con los hitos del journey (día 1, 7, 30, 60 y 90) y la responsabilidad del patrocinador por el acompañamiento temprano queda explícita y es exigible. Así el apoyo en el tramo crítico no depen
1de de qué patrocinador reclutó a la persona ni de su buena voluntad, sino de un compromiso de acompañamiento asignado, con cadencia y responsable definidos.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin mentoría definida; el acompañamiento del nuevo vendedor no es responsabilidad de nadie en particular."},{"nivel":1,"ancla":"1 Acompañamiento informal que depende de la buena voluntad del patrocinador; sin asignación, cadencia ni responsabilidad exigible."},{"nivel":2,"ancla":"2 Se espera que el patrocinador acompañe, pero sin cadencia de check-ins definida ni registro de que ocurran."},{"nivel":3,"ancla":"3 Mentoría definida: mentor asignado desde el alta, cadencia de check-ins alineada a los hitos y responsabilidad del patrocinador explícita."},{"nivel":4,"ancla":"4 Mentoría gestionada; se registran los check-ins realizados y se mide la adherencia a la cadencia y su efecto en la activación temprana."},{"nivel":5,"ancla":"5 Ninguna cadencia de mentoría permanece vigente sin una revisión documentada contra la correlación real entre check-ins cumplidos y retención al primer trimestre."}]},"sistemas":{"referenciaMp":"§3 (RACI: patrocinador en originación/acompañamiento, corporate y sistema como responsables del onboarding), §2 (check-ins estructurados del sponsor)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; no hay registro de la asignación de mentor ni de los check-ins realizados."},{"nivel":1,"ancla":"1 Asignación y contactos anotados en hoja de cálculo o chat, sin cadencia ni trazabilidad."},{"nivel":2,"ancla":"2 Herramienta especializada que registra la relación mentor-aprendiz y agenda contactos, desconectada del journey y del avance."},{"nivel":3,"ancla":"3 Mentoría integrada al journey: asignación registrada y check-ins programados por hito, con el estado del acompañamiento consultable."},{"nivel":4,"ancla":"4 Plataforma que expone en tiempo real la adherencia a la cadencia de check-ins y alerta al upline cuando un aprendiz queda sin contacto."},{"nivel":5,"ancla":"5 Ecosistema donde asignación, check-ins, avance del journey y señales de riesgo fluyen sin transferencias manuales para dirigir el acompañamiento."}]},"agentico":{"referenciaMp":"§6 (coaching asistido; next-best-action que apoya al sponsor en el acompañamiento)","anclas":[{"nivel":0,"ancla":"0 Sin IA; el patrocinador decide sin apoyo a quién contactar, cuándo y sobre qué."},{"nivel":1,"ancla":"1 Recordatorios automáticos al patrocinador de los check-ins pendientes por fecha."},{"nivel":2,"ancla":"2 Copiloto que prepara al patrocinador cada check-in con el contexto y los puntos a tratar del aprendiz."},{"nivel":3,"ancla":"3 Agente supervisado que prioriza a qué aprendiz atender primero y propone la next-best-action de acompañamiento al patrocinador."},{"nivel":4,"ancla":"4 Agentes que coordinan las señales de riesgo del aprendiz con la agenda de acompañamiento del upline de forma priorizada 24/7."},{"nivel":5,"ancla":"5 Coaching autónomo dentro de políticas que dispara y ajusta el acompañamiento del upline según resultados, con escalamiento por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Mentoría y Check-ins (asignación + cadencia + trazabilidad)","tipo":"S4DS","categoria":"Gestión de mentoría del onboarding","coberturaS4DS":"módulo Onboarding · asignación de mentor desde el alta · cadencia de check-ins por hito · MCP mentorship tools","nota":"Registra la asignación mentor-aprendiz, programa los check-ins por hito y exp
1one la adherencia a la cadencia de forma auditable."},{"nombre":"Rallyware","tipo":"tercero","categoria":"Coaching y engagement del upline","ejemplos":["Rallyware"],"nota":"Referencia de mercado en apoyar al patrocinador con contexto y agenda de acompañamiento del aprendiz."},{"nombre":"Exigo / Epixel","tipo":"tercero","categoria":"CRM de vendedor con seguimiento de la relación mentor-aprendiz","ejemplos":["Exigo","Epixel MLM Software"],"nota":"Registran la relación sponsor-aprendiz y el histórico de contactos dentro de la misma plataforma donde vive el journey y el volumen."}],"agentesYUseCase":[{"useCase":"Recordatorios automáticos al patrocinador de los check-ins pendientes por fecha, sin contexto adicional del aprendiz.","tipo":"S4DS","nivelAutonomia":"asistido (nivel 1) — recuerda por fecha","valor":"reduce el olvido operativo del check-in sin depender de que el patrocinador lo recuerde por su cuenta"},{"useCase":"Copiloto que prepara al patrocinador cada check-in con el contexto y los puntos a tratar del aprendiz —avance en el journey, módulos pendientes, señales de riesgo—.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — prepara el contexto; el patrocinador conduce la conversación","valor":"eleva la calidad del check-in de una llamada genérica a una conversación informada"},{"useCase":"Agente supervisado que prioriza a qué aprendiz atender primero entre todos los que mentorea un patrocinador y propone la next-best-action de acompañamiento.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — prioriza y propone; el patrocinador ejecuta","valor":"evita que un aprendiz en riesgo se pierda entre varios aprendices simultáneos del mismo upline"},{"useCase":"Agentes que coordinan las señales de riesgo del aprendiz con la agenda de acompañamiento del upline de forma priorizada y continua.","tipo":"tercero","nivelAutonomia":"multi-agente (nivel 4) — coordina agenda y riesgo 24/7","ejemplos":["plataformas de coaching asistido por IA aplicadas a venta directa"],"valor":"sostiene el acompañamiento priorizado incluso cuando el patrocinador mentorea a muchos aprendices a la vez"}],"metadata":{"evidenciaEsperada":"Definición de la mentoría (asignación de mentor desde el alta, cadencia de check-ins por hito, responsabilidad del patrocinador) + registro de check-ins realizados en las últimas cohortes de altas.","dolorAsociado":"Acompañamiento que depende de la buena voluntad y del conocimiento del patrocinador que reclutó; sin mentor asignado, cadencia ni responsabilidad exigible, el nuevo vendedor queda solo en el tramo de mayor abandono.","frenteRecomendacion":"Gobierno/Roles/Tercerización","fuente":"MASTER-C01 §2 (Onboarding 30-60-90: check-ins estructurados del sponsor; madurez = playbook con responsables patrocinador/corporate/sistema vs. proceso informal dependiente del patrocinador), §3 (RACI por etapa: Sponsor en originación y acompañamiento, Field Ops y corporate como responsables), §6 (coaching y next-best-action que apoyan al patrocinador)"},"camposFaltantes":[]},{"practiceId":"C01-05-PR-06","processId":"C01","temaId":"c01-onboarding-y-habilitacion-temprana","nombre":"Gates automatizados y medición del cliff 0-90 días con intervención ante riesgo de abandono","pregunta":"¿Medimos el avance del onboarding con indicadores tempranos (TTFO, primera venta, reorder, retención 30/60/90) y convertimos cada hito en un gate que dispara comunicación e intervención ante el riesgo de abandono, en lugar de medir la deserción retrospectivamente?","enunciado":"La organización mide el avance por el journey con indicadores tempranos —tiempo hasta la primera orden, primera venta en las primeras horas, primer reorder y retención a 30/60/90 días— y convierte cada hito en un gate que dispara la comunicación y la habilitación oportunas y, cuando un nuevo vendedor se queda atrás, una intervención temprana. Así el abandono del primer trimestre se detecta y se actúa antes de que se consume como baja, en lugar de medir la deserción de forma retrospectiva y agregada cuando ya no hay margen para recuperar a la persona.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin medición del avance ni gates;
1 el abandono del primer trimestre se descubre tarde, cuando la persona ya dejó de operar."},{"nivel":1,"ancla":"1 Se revisa la deserción de forma esporádica y retrospectiva, sin indicadores tempranos ni intervención definida."},{"nivel":2,"ancla":"2 Se miden algunos indicadores del onboarding, pero no disparan gates ni intervención consistente ante el rezago."},{"nivel":3,"ancla":"3 Indicadores tempranos definidos (TTFO, primera venta, reorder, retención 30/60/90) con gates por hito que disparan comunicación e intervención documentada."},{"nivel":4,"ancla":"4 Gestionado; se mide el cliff por cohorte y la efectividad de las intervenciones contra objetivos, y se corrige lo que no funciona."},{"nivel":5,"ancla":"5 Ningún umbral de riesgo o intervención de retención permanece vigente sin una revisión documentada contra su impacto medido en la retención al primer trimestre."}]},"sistemas":{"referenciaMp":"§7 (retención 30/60/90, TTFO, primer reorder como leading indicators; ventana configurable y auditable), §4 (2.6 onboarding como flujo orquestado por evento de comportamiento)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; no hay forma de calcular los indicadores tempranos ni de saber quién está en riesgo de abandonar."},{"nivel":1,"ancla":"1 Cálculo manual de la deserción en hoja de cálculo, después del hecho y sin disparadores."},{"nivel":2,"ancla":"2 Reporte especializado de retención temprana, desconectado del journey y sin gates que actúen sobre el rezago."},{"nivel":3,"ancla":"3 Indicadores tempranos calculados en la plataforma de vendedores, con gates por hito que disparan la comunicación/habilitación e integran la intervención."},{"nivel":4,"ancla":"4 Plataforma que evalúa los leading indicators en tiempo real y activa gates e intervenciones ante el riesgo de abandono, de forma auditable."},{"nivel":5,"ancla":"5 Ecosistema donde comportamiento, indicadores, gates e intervenciones fluyen encadenados sin transferencias manuales de extremo a extremo."}]},"agentico":{"referenciaMp":"§6 (predicción de churn + next-best-action, caso de uso mejor documentado del vertical), §8 (leading indicators de churn como triggers de intervención)","anclas":[{"nivel":0,"ancla":"0 Sin IA; identificar a quién va a abandonar en su primer trimestre es manual y tardío."},{"nivel":1,"ancla":"1 Alertas por regla fija cuando un indicador temprano cruza un umbral (p. ej. sin primera orden a las 72h)."},{"nivel":2,"ancla":"2 Copiloto que prioriza a los nuevos vendedores en riesgo de abandono para seguimiento."},{"nivel":3,"ancla":"3 Agente supervisado que predice el riesgo de abandono con los leading indicators y propone la next-best-action de intervención."},{"nivel":4,"ancla":"4 Agentes que combinan predicción de churn con las intervenciones de onboarding y las ejecutan de forma coordinada y priorizada 24/7."},{"nivel":5,"ancla":"5 Intervención autónoma dentro de políticas ante el riesgo de abandono, que ajusta la estrategia con los resultados y escala excepciones."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Leading Indicators y Gates de Onboarding","tipo":"S4DS","categoria":"Analítica de retención temprana / gates de intervención","coberturaS4DS":"módulo Onboarding · TTFO, primera venta 72h, primer reorder, retención 30/60/90 · MCP churn-gate tools","nota":"Calcula los leading indicators en tiempo real, dispara el gate de comunicación/intervención y deja auditable la ventana rolling configurable."},{"nombre":"Exigo AI","tipo":"tercero","categoria":"Detección de anomalías de comportamiento comercial","ejemplos":["Exigo AI"],"nota":"Marca anomalías como progresión de rango estancada o autoships perdidos semanas antes del churn, con evidencia independiente reportada por el proveedor."},{"nombre":"Rallyware","tipo":"tercero","categoria":"Predicción de churn + next-best-action","ejemplos":["Rallyware"],"nota":"Caso de uso mejor documentado del vertical: predicción de churn temprano acoplada a la intervención de onboarding correspondiente."},{"nombre":"BI / analítica de cohortes","tipo":"tercero","categoria":"Reporte del cliff por cohorte","ejemplos":["Power BI","Tableau"],"nota":"Para el reporte gerencial del cliff por cohorte y de la efectividad de las intervenciones contra objetivos, más allá del disparador operativo."}],"agentesYUseCase":[{"useCase":"Alertas por regla fija cuando un indicador temprano cruza un umbral definido, por ejemplo sin primera orden a las 72 horas de la inscripción.","tipo":"S4DS","nivelAutonomia":"asistido (nivel 1) — alerta por umbral fijo","valor":"instrumenta el primer nivel de detección temprana sin requerir un modelo predictivo"},{"useCase":"Copiloto que prioriza a los nuevos vendedores en riesgo de abandono para seguimiento humano, ordenados por severi
1dad del rezago.","tipo":"tercero","nivelAutonomia":"copiloto (nivel 2) — prioriza; humano hace el seguimiento","ejemplos":["Exigo AI","Rallyware"],"valor":"concentra el esfuerzo de seguimiento donde el riesgo de abandono es más alto"},{"useCase":"Agente supervisado que predice el riesgo de abandono combinando los leading indicators disponibles y propone la next-best-action de intervención específica para cada caso.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — predice y propone; humano ejecuta o aprueba","valor":"convierte la predicción de churn en una acción concreta, no solo en un score de riesgo"},{"useCase":"Agentes que combinan la predicción de churn con las intervenciones de onboarding disponibles y las ejecutan de forma coordinada y priorizada de manera continua.","tipo":"S4DS","nivelAutonomia":"multi-agente (nivel 4) — ejecuta intervenciones coordinadas 24/7","valor":"cierra el lazo completo entre detección y acción sin esperar a un ciclo de revisión manual"}],"metadata":{"evidenciaEsperada":"Definición de los leading indicators del onboarding (TTFO, primera venta, reorder, retención 30/60/90) y de los gates por hito con su intervención asociada, más el reporte del cliff por cohorte y la efectividad de las intervenciones.","dolorAsociado":"Plataformas que instrumentan la deserción de forma retrospectiva y agregada en vez de leading indicators como triggers: 70-80% de altas sin segunda acción y más del 50% de bajas en las primeras 13 semanas se detectan cuando ya no hay margen de recuperación.","frenteRecomendacion":"Modelos Agénticos/IA","fuente":"MASTER-C01 §2 (Onboarding 30-60-90: gates automatizados a día 1/7/30/60/90; el cliff del nuevo vendedor en el primer trimestre), §4.2.6 (onboarding como flujo orquestado por evento de comportamiento), §7 (retención 30/60/90, TTFO, primer reorder como leading indicators; ventana rolling configurable y auditable), §8.4 (churn temprano: leading indicators —primera venta a 72h, primer reorder— 
1como triggers de intervención, no attrition retrospectiva agregada), §6 (predicción de churn + next-best-action como caso mejor documentado)"},"camposFaltantes":[]},{"practiceId":"C01-06-PR-01","processId":"C01","temaId":"c01-estados-y-ciclo-de-vida","nombre":"Máquina de estados del vendedor explícita, documentada y con transiciones válidas","pregunta":"¿El ciclo de vida en régimen del vendedor está modelado como una máquina de estados explícita y documentada —estados activo/inactivo/suspendido/terminado/reactivado y transiciones válidas entre ellos— en lugar de un campo de estatus que cada área interpreta a su manera?","enunciado":"La organización modela el ciclo de vida en régimen del vendedor como una máquina de estados explícita —con estados definidos (activo, inactivo, suspendido, terminado, reactivado) y las transiciones válidas entre ellos—, documentada y comunicada, en lugar de un campo de estatus que cada área interpreta de forma distinta. Cada estado tiene un significado explícito y las transiciones permitidas (y las prohibidas) están enumeradas, de modo que la situación de un vendedor en cualquier momento es inequívoca y la misma para toda la organización.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 No hay máquina de estados; el estatus del vendedor es un campo suelto que cada área interpreta a su manera y sin transiciones definidas."},{"nivel":1,"ancla":"1 Existen estados informales conocidos por algunas personas, sin definición escrita de cuáles son ni de qué transición es válida."},{"nivel":2,"ancla":"2 Algunos estados están descritos de forma parcial e inconsistente; las transiciones válidas no están enumeradas y varían según quién las aplique."},{"nivel":3,"ancla":"3 Máquina de estados definida y documentada: estados (activo/inactivo/suspendido/terminado/reactivado) y transiciones válidas entre ellos, comunicada a las áreas."},{"nivel":4,"ancla":"4 Máquina de estados gestionada; se mide la consistencia de los estados y se detectan y corrigen las transiciones fuera de las reglas definidas."},{"nivel":5,"ancla":"5 Ningún estado o transición del catálogo permanece vigente sin una revisión documentada contra los casos límite y excepciones observados en el periodo anterior."}]},"sistemas":{"referenciaMp":"§2 (máquina de estados explícita Prospecto→Inscrito/Pendiente-KYC→Activo→Inactivo→Suspendido→Terminado→Reactivado), §10 (máquina de estados event-driven)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; los estados, si existen, se llevan en notas o correos sin un modelo que restrinja las transiciones."},{"nivel":1,"ancla":"1 Estados registrados en una hoja de cálculo o campo libre, editable a mano y sin control de qué transición es válida."},{"nivel":2,"ancla":"2 Herramienta especializada que registra el estado del vendedor, pero sin modelar las transiciones válidas ni impedir saltos inválidos."},{"nivel":3,"ancla":"3 Máquina de estados configurada en la plataforma de vendedores que solo permite las transiciones válidas definidas."},{"nivel":4,"ancla":"4 Plataforma que expone el estado y su historial de transiciones en tiempo real y bloquea de forma auditable cualquier transición no permitida."},{"nivel":5,"ancla":"5 Ecosistema donde el estado y sus transiciones válidas se aplican de extremo a extremo sin edición manual entre capas."}]},"agentico":{"referenciaMp":"§6 (detección de anomalías sobre el ciclo de vida; next-best-action por vendedor)","anclas":[{"nivel":0,"ancla":"0 Sin IA; nadie anticipa qué vendedores están por cambiar de estado ni detecta transiciones anómalas."},{"nivel":1,"ancla":"1 Alertas por regla fija cuando un vendedor cumple una condición simple de cambio de estado."},{"nivel":2,"ancla":"2 Copiloto que responde en qué estado está un vendedor y qué transiciones tiene disponibles."},{"nivel":3,"ancla":"3 Agente supervisado que proyecta qué vendedores se acercan a un cambio de estado y señala transiciones inconsistentes para revisión."},{"nivel":4,"ancla":"4 Agentes que monitorean el ciclo de vida completo y correlacionan señales para anticipar cambios de estado de forma coordinada 24/7."},{"nivel":5,"ancla":"5 Orquestación autónoma dentro de políticas que anticipa y propone cambios de estado según el comportamiento, con escalamiento por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Motor de Estados del Vendedor (máquina de estados explícita)","tipo":"S4DS","categoria":"Ciclo de vida y estados del CRM transaccional","coberturaS4DS":"módulo Ciclo de Vida · catálogo de estados y matriz de transiciones válidas configurable · MCP lifecycle/state tools","nota":"Modela el ciclo de vida como máquina de estados explícita con transiciones permitidas y prohibidas enumeradas, consultable por todas las áreas."},{"nombre":"DMS / plataforma de gestión de vendedores (MLM software)","tipo":"tercero","categoria":"Distributor Management System","ejemplos":["Exigo","DirectScale","ByDesign (Freedom)","Epixel"],"nota":"Plataformas núcleo del sector que suelen incluir un modelo de estados del vendedor configurable como parte del motor de comisiones y genealogía."},{"nombre":"Motor de orquestación de estados / BPM-workflow engine","tipo":"tercero","categoria":"Motor de state machine / orquestación de procesos","ejemplos":["Camunda","AWS Step Functions","Temporal"],"nota":"Para implementar la máquina de estados como componente técnico explícito con transiciones versionadas, cuando el DMS no la modela nativamente con ese rigor."}],"agentesYUseCase":[{"useCase":"Copiloto de estado: responde en qué estado está un vendedor y qué transiciones tiene disponibles desde ahí.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — responde a pedido, no actúa","valor":"reduce el tiempo de soporte de campo y evita que el sponsor o el back-office adivinen el estado"},{"useCase":"Agente supervisado de integridad de transiciones: monitorea los cambios de estado aplicad
1os y señala aquellos que no corresponden a una transición enumerada en la matriz.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — detecta y reporta; el humano corrige","valor":"convierte la matriz de transiciones de un documento en un control activo que detecta violaciones antes de que se propaguen"},{"useCase":"Detección de anomalías de compliance sobre el ciclo de vida (módulo de IA de compliance de plataformas DMS).","tipo":"tercero","nivelAutonomia":"agente supervisado (nivel 3)","ejemplos":["Epixel AI compliance & fraud detection module"],"valor":"añade una capa de detección específica de patrones de estado atípicos más allá de las reglas fijas"}],"metadata":{"evidenciaEsperada":"Documento de la máquina de estados vigente (estados activo/inactivo/suspendido/terminado/reactivado y el diagrama o matriz de transiciones válidas) más evidencia de su aplicación consistente en la operación.","dolorAsociado":"Estatus del vendedor como campo suelto que cada área interpreta distinto y sin transiciones definidas; sin una máquina de estados explícita conviven versiones contradictorias del mismo vendedor y las transiciones inválidas pasan inadvertidas.","frenteRecomendacion":"Eficiencia/Simplificación de Proceso","fuente":"MASTER-C01 §2 (Máquina de estados y offboarding: el ciclo se modela como máquina de estados explícita Prospecto→Inscrito/Pendiente-KYC→Activo→Inactivo→Suspendido→Terminado→Reactivado, con transiciones por volumen (PV/BV), pagos de renovación y flags de compliance), §10 (mediano plazo: máquina de estados event-driven con estados Prospecto→Activo→Inactivo→Suspendido→Terminado→Reactivado)"},"camposFaltantes":[]},{"practiceId":"C01-06-PR-02","processId":"C01","temaId":"c01-estados-y-ciclo-de-vida","nombre":"Reglas de calificación de estado: umbrales de inactividad/suspensión y criterios de reactivación","pregunta":"¿Están definidas y documentadas las reglas que califican a un vendedor en cada estado —qué umbral de volumen o ventana lleva a inactivo, qué evento de compliance lleva a suspendido y qué criterios permiten la reactivación— en lugar de decidirlo caso por caso?","enunciado":"La organización define reglas explícitas y documentadas de qué califica a un vendedor en cada estado —qué umbral de volumen o ventana transcurrida lleva a inactivo, qué evento de compliance o infracción lleva a suspendido, y qué criterios (volumen recuperado, subsanación de la causa) permiten la reactivación—, en lugar de decidirlo caso por caso. Las reglas se expresan con umbrales y ventanas configurables y auditables, de modo que la misma situación produce siempre el mismo estado y la calificación no depende del criterio de quien la tramite.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin reglas de calificación de estado; que un vendedor pase a inactivo o suspendido se decide caso por caso sin criterio definido."},{"nivel":1,"ancla":"1 Criterios implícitos conocidos por algunas personas, aplicados de forma inconsistente y sin documentar."},{"nivel":2,"ancla":"2 Algunas reglas escritas (p. ej. un umbral de inactividad), pero incompletas y sin criterios claros de suspensión ni de reactivación."},{"nivel":3,"ancla":"3 Reglas de calificación definidas y documentadas: umbral/ventana para inactivo, evento de compliance para suspendido y criterios de reactivación explícitos."},{"nivel":4,"ancla":"4 Reglas gestionadas; los umbrales y ventanas son configurables y auditables, y se mide su aplicación consistente frente a las excepciones."},{"nivel":5,"ancla":"5 Ningún umbral de estado o criterio de reactivación permanece vigente sin una revisión documentada contra su correlación real con la retención y el comportamiento observado."}]},"sistemas":{"referenciaMp":"§2 (transiciones por volumen PV/BV, pagos y flags de compliance), §7 ('activo' como compra en ventana rolling configurable y auditable, no hardcodeada)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; no hay forma de saber automáticamente quién cruzó el umbral de inactividad ni quién debe suspenderse."},{"nivel":1,"ancla":"1 Los umbrales se revisan a mano en una hoja de cálculo, después del hecho y sin disparar el cambio de estado."},{"nivel":2,"ancla":"2 Reporte especializado que lista volumen o flags, desconectado del cambio de estado, que se aplica manualmente."},{"nivel":3,"ancla":"3 Reglas de calificación configuradas en la plataforma que evalúan volumen/ventana y flags y proponen o aplican el cambio de estado."},{"nivel":4,"ancla":"4 Plataforma que evalúa los umbrales en tiempo real con ventanas configurables y auditables y ejecuta la calificación de estado de forma trazable."},{"nivel":5,"ancla":"5 Ecosistema donde volumen, compliance y reactivación se evalúan encadenados y ajustan el estado sin intervención manual."}]},"agentico":{"referenciaMp":"§6 (predicción de churn/próximo estado + next-best-action, caso mejor documentado del vertical)","anclas":[{"nivel":0,"ancla":"0 Sin IA; identificar quién está por caer en inactivo o quién puede reactivarse es manual y tardío."},{"nivel":1,"ancla":"1 Alertas por regla fija cuando el volumen de un vendedor se acerca al umbral de inactividad."},{"nivel":2,"ancla":"2 Copiloto que muestra a un vendedor qué le falta para no caer de estado o para reactivarse."},{"nivel":3,"ancla":"3 Agente supervisado que predice quién cruzará el umbral de estado y propone la acción para evitarlo o para reactivar."},{"nivel":4,"ancla":"4 Agentes que combinan volumen, compliance y comportamiento para anticipar cambios de estado y priorizar intervenciones de forma coordinada."},{"nivel":5,"ancla":"5 Calificación de estado asistida de forma autónoma dentro de políticas, que ajusta umbrales e intervenciones según resultados con escalamiento por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Motor de Reglas de Calificación de Estado","tipo":"S4DS","categoria":"Reglas de negocio y calificación de volumen del CRM transaccional","coberturaS4DS":"módulo Ciclo de Vida · umbrales y ventanas de calificación configurables (PV/BV, ventana rolling) · MCP lifecycle/rules tools","nota":"Evalúa volumen, ventana y flags de compliance para calificar el estado, con umbrales configurables y auditables."},{"nombre":"DMS / plataforma de gestión de vendedores (MLM software)","tipo":"tercero","categoria":"Distributor Management System","ejemplos":["Exigo","DirectScale","ByDesign (Freedom)","InfoTrax FlexCloud"],"nota":"Motores de comisiones y volumen donde suelen configurarse los umbrales de calificación de rango/estado."},{"nombre":"BI / analítica de retención y comportamiento","tipo":"tercero","categoria":"Analítica de negocio","ejemplos":["Power BI","Tableau","Looker"],"nota":"Para recalibrar umbrales y ventanas con su correlación observada con retención, en el nivel más maduro de la práctica."}],"agentesYUseCase":[{"useCase":"Copiloto de calificación: muestra a un vendedor qué le falta de volumen o ventana para no caer de estado o para reactivarse.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — sugiere, humano/vendedor decide","valor":"convierte una regla abstracta en una acción concreta y oportuna para el vendedor"},{"useCase":"Agente supervisado de predicción de cruce de umbral: identifica vendedores que se acercan al umbral de inactivo o que califican para reactivación y propone la acción.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — predice y propone; el humano decide","valor":"anticipa la caída de estado en lugar de reaccionar después de que ya ocurrió"},{"useCase":"Detección de anomalías de progresión (autoships perdidos, progresión de rango estancada) semanas antes del cambio de estado.","tipo":"tercero","nivelAutonomia":"agente supervisado (nivel 3)","ejemplos":["Exigo AI"],"valor":"caso de uso mejor documentado del vertical, con evidencia de múltiples vendors independientes"}],"metadata":{"evidenciaEsperada":"Reglas documentadas de calificación de estado (umbral/ventana de inactividad, evento de compliance que lleva a suspensión, criterios de reactivación) con sus parámetros configurables, y evidencia de su aplicación consistente.","dolorAsociado":"Pases a inactivo o suspendido decididos caso por caso, sin criterio definido ni ventana auditable; sin reglas explícitas la 'tasa de activos' se vuelve inconsistente y la reactivación depende del criterio de quien la tramite.","frenteRecomendacion":"Gobierno/Roles/Tercerización","fuente":"MASTER-C01 §2 (transiciones por volumen (PV/BV), pagos de renovación y flags de compliance; el autoship ligado a calificación como palanca de retención del estado Activo), §7 (definición de 'activo' como compra registrada en ventana rolling de 60/90 días, modelada como campo configurable y auditable, no hardcodeado)"},"camposFaltantes":[]},{"practiceId":"C01-06-PR-03","processId":"C01","temaId":"c01-estados-y-ciclo-de-vida","nombre":"Transiciones de estado como eventos de primera clase auditados (causa, timestamp y actor)","pregunta":"¿Cada camb
1io de estado se registra como un evento auditable con su causa, timestamp, actor y estado anterior/nuevo, en lugar de sobrescribir un campo de estatus y perder el historial?","enunciado":"La organización trata cada cambio de estado como un evento de primera clase que se registra en un rastro de auditoría inmutable —capturando la causa (el evento de volumen, el flag de compliance o la acción que lo disparó), el timestamp exacto, el actor (la persona o el proceso que lo ejecutó) y el estado anterior y el nuevo—, en lugar de sobrescribir un campo de estatus y perder el historial. Cada transición es reconstruible después del hecho, de modo que la organización puede explicar por qué y cuándo cambió de estado cualquier vendedor.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin registro de transiciones; el estado se sobrescribe y no queda rastro de por qué, cuándo ni quién lo cambió."},{"nivel":1,"ancla":"1 Se anotan algunos cambios de forma informal y esporádica, sin causa, actor ni fecha consistentes."},{"nivel":2,"ancla":"2 Se registran los cambios de estado pero con datos incompletos (falta la causa o el actor) y sin garantía de que no se alteren."},{"nivel":3,"ancla":"3 Cada transición se registra con causa, timestamp, actor y estado anterior/nuevo de forma consistente."},{"nivel":4,"ancla":"4 Registro gestionado e inmutable; se audita la completitud de las transiciones y se detectan cambios sin causa o sin actor."},{"nivel":5,"ancla":"5 Ninguna regla que genera cambios de estado permanece vigente sin una revisión documentada del historial de transiciones que depuró los patrones que la originaron."}]},"sistemas":{"referenciaMp":"§2/§10 (transiciones como eventos versionados y auditables end-to-end), §3 (audit log inmutable: los cambios son visibles, atribuibles y reversibles), §2.7 (evento de estado versionado)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; los cambios de estado no dejan rastro recuperable."},{"nivel":1,"ancla":"1 Bitácora manual en hoja de cálculo, editable y sin garantía de integridad."},{"nivel":2,"ancla":"2 Herramienta especializada que registra cambios de estado, sin inmutabilidad ni captura completa de causa/actor."},{"nivel":3,"ancla":"3 Plataforma que registra cada transición con causa, timestamp, actor y estados, con historial consultable."},{"nivel":4,"ancla":"4 Plataforma con audit log inmutable en tiempo real donde cada transición es visible, atribuible y reversible de forma trazable."},{"nivel":5,"ancla":"5 Ecosistema donde las transiciones fluyen como eventos versionados encadenados entre capas sin registro manual."}]},"agentico":{"referenciaMp":"§6 (detección de anomalías sobre el historial de estados)","anclas":[{"nivel":0,"ancla":"0 Sin IA; revisar si un cambio de estado fue correcto o anómalo es manual y esporádico."},{"nivel":1,"ancla":"1 Alertas por regla fija ante un tipo de cambio de estado marcado como sensible."},{"nivel":2,"ancla":"2 Copiloto que resume el historial de transiciones de un vendedor a pedido."},{"nivel":3,"ancla":"3 Agente supervisado que revisa el historial de transiciones y señala cambios sin causa, fuera de secuencia o atípicos."},{"nivel":4,"ancla":"4 Agentes que correlacionan transiciones a través de la red para detectar patrones anómalos de cambio de estado de forma continua."},{"nivel":5,"ancla":"5 Vigilancia autónoma dentro de políticas del historial de estados, con escalamiento de anomalías a revisión humana."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Audit Log inmutable de transiciones de estado","tipo":"S4DS","categoria":"Trazabilidad y auditoría del CRM transaccional","coberturaS4DS":"módulo Ciclo de Vida · registro inmutable de transiciones (causa/timestamp/actor/estado anterior-nuevo) · MCP audit/lifecycle tools","nota":"Captura cada transición como evento versionado, visible, atribuible y reversible de forma trazable."},{"nombre":"DMS con SOC 2 / audit trail nativo","tipo":"tercero","categoria":"Distributor Management System","ejemplos":["Exigo (SOC 2 Type II)","Epixel","ByDesign (Freedom)"],"nota":"Plataformas del sector que documentan controles de auditoría formales sobre cambios de estado y comisión."}
1,{"nombre":"Event store / ledger inmutable","tipo":"tercero","categoria":"Infraestructura de eventos versionados","ejemplos":["EventStoreDB","AWS QLDB"],"nota":"Cuando se requiere un registro de eventos técnicamente inmutable independiente del DMS, para transiciones de alto riesgo."}],"agentesYUseCase":[{"useCase":"Copiloto de historial: resume el historial de transiciones de un vendedor a pedido (soporte, disputa, auditoría).","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2)","valor":"acelera la reconstrucción de un caso sin recorrer manualmente el log"},{"useCase":"Agente supervisado de anomalías de transición: revisa el historial y señala cambios sin causa, fuera de secuencia o atípicos.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — detecta y reporta; el humano corrige","valor":"convierte un log pasivo en un control activo de integridad del historial"},{"useCase":"Correlación de transiciones a través de la red para detectar patrones anómalos de cambio de estado de forma continua.","tipo":"tercero","nivelAutonomia":"agente supervisado → multi-agente (nivel 3-4)","ejemplos":["módulos de detección de fraude/anomalías de plataformas DMS, p.ej. Epixel AI"],"valor":"escala la vigilancia de integridad del historial más allá de lo que un revisor humano puede cubrir"}],"metadata":{"evidenciaEsperada":"Muestra del audit trail de transiciones de estado mostrando causa, timestamp, actor y estado anterior/nuevo por cambio, y evidencia de que el registro es inmutable y reconstruible.","dolorAsociado":"Estado que se sobrescribe sin dejar rastro de por qué, cuándo y quién lo cambió; sin transiciones auditadas es imposible reconstruir un ajuste de comisión disputado o defender una suspensión ante el vendedor o el regulador.","frenteRecomendacion":"Tecnología e Integración","fuente":"MASTER-C01 §1 (el patrón best-in-class es que cada transición de estado sea un evento de primera clase que el motor de comisiones consume, no un campo que se actualiza y se olvida), §4 (cada transición es un evento versionado y auditable end-to-end), §2.7 (cada re-calificación es un evento de estado versionado: estado anterior/nuevo, fecha de corte, PV/GV, compresión aplicada), §3 (audit log inmutable donde los cambios son visibles, atribuibles y reversibles)"},"camposFaltantes":[]},{"practiceId":"C01-06-PR-04","processId":"C01","temaId":"c01-estados-y-ciclo-de-vida","nombre":"Acoplamiento del estado al cálculo y pago de comisiones en tiempo real","pregunta":"¿El estado del vendedor habilita o bloquea en tiempo real el cálculo y el pago de sus comisiones (y las del upline), disparado por el mismo evento que cambió el estado, en lugar de actualizarse por un lado y liquidarse por otro con desfase?","enunciado":"La organización acopla el estado del vendedor directamente a si sus comisiones se calculan y se pagan: un estado activo habilita el cálculo y la liquidación, y los estados inactivo, suspendido y terminado las bloquean o retienen, en tiempo real y como el mismo evento que cambió el estado, en lugar de un estatus que se actualiza y se olvida mientras la liquidación corre por un proceso separado y con desfase. Un cambio de estado surte efecto inmediata y automáticamente sobre las comisiones propias del vendedor y sobre las de su upline.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 El estado y las comisiones viven separados; se puede pagar a un vendedor inactivo o suspendido porque el pago no consulta el estado."},{"nivel":1,"ancla":"1 La relación estado-pago se aplica a mano y de forma inconsistente; a veces se detecta a tiempo, a veces no."},{"nivel":2,"ancla":"2 Existe la regla de que el estado condiciona el pago, pero se aplica en un corte posterior y con desfase respecto al cambio de estado."},{"nivel":3,"ancla":"3 El estado condiciona el cálculo y el pago de forma definida: activo habilita, inactivo/suspendido/terminado bloquean o retienen, aplicado consistentemente."},{"nivel":4,"ancla":"4 Acoplamiento gestionado; el cambio de estado surte efecto sobre el cálculo y el pago de forma medida y auditable, y se detectan los pagos indebidos."},{"nivel":5,"ancla":"5 Acoplamiento optimizado; cada transición ajusta en tiempo real la comisión propia y del upline como un solo evento, sin re
1cálculos batch ni reprocesos."}]},"sistemas":{"referenciaMp":"§1/§2 (cada transición de estado es un evento que el motor de comisiones consume), §2.7 (best-in-class: cálculo en tiempo real event-driven en lugar de batch nocturno), §10 (motor de comisiones en tiempo real que consume cada transición como evento versionado)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; el estado y la liquidación de comisiones se calculan por separado sin que uno consulte al otro."},{"nivel":1,"ancla":"1 El bloqueo o pago según estado se verifica a mano en hoja de cálculo antes de liquidar."},{"nivel":2,"ancla":"2 Un reporte especializado de estados y otro de comisiones, reconciliados manualmente antes del pago."},{"nivel":3,"ancla":"3 Motor de comisiones integrado al estado que habilita o bloquea el cálculo según el estado vigente."},{"nivel":4,"ancla":"4 Motor de comisiones que consume cada transición de estado como evento en tiempo real y ajusta cálculo y pago de forma auditable."},{"nivel":5,"ancla":"5 Ecosistema donde estado, cálculo y pago operan como eventos encadenados en tiempo real, sin batch ni reconciliación manual."}]},"agentico":{"referenciaMp":"§6 (detección de anomalías de comisión ligadas al estado; Exigo AI marca autoships perdidos y progresión estancada)","anclas":[{"nivel":0,"ancla":"0 Sin IA; detectar un pago que no correspondía al estado es manual y posterior al hecho."},{"nivel":1,"ancla":"1 Alertas por regla fija cuando se liquida a un vendedor en estado no elegible."},{"nivel":2,"ancla":"2 Copiloto que explica por qué un vendedor cobró o no según su estado."},{"nivel":3,"ancla":"3 Agente supervisado que revisa la coherencia entre estado y comisión pagada y señala discrepancias antes del pago."},{"nivel":4,"ancla":"4 Agentes que correlacionan transiciones de estado con la liquidación en toda la red para anticipar pagos indebidos de forma continua."},{"nivel":5,"ancla":"5 Verificación autónoma dentro de políticas de la coherencia estado-comisión, con retención automática y escalamiento de excepciones."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Motor de Comisiones event-driven","tipo":"S4DS","categoria":"Motor de comisiones del CRM transaccional","coberturaS4DS":"módulo Comisiones · consumo del evento de transición de estado en tiempo real (habilita/bloquea cálculo y pago) · MCP commission engine tools","nota":"Consume cada transición de estado como evento y ajusta cálculo y pago propio y del upline sin corte batch."},{"nombre":"Motor de comisiones real-time event-driven de plataformas DMS","tipo":"tercero","categoria":"Distributor Management System — motor de comisiones","ejemplos":["Exigo Core","Epixel","InfoTrax FlexCloud"],"nota":"Referencia de industria de arquitectura event-driven de comisiones en tiempo real frente a batch nocturno."},{"nombre":"Event streaming / message bus","tipo":"tercero","categoria":"Infraestructura de eventos en tiempo real","ejemplos":["Apache Kafka","AWS EventBridge"],"nota":"Para propagar el evento de cambio de estado a comisiones, genealogía y back-office simultáneamente sin acoplamiento punto a punto."}],"agentesYUseCase":[{"useCase":"Copiloto de explicación: responde por qué un vendedor cobró o no cobró según su estado vigente.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2)","valor":"reduce tickets de soporte y desconfianza sobre pagos no recibidos"},{"useCase":"Agente supervisado de coherencia estado-comisión: revisa antes del pago que el estado vigente sea elegible y señala discrepancias.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — revisa antes de liquidar","valor":"evita el pago indebido en lugar de descubrirlo después vía clawback"},{"useCase":"Correlación de transiciones de estado con la liquidación en toda la red para anticipar pagos indebidos de forma continua (marca autoships perdidos y progresión estancada).","tipo":"tercero","nivelAutonomia":"agente supervisado (nivel 3)","ejemplos":["Exigo AI"],"valor":"anticipa el desacople estado-comisión antes de que llegue al ciclo de pago"}],"metadata":{"evidenciaEsperada":"Evidencia de que el cálculo y el pago de comisiones consultan el estado vigente en tiempo real (regla de habilitación/bloqueo por estado) y de que un cambio de estado surte efecto sobre la comisión propia y del upline sin corte batch.","dolorAsociado":"Estado que se actualiza y se olvida mientras la liquidación corre por un batch separado: se paga a inactivos o suspendidos y se descubre tarde, generando clawbacks, ajustes retroactivos y disputas con el upline.","frenteRecomendacion":"Tecnología e Integración","fuente":"MASTER-C01 §1 (el patrón best-in-class es que cada transición de estado sea un evento de primera clase que el motor de comisiones consume, no un campo que se actualiza y se olvida), §2.5 (el evento de primera calificación dispara el sponsor bonus como hand-off directo al motor de comisiones, versionado), §2.7 (best-in-class corre el recálculo como cálculo en tiempo real con arquitectura event-driven en lugar de batch nocturno), §10 (largo plazo: motor de comisiones en tiempo real event-driven que consume cada transición de estado como evento versionado)"},"camposFaltantes":[]},{"practiceId":"C01-06-PR-05","processId":"C01","temaId":"c01-estados-y-ciclo-de-vida","nombre":"Regla de compresión vs. roll-up documentada en la P&P y su efecto sobre genealogía y pago del upline","pregunta":"¿La regla de compresión (temporal/reversible, sin alterar la genealogía) frente a roll-up (permanente hacia el primer upline calificado) está documentada en la Política y Procedimientos —no solo en la lógica del motor— con su efecto explícito sobre la genealogía y el pago del upline?","enunciado":"La organización documenta, en su Política y Procedimientos y no solo en la lógica de cálculo, la regla que gobierna cómo 
1se trata a un nodo inactivo o no calificado para efectos de comisión: compresión (un salto temporal y reversible sobre los nodos inactivos para el cálculo del periodo, sin alterar la genealogía real) frente a roll-up (un movimiento permanente de la comisión hacia el primer upline calificado). La regla especifica cuál aplica, si es dinámica o estática, y su efecto sobre la genealogía y sobre lo que se paga a cada upline, de modo que el tratamiento es transparente, consistente y explicable a los uplines afectados.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin regla definida; el tratamiento de nodos inactivos para la comisión es opaco y depende de lo que haga la lógica de cálculo."},{"nivel":1,"ancla":"1 La regla existe solo en la práctica de quien opera el cálculo; no está escrita ni es explicable al upline."},{"nivel":2,"ancla":"2 Hay una noción de compresión o roll-up pero sin distinguirlas con claridad ni documentar cuál aplica y cuándo."},{"nivel":3,"ancla":"3 Regla documentada en la P&P: distingue compresión (temporal/reversible, sin alterar genealogía) de roll-up (permanente al primer upline calificado) y define cuál aplica."},{"nivel":4,"ancla":"4 Regla gestionada; se audita que el cálculo aplique lo documentado y se explica al upline el efecto sobre su pago, con desviaciones detectadas."},{"nivel":5,"ancla":"5 Ningún tratamiento de compresión (dinámico o estático, con o sin roll-up) permanece vigente sin una revisión documentada de su efecto medido sobre el pago del upline y la integridad de la genealogía."}]},"sistemas":{"referenciaMp":"§2 (distinguir compresión —salto comercial a inactivos solo para el cálculo del periodo, sin alterar la genealogía real— de roll-up —mover la comisión al primer upline calificado—; la regla debe estar en la P&P, no solo en la lógica del motor)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; el efecto de compresión o roll-up no es visible ni reproducible fuera del cálculo mismo."},{"nivel":1,"ancla":"1 El tratamiento se resuelve a mano en el cálculo del periodo, sin dejar visible qué nodos se comprimieron o subieron."},{"nivel":2,"ancla":"2 El motor aplica una lógica de compresión/roll-up, pero no la expone ni permite auditar qué se aplicó por nodo."},{"nivel":3,"ancla":"3 Motor que aplica la regla documentada y deja visible, por periodo, qué nodos se comprimieron (reversible) y cuáles subieron por roll-up."},{"nivel":4,"ancla":"4 Plataforma que aplica y audita en tiempo real el efecto de compresión/roll-up sobre la genealogía y el pago de cada upline."},{"nivel":5,"ancla":"5 Ecosistema donde la regla, su aplicación y su efecto sobre genealogía y pago fluyen encadenados y trazables sin ajuste manual."}]},"agentico":{"referenciaMp":"§6 (simulación/explicación asistida del efecto en comisiones)","anclas":[{"nivel":0,"ancla":"0 Sin IA; simular qué pasaría con el pago del upline bajo compresión o roll-up es manual."},{"nivel":1,"ancla":"1 Cálculo automatizado del efecto en una hoja con parámetros cargados a mano."},{"nivel":2,"ancla":"2 Copiloto que explica a un upline por qué su pago cambió por compresión o roll-up."},{"nivel":3,"ancla":"3 Agente supervisado que simula el efecto de compresión frente a roll-up sobre la genealogía y el pago antes de aplicarlo."},{"nivel":4,"ancla":"4 Agentes que evalúan el impacto de la regla en toda la downline y anticipan efectos no deseados sobre el pago de forma coordinada."},{"nivel":5,"ancla":"5 Simulación y aplicación autónomas dentro de políticas del tratamiento óptimo por periodo, con escalamiento de casos límite."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Motor de Genealogía y Comisiones (compresión/roll-up configurable)","tipo":"S4DS","categoria":"Genealogía y comisiones del CRM transaccional","coberturaS4DS":"módulo Genealogía/Comisiones · regla de compresión (temporal/reversible) vs. roll-up (permanente) configurable y visible por nodo/periodo · MCP genealogy/commission tools","nota":"Aplica la regla documentada y deja visible qué nodos se comprimieron y cuáles subieron por roll-up en cada periodo."}
1,{"nombre":"DMS con motor de compresión configurable","tipo":"tercero","categoria":"Distributor Management System","ejemplos":["Epixel","InfoTrax FlexCloud","DirectScale"],"nota":"Plataformas que documentan públicamente su lógica de compresión y permiten configurarla por plan."},{"nombre":"Gestión documental de políticas (P&P)","tipo":"tercero","categoria":"Gestión de contratos y políticas","ejemplos":["Ironclad","DocuSign CLM"],"nota":"Para versionar la Política y Procedimientos donde debe quedar escrita la regla de compresión/roll-up, no solo en el motor."}],"agentesYUseCase":[{"useCase":"Copiloto de explicación de pago: explica a un upline por qué su comisión cambió por efecto de compresión o roll-up en el periodo.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2)","valor":"reduce disputas al hacer explicable un efecto que de otro modo parece arbitrario"},{"useCase":"Agente supervisado de simulación: simula el efecto de compresión frente a roll-up sobre la genealogía y el pago antes de aplicarlo.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — simula y recomienda; el humano aprueba","valor":"permite anticipar el impacto en la downline antes de que el cálculo del periodo lo haga irreversible"},{"useCase":"Evaluación del impacto de la regla en toda la downline para anticipar efectos no deseados sobre el pago.","tipo":"tercero","nivelAutonomia":"agente supervisado → multi-agente (nivel 3-4)","ejemplos":["módulos de simulación de comp plan de plataformas DMS, p.ej. DirectScale scenario modeling"],"valor":"escala la simulación de compresión/roll-up a redes grandes antes de aplicar un cambio de regla"}],"metadata":{"evidenciaEsperada":"Sección de la Política y Procedimientos que documenta la regla de compresión (temporal/reversible) frente a roll-up (permanente), si es dinámica o estática y con/sin roll-up, más evidencia de que el cálculo del periodo aplica lo documentado y su efecto por nodo es auditable.","dolorAsociado":"Compresión y roll-up viviendo solo en la lógica del motor, sin regla escrita: el upline no puede entender por qué cambió su pago, la genealogía real se confunde con el salto de cálculo y una disputa no tiene documento que la resuelva.","frenteRecomendacion":"Gobierno/Roles/Tercerización","fuente":"MASTER-C01 §2 (Colocación en genealogía: distinguir compresión —salta comercialmente a inactivos solo para el cálculo del periodo, sin alterar la genealogía real— de roll-up —mueve la comisión hacia arriba hasta el primer upline calificado—; la regla dinámica vs. estática, con/sin roll-up, debe estar en la Política y Procedimientos, no solo en la lógica del motor), §2.7 (compresión aplicada como parte del evento de estado versionado del que derivan ajustes de bono y cambios de tasa en la downline)"},"camposFaltantes":[]},{"practiceId":"C01-06-PR-06","processId":"C01","temaId":"c01-estados-y-ciclo-de-vida","nombre":"Fuente única y consistente del estado a través de back-office, comisiones y genealogía","pregunta":"¿Existe una fuente única y autoritativa del estado del vendedor que back-office, comisiones y genealogía leen por igual, en lugar de que cada área mantenga su propia copia que se desincroniza?","enunciado":"La organización mantiene una fuente única y autoritativa del estado del vendedor, de modo que back-office, comisiones y genealogía leen todos el mismo estado al mismo tiempo, en lugar de que cada área conserve su propia copia que se desincroniza. El estado se define una sola vez y se propaga —no se recaptura—, de modo que un vendedor suspendido está suspendido en todas partes y ninguna área aguas abajo opera sobre un estado desactualizado o contradictorio.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Cada área mantiene su propia versión del estado del vendedor; back-office, comisiones y genealogía pueden contradecirse."},{"nivel":1,"ancla":"1 Se intenta mantener el mismo estado en varias áreas de forma manual, con desincronizaciones frecuentes."},{"nivel":2,"ancla":"2 Hay un estado de referencia, pero las áreas lo copian y se desactualiza entre sincronizaciones periódicas."},{"nivel":3,"ancla":"3 Fuente única del estado definida: back-office, comisiones y genealogía leen el mismo estado, con reglas claras de propagación."},{"nivel":4,"ancla":"4 Fuente única gestionada; se mide y audita la consistencia del estado entre sistemas y se corrigen las divergencias detectadas."},{"nivel":5,"ancla":"5 Fuente única optimizada; la consistencia del estado es continua y las divergencias se previenen en origen, sin re
1conciliación manual."}]},"sistemas":{"referenciaMp":"§5 (DMS como sistema de registro único de identidad-genealogía-contrato-comisión; sincronización unidireccional hacia ERP y CRM; evitar la fragmentación de fuente de verdad), §10 (DMS como sistema de registro único)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; el estado vive en múltiples lugares sin un sistema de registro que mande."},{"nivel":1,"ancla":"1 Varias hojas o sistemas con el estado, reconciliados a mano y con divergencias."},{"nivel":2,"ancla":"2 Sistemas especializados por función, cada uno con su propia copia del estado, transferida manualmente entre ellos."},{"nivel":3,"ancla":"3 Sistema de registro del estado del vendedor del que los demás sistemas leen o hacia el que sincronizan."},{"nivel":4,"ancla":"4 Sistema de registro único que expone el estado en tiempo real y sincroniza unidireccionalmente hacia back-office, comisiones y genealogía."},{"nivel":5,"ancla":"5 Ecosistema donde el estado se define una vez y fluye a todas las capas sin transferencias ni reconciliación manual."}]},"agentico":{"referenciaMp":"§6 (detección de inconsistencias de dato maestro entre sistemas)","anclas":[{"nivel":0,"ancla":"0 Sin IA; detectar que dos sistemas muestran estados distintos del mismo vendedor es manual y tardío."},{"nivel":1,"ancla":"1 Alertas por regla fija cuando una reconciliación encuentra un estado divergente."},{"nivel":2,"ancla":"2 Copiloto que consulta y compara el estado de un vendedor entre sistemas a pedido."},{"nivel":3,"ancla":"3 Agente supervisado que reconcilia el estado entre sistemas y señala las divergencias para corregirlas."},{"nivel":4,"ancla":"4 Agentes que vigilan la consistencia del estado a través de todas las capas y anticipan divergencias de forma continua."},{"nivel":5,"ancla":"5 Reconciliación autónoma dentro de políticas del estado entre sistemas, con corrección en origen y escalamiento por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — DMS / Sistema de Registro Único (identidad-genealogía-contrato-comisión)","tipo":"S4DS","categoria":"Sistema de registro del CRM transaccional","coberturaS4DS":"módulo Ciclo de Vida/Genealogía · fuente única del estado con sincronización unidireccional hacia ERP/CRM · MCP system-of-record tools","nota":"Actúa como sistema de registro del estado del vendedor del que back-office, comisiones y genealogía leen o hacia el que sincronizan."},{"nombre":"ERP (contabilidad y lista de precios maestra)","tipo":"tercero","categoria":"Sistema financiero de registro","ejemplos":["SAP","Oracle NetSuite","Microsoft Dynamics 365"],"nota":"Debe sincronizarse desde el DMS, nunca mantener su propia copia autoritativa del estado del vendedor."},{"nombre":"iPaaS / integración","tipo":"tercero","categoria":"Integración y sincronización de sistemas","ejemplos":["MuleSoft","Boomi","Workato"],"nota":"Para la sincronización unidireccional disciplinada del estado hacia ERP y CRM sin que se convierta en una segunda fuente de verdad."},{"nombre":"Master Data Management (MDM)","tipo":"tercero","categoria":"Gestión de datos maestros","ejemplos":["Informatica MDM","Profisee"],"nota":"Cuando la organización necesita gobernar el estado del vendedor como entidad maestra a través de múltiples dominios (cliente, empleado, socio)."}],"agentesYUseCase":[{"useCase":"Copiloto de consulta cruzada: compara el estado de un vendedor entre sistemas (back-office, comisiones, genealogía) a pedido.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2)","valor":"acelera el diagnóstico de una discrepancia reportada sin acceso manual a cada sistema"},{"useCase":"Agente supervisado de reconciliación: detecta divergencias de estado entre sistemas y las señala para corrección.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — detecta y reporta; el humano corrige","valor":"encuentra la fragmentación de fuente de verdad antes de que genere un pago indebido o una disputa de genealogía"},{"useCase":"Vigilancia continua de consistencia del estado a través de todas las capas, con corrección en origen.","tipo":"tercero","nivelAutonomia":"agente supervisado → autónomo dentro de políticas (nivel 3-4)","ejemplos":["herramientas de calida
1d de datos / MDM con detección de anomalías, p.ej. Informatica Data Quality"],"valor":"previene la divergencia en origen en lugar de descubrirla en una reconciliación periódica"}],"metadata":{"evidenciaEsperada":"Definición del sistema de registro único del estado del vendedor y de cómo back-office, comisiones y genealogía lo leen o sincronizan, más evidencia de medición de la consistencia del estado entre sistemas.","dolorAsociado":"Cada área con su propia copia del estado que se desincroniza: el vendedor está suspendido en compliance pero activo en comisiones y sigue cobrando, o terminado en back-office pero vivo en la genealogía; la fragmentación de la fuente de verdad es la falla estructural más citada del sector.","frenteRecomendacion":"Tecnología e Integración","fuente":"MASTER-C01 §5 (Integración ERP/CRM: el riesgo típico es la fragmentación de fuente de verdad; DMS como sistema de registro de la relación vendedor-compañía —identidad, genealogía, contrato, comisión— que sincroniza unidireccionalmente hacia ERP y CRM, nunca al revés), §10 (largo plazo: DMS como sistema de registro único de identidad-genealogía-contrato-comisión con sincronización unidireccional)"},"camposFaltantes":[]},{"practiceId":"C01-07-PR-01","processId":"C01","temaId":"c01-renovaciones-y-retencion-del-vinculo","nombre":"Renovación contractual recurrente como evento explícito con aceptación auditable y cuota de renovación gobernada","pregunta":"¿La renovación contractual del vendedor es un evento recurrente explícito con corte de elegibilidad y aceptación auditable de la versión vigente del acuerdo —con la cuota de renovación separada, transparente y con política de reembolso alineada a los códigos del sector— en lugar de un cobro automático silencioso o una prórroga tácita?","enunciado":"La organización trata la renovación contractual del vendedor como un evento recurrente explícito —con un periodo definido (típicamente anual), una fecha de corte de elegibilidad y una aceptación auditable de la versión vigente del acuerdo—, en lugar de un cobro automático silencioso o de una prórroga tácita que nadie confirma. La cuota de renovación, cuando existe, está separada de otras cuotas, es transparente para el vendedor y su política de reembolso está alineada a los códigos de ética del sector, de modo que cada renovación deja un registro de qué versión del acuerdo aceptó el vendedor y en qué fecha, y no se confunde la facturación recurrente con el consentimiento contractual.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 No hay evento de renovación; el vínculo se prorroga de forma tácita o se cobra de forma automática sin confirmar consentimiento ni versión del acuerdo."},{"nivel":1,"ancla":"1 La renovación se maneja caso por caso de forma informal; no hay periodo definido ni registro consistente de qué se aceptó."},{"nivel":2,"ancla":"2 Existe un ciclo de renovación repetible con cuota, pero la aceptación no es auditable y la política de reembolso de la cuota no está clara."},{"nivel":3,"ancla":"3 Renovación definida como evento recurrente con periodo, corte de elegibilidad y aceptación auditable de la versión vigente del acuerdo; cuota separada y política de reembolso documentada y alineada a los códigos del sector."},{"nivel":4,"ancla":"4 Renovación gestionada; se mide la tasa de renovación como métrica separada de la actividad mensual y se audita que cada renovación registró versión, fecha y aceptación."},{"nivel":5,"ancla":"5 Ninguna condición de renovación (cuota, ventana, requisitos) permanece vigente sin una revisión documentada contra su correlación real con la retención y la calidad del vínculo."}]},"sistemas":{"referenciaMp":"§2.8 (renovación como evento explícito, no cargo automático silencioso; separación de cuota de registro y cuota de afiliación), §7 (renovación anual como evento binario auditable; renewal fee)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; la renovación, si ocurre, se resuelve en correos o cobros sueltos sin dejar registro de aceptación."},{"nivel":1,"ancla":"1 La renovación se controla en una hoja de cálculo con fechas y cobros anotados a mano, sin captura de la ver
1sión aceptada."},{"nivel":2,"ancla":"2 Herramienta especializada que factura la cuota de renovación, pero sin vincular la aceptación a la versión exacta del acuerdo ni registrar el consentimiento."},{"nivel":3,"ancla":"3 Plataforma de vendedores que gestiona el evento de renovación con corte de elegibilidad y captura de aceptación ligada a la versión vigente del acuerdo."},{"nivel":4,"ancla":"4 Plataforma que registra cada renovación con versión, timestamp y evidencia de aceptación de forma auditable, y expone la cuota y su política de reembolso al vendedor."},{"nivel":5,"ancla":"5 Ecosistema donde el evento de renovación, la cuota, la aceptación auditable y el corte de elegibilidad fluyen encadenados hacia comisiones y back-office sin re-captura manual."}]},"agentico":{"referenciaMp":"§6 (next-best-action por vendedor; predicción de churn en el punto de renovación)","anclas":[{"nivel":0,"ancla":"0 Sin IA; anticipar qué vendedores llegan a su fecha de renovación y prepararla es manual."},{"nivel":1,"ancla":"1 Alertas por regla fija cuando un vendedor se acerca a su fecha de corte de renovación."},{"nivel":2,"ancla":"2 Copiloto que responde a un vendedor cuándo renueva, qué cuota aplica y qué versión del acuerdo debe aceptar."},{"nivel":3,"ancla":"3 Agente supervisado que prepara el paquete de renovación (versión vigente, cuota, corte) por vendedor y propone la secuencia de renovación para revisión."},{"nivel":4,"ancla":"4 Agentes que coordinan el ciclo de renovación de toda la red, correlacionan señales de riesgo y priorizan las renovaciones críticas de forma continua."},{"nivel":5,"ancla":"5 Orquestación autónoma del ciclo de renovación dentro de políticas, con aceptación auditable garantizada y escalamiento por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Motor de renovación y ciclo contractual","tipo":"S4DS","categoria":"Ciclo de vida del vendedor / eventos de renovación","coberturaS4DS":"módulo Ciclo de vida · evento de renovación versionado con corte de elegibilidad · MCP renewal tools","nota":"Modela el periodo, el corte de elegibilidad y la cuota como configuración gobernada, no como cobro silencioso."},{"nombre":"S4DS — Registro de aceptación auditable","tipo":"S4DS","categoria":"Consentimiento y versión de acuerdo","coberturaS4DS":"registro inmutable de versión aceptada, timestamp y evidencia · MCP consent tools","nota":"Deja constancia reconstruible de qué versión del acuerdo aceptó el vendedor en cada renovación."},{"nombre":"Plataformas DMS (Distributor Management)","tipo":"tercero","categoria":"Sistema de registro de genealogía, comisiones y ciclo de vida","ejemplos":["Exigo","DirectScale","ByDesign (Freedom)","Epixel"],"nota":"Ejecutan el ciclo de renovación (facturación, corte de elegibilidad) como parte del DMS núcleo."},{"nombre":"Firma electrónica","tipo":"tercero","categoria":"Aceptación auditable de documentos","ejemplos":["DocuSign eSignature"],"nota":"Vincula la aceptación de la renovación a la versión exacta del acuerdo vigente, con audit trail."},{"nombre":"Gestión de suscripciones/facturación recurrente","tipo":"tercero","categoria":"Billing y política de reembolso","ejemplos":["Chargebee","Recurly","Zuora"],"nota":"Separa la cuota de renovación de otras cuotas y expone la política de reembolso de forma transparente."}],"agentesYUseCase":[{"useCase":"Copiloto que responde a un vendedor cuándo renueva, qué cuota aplica y qué versión del acuerdo debe aceptar.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — responde y explica; el humano decide","valor":"reduce fricción y dudas del vendedor en el momento del corte de elegibilidad"},{"useCase":"Agente supervisado que prepara el paquete de renovación (versión vigente, cuota, corte) por vendedor y propone la secuencia de renovación para revisión.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — prepara y propone; el humano aprueba","valor":"estandariza el paquete de renovación en toda la red sin depender de armarlo caso por caso"},{"useCase":"Auditor de renovaciones: verifica que cada evento de renovación registró versión, fecha y evidencia de aceptación, y abre excepción cuando falta.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — detecta y reporta; el humano corrige","valor":"elimina renovaciones que quedaron como cobro sin consentimiento reconstruible"},{"useCase":"Agentes que coordinan el ciclo de renovación de toda la red, correlacionan señales de r
1iesgo de no-renovación y priorizan de forma continua las renovaciones críticas.","tipo":"tercero","nivelAutonomia":"multi-agente (nivel 4) — coordina y prioriza; escalamiento por excepción","ejemplos":["Rallyware Intelligent Field Orchestration","Exigo AI"],"valor":"anticipa qué renovaciones están en riesgo antes del corte, no solo las procesa"}],"metadata":{"evidenciaEsperada":"Definición del evento de renovación (periodo, corte de elegibilidad, cuota y su política de reembolso) más muestra del registro de renovaciones con versión del acuerdo aceptada, timestamp y evidencia de aceptación.","dolorAsociado":"Renovación como cobro automático silencioso o prórroga tácita: no queda registro de qué versión del acuerdo aceptó el vendedor, la cuota se confunde con otras y una disputa sobre el cargo o sobre las condiciones vigentes no tiene documento que la resuelva.","frenteRecomendacion":"Gobierno/Roles/Tercerización","fuente":"MASTER-C01 §2.8 (la renovación no es solo facturación: revalida disclosure y consentimiento; debe ser un evento explícito con disclosure refresh —no cargo automático silencioso— y alimentar al motor como corte de elegibilidad; Amway separa cuota de registro de negocio de cuota de afiliación), §7 (el proxy de retención dura más limpio es la re-calificación/renovación anual como evento binario auditable; Reliv cobra US$40/año, Herbalife ~US$15/año; reportar % activo mensual y % renovación como métricas separadas), §2 (el IDS debe versionarse y re-certificarse anualmente junto con la renovación)"},"camposFaltantes":[]},{"practiceId":"C01-07-PR-02","processId":"C01","temaId":"c01-renovaciones-y-retencion-del-vinculo","nombre":"Re-calificación periódica de rango como evento versionado con mantenimiento o descenso por desempeño","pregunta":"¿El rango del vendedor se re-califica periódicamente por desempeño —con reglas explícitas de mantenimiento y descenso y como evento versionado— en lugar de asignar rangos que, una vez alcanzados, ya no se revisan?","enunciado":"La organización re-califica periódicamente el rango del vendedor con base en su desempeño en la ventana de medición —confirmando el mantenimiento, el ascenso o el descenso de rango— y trata cada re-calificación como un evento versionado con reglas explícitas de qué volumen o actividad sostiene cada rango, en lugar de asignar rangos que, una vez alcanzados, nunca se revisan. Las reglas de mantenimiento y descenso están documentadas y son consistentes, de modo que el rango refleja el desempeño vigente y no un logro histórico congelado, y el efecto de cada re-calificación sobre la comisión propia y de la downline es trazable.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 No hay re-calificación; un rango alcanzado se conserva de forma indefinida sin importar el desempeño posterior."},{"nivel":1,"ancla":"1 La re-calificación se hace de forma esporádica y discrecional, sin ventana ni criterios consistentes."},{"nivel":2,"ancla":"2 Existe una noción de re-calificación periódica, pero las reglas de mantenimiento y descenso son incompletas o se aplican de forma desigual."},{"nivel":3,"ancla":"3 Re-calificación definida y documentada: ventana de medición, reglas de mantenimiento/ascenso/descenso por rango y su efecto declarado sobre la comisión."},{"nivel":4,"ancla":"4 Re-calificación gestionada; se mide la tasa de re-calificación por rango, cada evento queda versionado y se auditan los ajustes de comisión que derivan de un cambio de rango."},{"nivel":5,"ancla":"5 Ningún umbral de mantenimiento o descenso de rango permanece vigente sin una revisión documentada de su impacto medido en la retención y la equidad del plan."}]},"sistemas":{"referenciaMp":"§2.7 (re-calificación periódica como evento de estado versionado —rango anterior/nuevo, fecha de corte, PV/GV, compresión aplicada—; best-in-class corre el recálculo en tiempo real event-driven en lugar de batch nocturno), §10 (motor de comisiones en tiempo real que consume cada transición como evento versionado)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; el rango es un campo que se fija una vez y no se recalcula contra el desempeño."},{"nivel":1,"ancla":"1 La re-calificación se recalcula a mano en una hoja de cálculo al cierre del periodo, sin versionar el cambio."},{"nivel":2,"ancla":"2 Reporte especializado de volumen por rango, desconectado del cambio de rango, que se aplica manualmente."},{"nivel":3,"ancla":"3 Plataforma que re-califica el rango según las reglas de la ventana y registra el evento con rango anterior/nuevo y fecha de corte."},{"nivel":4,"ancla":"4 Motor que re-califica el rango consumiendo el evento versionado en tiempo real y ajusta la comisión propia y de la downline de forma auditable."},{"nivel":5,"ancla":"5 Ecosistema donde la re-calificación, la compresión y los ajustes de comisión asociados fluyen encadenados por evento sin recálculo batch ni reprocesos."}]},"agentico":{"referenciaMp":"§6 (Exigo AI marca progresión de rango estancada semanas antes del churn; predicción de churn + next-best-action, caso mejor documentado del vertical)","anclas":[{"nivel":0,"ancla":"0 Sin IA; identificar quién está por perder su rango en la próxima re-calificación es manual y tardío."},{"nivel":1,"ancla":"1 Alertas por regla fija cuando el volumen de un vendedor se acerca al umbral de descenso de rango."},{"nivel":2,"ancla":"2 Copiloto que muestra a un vendedor qué le falta para mantener o ascender de rango en la ventana."},{"nivel":3,"ancla":"3 Agente supervisado que detecta progresión de rango estancada y propone la acción para mantener el rango antes del corte."},{"nivel":4,"ancla":"4 Agentes que combinan volumen, desempeño y comportamiento para anticipar descensos de rango y priorizar intervenciones de forma coordinada."},{"nivel":5,"ancla":"5 Re-calificación asistida de forma autónoma dentro de políticas, que ajusta intervenciones según resultados con escalamiento de casos límite."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Motor de re-calificación de rango","tipo":"S4DS","categoria":"Ciclo de vida / motor de comisiones","coberturaS4DS":"módulo Rangos · evento versionado (rango anterior/nuevo, fecha de corte, PV/GV, compresión) · MCP rank-requalification tools","nota":"Registra cada re-calificación como evento versionado consumible por el motor de comisiones sin recálculo local."},{"nombre":"S4DS — Motor de comisiones en tiempo real event-driven","tipo":"S4DS","categoria":"Motor de comisiones","coberturaS4DS":"recálculo por evento de transición de rango, no batch nocturno","nota":"Ajusta comisión propia y de downline de forma auditable en el mismo ciclo en que ocurre la re-calificación."},{"nombre":"Plataformas DMS (Distributor Management)","tipo":"tercero","categoria":"Sistema de registro de genealogía, comisiones y rangos","ejemplos":["Exigo","DirectScale","ByDesign (Freedom)","Epixel"],"nota":"Ejecutan la re-calificación periódica de rango según reglas de la ventana de medición configurada."},{"nombre":"BI / analítica de rangos y comisiones","tipo":"tercero","categoria":"Analítica de desempeño por rango","ejemplos":["Power BI","Tableau","Looker"],"nota":"Monitorea la tasa de re-calificación por rango y el impacto de ascensos/descensos en el gasto de comisiones."},{"nombre":"Consultoría de plan de compensación","tipo":"tercero","categoria":"Diseño de reglas de mantenimiento/descenso","ejemplos":["Dan Jensen Consulting","Sylvina Consulting"],"nota":"Aporta el racional comparativo para calibrar umbrales de mantenimiento y descenso sin romper la equidad del plan."}],"agentesYUseCase":[{"useCase":"Copiloto que muestra a un vendedor qué le falta en volumen o actividad para mantener o ascender de rango dentro de la ventana vigente.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — informa; el vendedor actúa","valor":"convierte el umbral de re-calificación en una meta visible en vez de una sorpresa al cierre"},{"useCase":"Agente supervisado que detecta progresión de rango estancada y propone la acción para mantener el rango antes del corte de la ventana.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — detecta y propone; el humano decide","valor":"convierte una señal temprana de churn en una intervención antes de perder el rango"},{"useCase":"Exigo AI marca anomalías de progresión de rango estancada semanas antes del churn, con evidencia documentada del vertical junto a otros dos vendors independientes.","tipo":"tercero","nivelAutonomia":"agente supervisado (nivel 3)","ejemplos":["Exigo AI","Rallyware","Epixel"],"valor":"es, con evidencia de tres vendors independientes, el caso de uso mejor documentado del vertical para anticipar el descenso de rango"},{"useCase":"Agentes que combinan volumen, desempeño y comportamiento para anticipar descensos de rango de toda la red y priorizar intervenciones de forma coordinada.","t
1ipo":"S4DS","nivelAutonomia":"multi-agente (nivel 4) — prioriza a escala; escalamiento por excepción","valor":"extiende la detección de riesgo de descenso de un vendedor a la red completa sin perder trazabilidad"}],"metadata":{"evidenciaEsperada":"Reglas documentadas de re-calificación de rango (ventana, criterios de mantenimiento/ascenso/descenso) más muestra de eventos de re-calificación versionados (rango anterior/nuevo, fecha de corte) y del efecto auditado sobre la comisión.","dolorAsociado":"Rangos que, una vez alcanzados, nunca se revisan: la estructura de comisiones paga rangos que ya no reflejan el desempeño vigente, el descenso no ocurre o se hace de forma discrecional, y sin evento versionado un ajuste de rango disputado no puede reconstruirse.","frenteRecomendacion":"Tecnología e Integración","fuente":"MASTER-C01 §2.7 (el ciclo de vida y el motor de comisiones están más acoplados vía re-calificación periódica; Herbalife reporta ~70.3% de sales leaders re-calificados en el periodo a enero-2025; cada re-calificación es un evento de estado versionado —rango anterior/nuevo, fecha de corte, PV/GV, compresión aplicada— del que derivan ajustes retroactivos de bono y cambios de tasa en toda la downline; best-in-class corre esto como cálculo en tiempo real event-driven en lugar de batch nocturno), §7 (la re-calificación/renovación anual es el proxy de retención dura más limpio), §10 (motor de comisiones en tiempo real que consume cada transición de estado como evento versionado)"},"camposFaltantes":[]},{"practiceId":"C01-07-PR-03","processId":"C01","temaId":"c01-renovaciones-y-retencion-del-vinculo","nombre":"Refresh y re-certificación anual del income disclosure junto a la renovación","pregunta":"¿El income disclosure y la divulgación precontractual se refrescan y re-certifican como parte de la renovación, con aceptación separada de la versión vigente y datos de ingreso neto —no un consentimiento genérico embebido en el cobro— y con la sustentación registrada de forma reconstruible?","enunciado":"La organización refresca y re-certifica el income disclosure statement (IDS) y la divulgación precontractual como parte del evento de renovación, capturando una aceptación separada de la versión vigente del disclosure —no un consentimiento genérico embebido en el cobro—, de modo que el vendedor revalida, cada ciclo, qué divulgación de ingresos y gastos vio y aceptó. El IDS refleja datos de ingresos netos (con gastos y deducciones, no solo ingresos brutos) y su versión, timestamp y aceptación quedan registrados de forma reconstruible, cerrando el requisito de conservar la sustentación de las afirmaciones de ingresos por el periodo exigido.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 No hay refresh del disclosure; el income disclosure se muestra una vez al alta (o nunca) y no se revalida al renovar."},{"nivel":1,"ancla":"1 El disclosure se re-comparte de forma informal en algunas renovaciones, sin captura de aceptación ni control de versión."},{"nivel":2,"ancla":"2 Se re-muestra el disclosure al renovar, pero la aceptación va embebida en un único 'acepto todo' junto al cobro y no distingue el IDS."},{"nivel":3,"ancla":"3 Refresh definido: el IDS se re-certifica anualmente con aceptación separada de la versión vigente, con datos de ingreso neto (gastos incluidos)."},{"nivel":4,"ancla":"4 Refresh gestionado; se audita que cada renovación capturó la aceptación separada del IDS vigente y se conserva la sustentación por el periodo exigido."},{"nivel":5,"ancla":"5 Refresh optimizado; el IDS se genera desde datos transaccionales reales por ciclo y su presentación se ajusta para maximizar comprensión y cumplimiento."}]},"sistemas":{"referenciaMp":"§2 (el IDS debe aceptarse con firma separada del Distributor Agreement, declarar gastos/deducciones y versionarse y re-certificarse anualmente junto con la renovación; aceptación auditable con versión exacta, timestamp e IP/dispositivo), §2.8 (renovación con disclosure refresh, no cargo automático silencioso)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; no hay forma de registrar qué versión del disclosure aceptó el vendedor al renovar."},{"nivel":1,"ancla":"1 El disclosure se envía por correo o se archiva en documento suelto, sin captura de aceptación por versión."},{"nivel":2,"ancla":"2 Herramienta que muestra el IDS al renovar, pero con una sola casilla de aceptación conjunta y sin versionado del documento."},{"nivel":3,"ancla":"3 Plataforma que presenta el IDS vigente con aceptación separada del acuerdo y registra versión, timestamp y evidencia de aceptación."},{"nivel":4,"ancla":"4 Plataforma con registro inmutable de la aceptación del IDS por versión, con retención de la sustentación por el periodo exigido y consulta trazable."},{"nivel":5,"ancla":"5 Ecosistema donde el IDS se genera desde datos transaccionales reales, se versiona y su aceptación fluye encadenada al evento de renovación sin re-captura manual."}]},"agentico":{"referenciaMp":"§6 (riesgo de earnings claims generados por IA no verificados; auditoría de proyecciones de ingreso contra la guía FTC), §10 (auditoría de earnings claims generados por IA contra la guía FTC)","anclas":[{"nivel":0,"ancla":"0 Sin IA; verificar que cada renovación capturó la aceptación del IDS vigente es manual y esporádico."},{"nivel":1,"ancla":"1 Alertas por regla fija cuando una renovación se completa sin registro de aceptación del disclosure."},{"nivel":2,"ancla":"2 Copiloto que arma el IDS del periodo desde datos del vendedor y lo deja listo para su aceptación."},{"nivel":3,"ancla":"3 Agente supervisado que genera el IDS neto por vendedor y verifica que la aceptación separada quedó registrada antes de completar la renovación."},{"nivel":4,"ancla":"4 Agentes que consolidan la sustentación de disclosure de toda la red y señalan renovaciones sin aceptación válida o con datos de ingreso inconsistentes."},{"nivel":5,"ancla":"5 Generación y verificación autónomas del refresh de disclosure dentro de políticas, con auditoría de las afirmaciones de ingreso y escalamiento por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Generación de IDS desde datos transaccionales","tipo":"S4DS","categoria":"Income disclosure / motor de comisiones","coberturaS4DS":"generación automática del IDS con ingreso neto (gastos y deducciones) desde el dato transaccional real · MCP disclosure tools","nota":"Evita el IDS como plantilla estática desconectada del ingreso real de la red."},{"nombre":"S4DS — Registro inmutable de aceptación versionada del IDS","tipo":"S4DS","categoria":"Consentimiento y compliance","coberturaS4DS":"aceptación separada del Agreement, con versión, timestamp e IP/dispositivo · retención de sustentación","nota":"Deja evidencia reconstruible de qué versión del disclosure vio y aceptó cada vendedor en cada renovación."},{"nombre":"Plataformas DMS con módulo de compliance","tipo":"tercero","categoria":"Compliance y detección de earnings claims","ejemplos":["Epixel","Exigo","ByDesign (Freedom)"],"nota":"Epixel lidera el ritmo público de lanzamientos de módulos de compliance y detección de fraude en 2025-2026, relevante para gatear el refresh del IDS."},{"nombre":"Firma electrónica","tipo":"tercero","categoria":"Aceptación auditable de documentos","ejemplos":["DocuSign eSignature"],"nota":"Certifica la aceptación del IDS con audit trail bajo ESIGN Act/eIDAS, vinculado a la versión exacta vigente."},{"nombre":"Herramientas de auditoría de earnings claims","tipo":"tercero","categoria":"Compliance regulatorio (FTC/DSSRC)","ejemplos":["software de compliance gating de contenido y earnings claims generado por la fuerza de ventas"],"nota":"Contrasta afirmaciones de ingreso circulantes contra la guía FTC antes de que lleguen al vendedor."}],"agentesYUseCase":[{"useCase":"Copiloto que arma el IDS del periodo desde datos del vendedor y lo deja listo para su aceptación separada.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — prepara; el humano revisa y publica","valor":"reduce el tiempo entre cierre de peri
1odo y disponibilidad del IDS vigente para renovar"},{"useCase":"Agente supervisado que genera el IDS neto por vendedor y verifica que la aceptación separada quedó registrada antes de completar la renovación.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — genera y verifica; el humano corrige excepciones","valor":"cierra el hueco de renovaciones completadas sin aceptación válida del disclosure vigente"},{"useCase":"Agentes que consolidan la sustentación de disclosure de toda la red y señalan renovaciones sin aceptación válida o con datos de ingreso inconsistentes.","tipo":"S4DS","nivelAutonomia":"multi-agente (nivel 4) — consolida a escala; escalamiento por excepción","valor":"convierte la obligación de conservar sustentación en un proceso continuo, no una auditoría anual bajo presión"},{"useCase":"Auditoría de earnings claims generados por IA (proyecciones de ingreso, coaching de ganancias) contra la guía FTC antes de que circulen entre vendedores.","tipo":"tercero","nivelAutonomia":"agente supervisado (nivel 3) — audita; compliance humano aprueba","valor":"contiene el riesgo regulatorio nuevo que introduce la GenAI al generar afirmaciones de ingreso no verificadas"}],"metadata":{"evidenciaEsperada":"Muestra de una renovación con la aceptación separada del IDS vigente registrada (versión, timestamp, evidencia de aceptación), el IDS con datos de ingreso neto (gastos incluidos) y evidencia de conservación de la sustentación por el periodo exigido.","dolorAsociado":"Disclosure que se muestra una vez al alta y nunca se revalida, o aceptación embebida en un 'acepto todo' junto al cobro: la compañía no puede demostrar qué divulgación de ingresos vio y aceptó cada vendedor en cada ciclo, quedando expuesta cuando se cuestionan las afirmaciones de ingreso.","frenteRecomendacion":"Gobierno/Roles/Tercerización","fuente":"MASTER-C01 §2 (Inscripción y aceptación auditable: el IDS debe aceptarse con firma separada del Distributor Agreement, declarar gastos/deducciones y no solo ingresos brutos, y versionarse y re-certificarse anualmente junto con la renovación; aceptación auditable como registro inmutable de la versión exacta del documento aceptado, timestamp e IP/dispositivo, relevante a la obligación de conservar sustentación por 3 años), §2.8 (la renovación revalida disclosure y consentimiento con disclosure refresh, no cargo automático silencioso), §8.1 (el IDS debe generarse automáticamente desde datos transaccionales reales, con gastos)"},"camposFaltantes":[]},{"practiceId":"C01-07-PR-04","processId":"C01","temaId":"c01-renovaciones-y-retencion-del-vinculo","nombre":"Recordatorios de renovación multicanal escalonados y ventana de gracia con reactivación","pregunta":"¿La renovación se avisa con recordatorios escalonados por varios canales (p. ej. 30/15/7/1 días) y existe una ventana de gracia posterior al vencimiento para renovar o reactivarse sin perder posición, en lugar de dejar caer el vínculo en la fecha exacta sin aviso?","enunciado":"La organización avisa la renovación mediante recordatorios escalonados por múltiples canales con suficiente antelación (por ejemplo 30/15/7/1 días antes del corte) y define una ventana de gracia posterior al vencimiento durante la cual el vendedor puede renovar o reactivarse sin perder su posición, en lugar de dejar caer el vínculo en la fecha exacta sin aviso ni segunda oportunidad. Los recordatorios y la ventana de gracia están definidos como reglas configurables, y el tratamiento de la posición de un no-renovado durante y después de la gracia es explícito, de modo que la caída del vínculo es una decisión gobernada y comunicada, no un efecto colateral silencioso.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 No hay recordatorios ni ventana de gracia; el vínculo cae en la fecha de vencimiento sin aviso ni oportunidad de reactivarse."},{"nivel":1,"ancla":"1 Se avisa la renovación de forma esporádica y por un solo canal, sin escalonamiento ni ventana de gracia definida."},{"nivel":2,"ancla":"2 Hay recordatorios repetibles, pero por un canal único o sin la secuencia anticipada, y la gracia se concede caso por caso."},{"nivel":3,"ancla":"3 Recordatorios escalonados multicanal definidos (p. ej. 30/15/7/1 días) y ventana de gracia con criterios de reactivación documentados."},{"nivel":4,"ancla":"4 Gestionado; se mide la efectividad de cada recordatorio y la tasa de reactivación dentro de la gracia, y se ajusta la cadencia según respuesta."},{"nivel":5,"ancla":"5 Ninguna secuencia de recordatorios o ventana de gracia por segmento permanece vigente sin una revisión documentada de su impacto medido en la renovación."}]},"sistemas":{"referenciaMp":"§10 (quick-win: recordatorios de renovación multicanal escalonados —30/15/7/1 días— con disclosure refresh, no cargo automático silencioso), §2.8 (regla explícita de roll-up u orphan placement para la posición del no-renovado)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; no hay forma sistemática de avisar la renovación ni de gestionar la ventana de gracia."},{"nivel":1,"ancla":"1 Los avisos se envían a mano desde el correo personal, sin secuencia ni registro de envío."},{"nivel":2,"ancla":"2 Herramienta que envía un recordatorio único por un canal, sin escalonamiento ni gestión de la gracia."},{"nivel":3,"ancla":"3 Plataforma que ejecuta la secuencia escalonada multicanal y aplica la ventana de gracia con sus reglas de reactivación configuradas."},{"nivel":4,"ancla":"4 Plataforma que dispara los recordatorios por evento en tiempo real, registra respuesta por canal y gestiona la reactivación dentro de la gracia de forma auditable."},{"nivel":5,"ancla":"5 Ecosistema donde la cadencia de renovación, la ventana de gracia y la reactivación fluyen encadenadas con el estado y las comisiones sin intervención manual."}]},"agentico":{"referenciaMp":"§6 (next-best-action por vendedor; predicción de churn como el caso de uso mejor documentado del vertical)","anclas":[{"nivel":0,"ancla":"0 Sin IA; decidir a quién, cuándo y por qué canal recordar la renovación es manual y uniforme para todos."},{"nivel":1,"ancla":"1 Recordatorios automáticos por calendario en fechas fijas, iguales para todos."},{"nivel":2,"ancla":"2 Copiloto que redacta el mensaje de recordatorio de renovación para un vendedor."},{"nivel":3,"ancla":"3 Agente supervisado que elige el canal y el momento del recordatorio por vendedor y propone la mejor acción de reactivación dentro de la gracia."},{"nivel":4,"ancla":"4 Agentes que orquestan la secuencia multicanal de toda la red, ajustan la cadencia por respuesta y priorizan las reactivaciones de mayor valor de forma coordinada."},{"nivel":5,"ancla":"5 Orquestación autónoma de la cadencia de renovación y reactivación dentro de políticas, optimizada por resultados con escalamiento por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Motor de recordatorios multicanal escalonados","tipo":"S4DS","categoria":"Comunicaciones / ciclo de renovación","coberturaS4DS":"secuencia configurable (30/15/7/1 días) por email/SMS/push · disparo por evento en tiempo real · MCP renewal-reminder tools","nota":"Ejecuta la cadencia escalonada y registra la respuesta por canal sin depender de envíos manuales."},{"nombre":"S4DS — Ventana de gracia y reactivación","tipo":"S4DS","categoria":"Ciclo de vida del vendedor","coberturaS4DS":"regla configurable de gracia y de roll-up/orphan placement del no-renovado","nota":"Gobierna qu
1é pasa con la posición durante y después de la gracia, evitando el efecto colateral silencioso."},{"nombre":"Plataformas de marketing automation multicanal","tipo":"tercero","categoria":"Orquestación de comunicaciones (email/SMS/push)","ejemplos":["Klaviyo","Braze","Twilio"],"nota":"Soportan la ejecución de secuencias escalonadas por varios canales cuando se integran al evento de renovación."},{"nombre":"Plataformas DMS (Distributor Management)","tipo":"tercero","categoria":"Sistema de registro con recordatorios de renovación","ejemplos":["Exigo","Epixel","DirectScale"],"nota":"Incluyen disparo de recordatorios de renovación como parte del ciclo de vida gestionado del DMS."}],"agentesYUseCase":[{"useCase":"Copiloto que redacta el mensaje de recordatorio de renovación personalizado para un vendedor según su historial y canal preferido.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — redacta; el humano aprueba el envío","valor":"personaliza el tono y contenido del recordatorio sin multiplicar el trabajo manual por vendedor"},{"useCase":"Agente supervisado que elige el canal y el momento del recordatorio por vendedor y propone la mejor acción de reactivación dentro de la ventana de gracia.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — decide canal/momento; el humano revisa casos límite","valor":"recupera renovaciones que se habrían perdido por un recordatorio genérico o mal cronometrado"},{"useCase":"Next-best-action por vendedor con Intelligent Field Orchestration, con ROI reportado de hasta 32X en 90 días (cifra de vendor, sin auditoría independiente).","tipo":"tercero","nivelAutonomia":"agente supervisado (nivel 3)","ejemplos":["Rallyware Intelligent Field Orchestration"],"valor":"ilustra el caso de uso mejor documentado del vertical para decidir a quién, cuándo y por qué canal recordar"},{"useCase":"Agentes que orquestan la secuencia multicanal de toda la red, ajustan la cadencia por respuesta observada y priorizan las reactivaciones de mayor valor de forma coordinada.","tipo":"S4DS","nivelAutonomia":"multi-agente (nivel 4) — orquesta a escala; escalamiento por excepción","valor":"convierte la cadencia fija en una política adaptativa por segmento sin perder gobierno central"}],"metadata":{"evidenciaEsperada":"Definición de la secuencia de recordatorios escalonados multicanal (p. ej. 30/15/7/1 días) y de la ventana de gracia con sus criterios de reactivación, más evidencia de ejecución (envíos registrados y tasa de reactivación dentro de la gracia).","dolorAsociado":"Vínculo que cae en la fecha exacta sin aviso ni segunda oportunidad: vendedores que habrían renovado se pierden por falta de recordatorio, la reactivación depende del criterio de quien la tramita y la posición del no-renovado queda sin regla explícita durante la gracia.","frenteRecomendacion":"Eficiencia/Simplificación de Proceso","fuente":"MASTER-C01 §10 (quick-win: recordatorios de renovación multicanal escalonados —30/15/7/1 días— con disclosure refresh, no cargo automático silencioso; instrumentar leading indicators de churn como triggers de intervención, no reporting retrospectivo), §2.8 (un no-renovado no debe generar ni recibir comisión, pero su posición requiere regla explícita de roll-up u orphan placement), §7 (retención 30/60/90 y renovación anual como métricas separadas; leading indicators como triggers de intervención)"},"camposFaltantes":[]},{"practiceId":"C01-07-PR-05","processId":"C01","temaId":"c01-renovaciones-y-retencion-del-vinculo","nombre":"Autoship como palanca de retención con cancelación y edición self-service transparente y reembolso alineado al código del sector","pregunta":"¿El vendedor puede editar, pausar o cancelar su pedido recurrente (autoship) por sí mismo, en el mismo canal y con la misma facilidad con que lo activó, con una política de reembolso publicada y alineada a los códigos del sector —usando el autoship como incentivo legítimo de continuidad y no como una opción negativa difícil de cancelar?","enunciado":"La organización usa el pedido recurrente (autoship) como palanca de retención del estado activo, pero lo diseña de forma transparente: el vendedor puede editar, pausar o cancelar su pedido recurrente por sí mismo, en el mismo canal en que lo activó y con la misma facilidad, sin tener que pasar por su patrocinador ni por un canal más difícil, y la política de reembolso del producto está publicada y alineada a los códigos de ética del sector. El autoship se ata a la calificación de estado y de rango como incentivo legítimo de continuidad, nunca como una opción negativa de la que sea difícil salir, de modo que la retención se sostiene en el valor percibido y no en la fricción de cancelación.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 El autoship solo se cancela por un canal más difícil que el alta (p. ej. a través del patrocinador o por teléfono); la política de reembolso no está publicada."},{"nivel":1,"ancla":"1 La cancelación y la edición del autoship depen
1den de gestionarlas con soporte caso por caso, sin regla clara ni self-service."},{"nivel":2,"ancla":"2 Existe una vía de cancelación, pero con más fricción que el alta o con reembolso poco claro y no alineado a un código del sector."},{"nivel":3,"ancla":"3 Cancelación y edición del autoship self-service en el mismo canal del alta y con la misma facilidad; política de reembolso publicada y alineada a los códigos del sector."},{"nivel":4,"ancla":"4 Gestionado; se mide la fricción y la tasa de cancelación self-service frente a las gestionadas por soporte, y se audita que no existan patrones de opción negativa."},{"nivel":5,"ancla":"5 Optimizado; la propuesta de autoship y sus opciones de pausa/edición se ajustan para sostener la retención por valor percibido, sin recurrir a fricción de salida."}]},"sistemas":{"referenciaMp":"§8.8 (la cancelación de autoship debe ser tan fácil como el alta y en el mismo canal; cancelar solo 'a través del patrocinador' o por teléfono es un hallazgo de alto riesgo), §10 (quick-win: cancelación de autoship self-service en el mismo canal del alta)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta de self-service; el autoship solo se modifica o cancela por un canal manual y más difícil que el alta."},{"nivel":1,"ancla":"1 La cancelación se registra a mano tras una solicitud por correo o teléfono, sin opción de autogestión."},{"nivel":2,"ancla":"2 Herramienta que permite gestionar el autoship, pero la cancelación tiene más pasos o menos accesibilidad que el alta."},{"nivel":3,"ancla":"3 Plataforma con self-service de edición, pausa y cancelación del autoship en el mismo canal del alta, con la política de reembolso visible."},{"nivel":4,"ancla":"4 Plataforma que ejecuta la cancelación/edición en tiempo real, la registra de forma auditable y aplica la política de reembolso de forma trazable."},{"nivel":5,"ancla":"5 Ecosistema donde el autoship, su edición/cancelación self-service y el reembolso fluyen encadenados con estado y comisiones sin intervención manual."}]},"agentico":{"referenciaMp":"§6 (Exigo AI marca autoships perdidos semanas antes del churn; next-best-action de retención)","anclas":[{"nivel":0,"ancla":"0 Sin IA; detectar un autoship en riesgo de cancelarse o ya perdido es manual y posterior al hecho."},{"nivel":1,"ancla":"1 Alertas por regla fija cuando un autoship falla o se cancela."},{"nivel":2,"ancla":"2 Copiloto que explica al vendedor cómo editar o pausar su autoship y qué reembolso aplica."},{"nivel":3,"ancla":"3 Agente supervisado que anticipa el autoship perdido y propone la mejor acción de retención sin recurrir a fricción de cancelación."},{"nivel":4,"ancla":"4 Agentes que correlacionan señales de autoship de toda la red para anticipar churn y priorizar intervenciones de retención de forma coordinada."},{"nivel":5,"ancla":"5 Retención por autoship asistida de forma autónoma dentro de políticas, con ofertas de valor y escalamiento por excepción, sin patrones de opción negativa."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Autoship self-service","tipo":"S4DS","categoria":"Pedido recurrente / retención del estado activo","coberturaS4DS":"edición, pausa y cancelación en el mismo canal del alta · MCP autoship tools","nota":"Evita el patrón de opción negativa al ofrecer la misma facilidad para cancelar que para activar."},{"nombre":"S4DS — Política de reembolso publicada y vinculada a la orden recurrente","tipo":"S4DS","categoria":"Compliance de negative option","coberturaS4DS":"política de reembolso visible al vendedor, trazable por orden y aplicada de forma auditable","nota":"Cierra el hallazgo de alto riesgo de reembolsos poco claros o gestionados de forma discrecional."},{"nombre":"Plataformas DMS (Distributor Management)","tipo":"tercero","categoria":"Sistema de registro con módulo de autoship","ejemplos":["Exigo","DirectScale","ByDesign (Freedom)","Epixel"],"nota":"Ejecutan el ciclo de autoship ligado a calificación de rango como palanca de retención del estado activo."},{"nombre":"Gestión de suscripciones / negative option compliance","tipo":"tercero","categoria":"Billing recurrente y autogestión de cancelación","ejemplos":["Chargebee","Recurly"],"nota":"Referencia de mercado de flujos de self-service de cancelación tan fáciles como el alta, fuera del vertical MLM."},{"nombre":"Procesamiento de pagos y reembolsos","tipo":"tercero","categoria":"Comercio y devoluciones","ejemplos":["Stripe Billing"],"nota":"Ejecuta el reembolso de forma trazable una vez aplicada la política publicada."}],"agentesYUseCase":[{"useCase":"Copiloto que explica al vendedor cómo editar o pausar su autoship y qué reembolso aplica si cancela.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — explica; el vendedor autogestiona","valor":"reduce las cancelaciones que terminan escalando a soporte por falta de claridad"},{"useCase":"Agente supervisado que anticipa el autoship perdido y propone la mejor acción de retención sin recurrir a fricción de cancelación.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — anticipa y propone; el humano decide la oferta","valor":"sostiene la retención por valor percibido en vez de por dificultad de salida"},{"useCase":"Exigo AI marca autoships perdidos semanas antes del churn, alimentando next-best-action de retención sin depender de reporting retrospectivo.","tipo":"tercero","nivelAutonomia":"agente supervisado (nivel 3)","ejemplos":["Exigo AI"],"valor":"convierte la pérdida de un autoship en una señal temprana de acción, no en un dato de cierre de mes"},{"useCase":"Agentes que correlacionan señales de autoship de toda la red para anticipar churn y priorizar intervenciones de retención de forma coordinada.","t
1ipo":"S4DS","nivelAutonomia":"multi-agente (nivel 4) — prioriza a escala; escalamiento por excepción","valor":"extiende la detección de riesgo por autoship perdido de un vendedor a la red completa"}],"metadata":{"evidenciaEsperada":"Evidencia de que la cancelación y edición del autoship es self-service, en el mismo canal y con la misma facilidad que el alta, más la política de reembolso publicada y alineada a los códigos del sector, y medición de cancelaciones self-service vs. gestionadas por soporte.","dolorAsociado":"Autoship diseñado como opción negativa difícil de cancelar (solo 'a través del patrocinador' o por teléfono): retención sostenida por fricción de salida y no por valor, con exposición regulatoria alta y reembolsos poco claros que erosionan la confianza del vendedor.","frenteRecomendacion":"Eficiencia/Simplificación de Proceso","fuente":"MASTER-C01 §8.8 (Autoship / negative option: la cancelación de autoship debe ser tan fácil como el alta y en el mismo canal; un CRM que solo permite cancelar 'a través de tu patrocinador' o por teléfono es un hallazgo de alto riesgo; enforcement bajo ROSCA y Section 5 tras la anulación de Click-to-Cancel), §2 (el autoship ligado a calificación de rango es la palanca dominante de retención del estado Activo), §10 (quick-win: cancelación de autoship self-service en el mismo canal del alta), §9 (autoship/suscripción como mecanismo de retención dominante, diseñado desde el día 1 como ancla de retención), §2 (buyback/recompra ≤12 meses a ≥90% del costo per DSA Code; piso global WFDSA Code of Ethics)"},"camposFaltantes":[]},{"practiceId":"C01-07-PR-06","processId":"C01","temaId":"c01-renovaciones-y-retencion-del-vinculo","nombre":"Medición y gestión proactiva de la retención: segmentación de riesgo de no-renovación y acción","pregunta":"¿Se mide la retención con métricas separadas y auditables (renovación anual vs. actividad mensual) y se gestiona el riesgo de no-renovación de forma proactiva —segmentando por indicadores tempranos y actuando antes del corte— en lugar de constatar la baja después de que ocurre?","enunciado":"La organización mide la retención con métricas separadas y auditables —tasa de renovación anual como evento binario distinto de la actividad mensual— y gestiona el riesgo de no-renovación de forma proactiva: segmenta a los vendedores por su probabilidad de no renovar usando indicadores tempranos de desvinculación (caída de volumen, autoship perdido, progresión estancada) y actúa antes del corte, en lugar de constatar la baja después de que ocurre. Las intervenciones de retención se priorizan por valor y riesgo, y su efecto sobre la renovación se mide, de modo que la retención es una disciplina gestionada con datos y no una consecuencia observada al cierre de cada ciclo.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 No se mide la retención de forma diferenciada ni se actúa antes del corte; la baja se constata cuando el vendedor ya no renovó."},{"nivel":1,"ancla":"1 Se revisa la retención de forma agregada y retrospectiva, sin segmentación de riesgo ni acción anticipada."},{"nivel":2,"ancla":"2 Hay algunas métricas de retención, pero se mezcla actividad mensual con renovación y la intervención es reactiva."},{"nivel":3,"ancla":"3 Retención medida con métricas separadas (renovación anual vs. actividad mensual) y segmentación de riesgo de no-renovación con acciones definidas antes del corte."},{"nivel":4,"ancla":"4 Gestionada; se mide el efecto de las intervenciones sobre la renovación y se priorizan por valor y riesgo con seguimiento del resultado."},{"nivel":5,"ancla":"5 Ningún modelo de riesgo o intervención de retención permanece vigente sin una revisión documentada de su impacto medido en la renovación."}]},"sistemas":{"referenciaMp":"§7 (reportar % activo mensual y % renovación como métricas separadas, nunca una como sustituto de la otra; modelar la ventana de 'activo' como campo configurable y auditable; leading indicators de churn), §10 (instrumentar leading indicators de churn como triggers de intervención)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; la retención no se mide de forma sistemática ni hay datos para segmentar el riesgo."},{"nivel":1,"ancla":"1 La retención se calcula a mano en una hoja al cierre del periodo, mezclando actividad y renovación."},{"nivel":2,"ancla":"2 Reporte especializado de retención agregada, sin indicadores tempranos ni segmentación de riesgo por vendedor."},{"nivel":3,"ancla":"3 Plataforma que separa las métricas (renovación vs. actividad) y expone indicadores tempranos de desvinculación por vendedor."}
1,{"nivel":4,"ancla":"4 Plataforma que calcula el riesgo de no-renovación en tiempo real y dispara intervenciones registradas de forma auditable."},{"nivel":5,"ancla":"5 Ecosistema donde señales de riesgo, intervención y resultado de renovación fluyen encadenados para recalibrar la gestión de retención sin intervención manual."}]},"agentico":{"referenciaMp":"§6 (predicción de churn + next-best-action, con evidencia de tres vendors independientes, es el caso de uso mejor documentado del vertical; Exigo AI marca autoships perdidos y progresión estancada semanas antes del churn)","anclas":[{"nivel":0,"ancla":"0 Sin IA; predecir quién no renovará y por qué es manual, si es que se intenta."},{"nivel":1,"ancla":"1 Alertas por regla fija cuando un indicador simple (p. ej. autoship perdido) se cumple."},{"nivel":2,"ancla":"2 Copiloto que responde qué vendedores están en riesgo de no renovar según reglas consultables."},{"nivel":3,"ancla":"3 Agente supervisado que predice el riesgo de no-renovación por vendedor y propone la mejor acción de retención para revisión."},{"nivel":4,"ancla":"4 Agentes que combinan volumen, autoship, progresión y comportamiento para anticipar el churn y priorizar intervenciones de retención de forma coordinada 24/7."},{"nivel":5,"ancla":"5 Gestión de retención autónoma dentro de políticas que activa intervenciones segmentadas al detectar riesgo y aprende del resultado, con escalamiento por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Tablero de retención con métricas separadas","tipo":"S4DS","categoria":"Analítica de retención / ciclo de vida","coberturaS4DS":"renovación anual vs. actividad mensual como campos independientes y auditables · MCP retention-metrics tools","nota":"Evita que la actividad mensual se reporte como sustituto de la tasa de renovación real."},{"nombre":"S4DS — Motor de segmentación de riesgo de no-renovación","tipo":"S4DS","categoria":"Predicción de churn / leading indicators","coberturaS4DS":"score de riesgo por vendedor a partir de volumen, autoship y progresión · trigger de intervención antes del corte","nota":"Convierte leading indicators dispersos en un score único que dispara acción antes de la baja."},{"nombre":"Predicción de churn + next-best-action (vendors de industria)","tipo":"tercero","categoria":"Analítica predictiva de retención en venta directa","ejemplos":["Exigo AI","Rallyware","Epixel"],"nota":"El caso de uso mejor documentado del vertical, con evidencia pública de tres vendors independientes; cifras de impacto sin auditoría independiente."},{"nombre":"BI / dashboards de retención","tipo":"tercero","categoria":"Visualización y reporting ejecutivo","ejemplos":["Power BI","Tableau","Looker"],"nota":"Expone la tasa de renovación separada de la actividad mensual al nivel ejecutivo que decide inversión en retención."},{"nombre":"Marketing automation para intervenciones disparadas","tipo":"tercero","categoria":"Ejecución de campañas de retención","ejemplos":["Klaviyo","Braze"],"nota":"Ejecuta la intervención priorizada por riesgo/valor una vez que el score la dispara."}],"agentesYUseCase":[{"useCase":"Copiloto que responde qué vendedores están en riesgo de no renovar según reglas e indicadores consultables.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — consulta y explica; el humano decide la intervención","valor":"hace visible el riesgo de no-renovación sin esperar al reporte de cierre de ciclo"},{"useCase":"Agente supervisado que predice el riesgo de no-renovación por vendedor y propone la mejor acción de retención para revisión humana.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — predice y propone; el humano aprueba la acción","valor":"adelanta la intervención al momento en que aún puede cambiar el resultado, no después del corte"},{"useCase":"Predicción de churn + next-best-action, con evidencia de tres vendors independientes, marcando anomalías como progresión estancada o autoships perdidos semanas antes del churn.","tipo":"tercero","nivelAutonomia":"agente supervisado (nivel 3)","ejemplos":["Exigo AI","Rallyware","Epixel"],"valor":"el caso de uso mejor documentado del vertical para anticipar la no-renovación con antelación real"},{"useCase":"Agentes que combinan volumen, autoship, progresión de rango y comportamiento para anticipar el churn y priorizar intervenciones de retención de forma coordinada 24/7 en toda la red.","tipo":"S4DS","nivelAutonomia":"multi-agente (nivel 4) — prioriza a escala continua; escalamiento por excepción","valor":"sostiene la gestión proactiva de la retención sin depender de revisiones periódicas manuales"},{"useCase":"Gestión de retención autónoma dentro de políticas, que activa intervenciones segmentadas al detectar riesgo y aprende del resultado medido, con escalamiento de casos límite.","tipo":"S4DS","nivelAutonomia":"autónomo (nivel 5) — actúa dentro de políticas; escalamiento por excepción","valor":"cierra el lazo completo entre detección, intervención y recalibración sin intervención manual recurrente"}],"metadata":{"evidenciaEsperada":"Tablero o reporte de retención con la tasa de renovación anual separada de la actividad mensual, la segmentación de riesgo de no-renovación por indicadores tempranos, y evidencia de intervenciones ejecutadas antes del corte con medición de su efecto.","dolorAsociado":"Retención constatada solo al cierre del ciclo, cuando la baja ya ocurrió: sin métricas separadas la 'tasa de activos' enmascara la no-renovación, y sin indicadores tempranos ni segmentación de riesgo las intervenciones llegan tarde y n
1o se priorizan por valor.","frenteRecomendacion":"Modelos Agénticos/IA","fuente":"MASTER-C01 §6 (predicción de churn + next-best-action es, con evidencia de tres vendors independientes, el caso de uso mejor documentado del vertical; Exigo AI marca anomalías como progresión de rango estancada o autoships perdidos semanas antes del churn), §7 (reportar % activo mensual y % renovación como métricas separadas, nunca una como sustituto de la otra; la re-calificación/renovación anual es el proxy de retención dura más limpio; instrumentar leading indicators —TTFO, primera venta, primer reorder— como triggers de intervención), §10 (instrumentar leading indicators de churn como triggers de intervención, no reporting retrospectivo), §8.4 (el cuello de botella es que las plataformas legacy no instrumentan leading indicators como triggers de intervención, sino attrition retrospectiva agregada)"},"camposFaltantes":[]},{"practiceId":"C01-08-PR-01","processId":"C01","temaId":"c01-terminacion-offboarding-y-buyback","nombre":"Iniciación diferenciada de la baja: voluntaria (self-service) y forzosa (por causa/compliance)","pregunta":"¿La baja se inicia por flujos diferenciados según su origen —voluntaria (solicitud self-service del vendedor) y forzosa (por causa/compliance con su decisor)—, cada uno con su disparador, aprobaciones y efectos, en lugar de un único camino indistinto o un trámite ad-hoc?","enunciado":"La organización inicia la salida del vendedor mediante flujos diferenciados según su origen —una baja voluntaria que el vendedor puede solicitar de forma directa y una terminación forzosa por causa o compliance que sigue la ruta de enforcement con su decisor—, cada uno con su disparador, sus aprobaciones y sus efectos definidos, en lugar de un único camino indistinto o de un trámite resuelto caso por caso. El origen de la baja determina el flujo, de modo que la renuncia voluntaria no queda atrapada en fricción y la terminación por causa no se ejecuta sin las aprobaciones que exige.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 No hay proceso de baja definido; la salida de un vendedor se maneja caso por caso sin distinguir si es voluntaria o forzosa."},{"nivel":1,"ancla":"1 La baja se tramita informalmente y depende de a quién se le pida; no hay flujo distinto para la renuncia voluntaria y la terminación por causa."},{"nivel":2,"ancla":"2 Existe un trámite de baja repetible pero uno solo, sin diferenciar la solicitud voluntaria de la terminación forzosa ni sus aprobaciones."},{"nivel":3,"ancla":"3 Flujos de baja diferenciados y documentados: voluntaria (solicitud del vendedor) y forzosa (por causa/compliance), cada uno con disparador, aprobaciones y decisor definidos."},{"nivel":4,"ancla":"4 Flujos gestionados; se mide el tiempo y la completitud de cada tipo de baja y se detectan salidas tramitadas fuera del flujo que corresponde."},{"nivel":5,"ancla":"5 Ninguna regla de iniciación de baja permanece vigente sin una revisión documentada contra los motivos y patrones de baja observados en el periodo anterior."}]},"sistemas":{"referenciaMp":"§2.9 (Terminación como hand-off multi-departamental legal/finanzas/field), §4 (2.9: IT en cierre/portabilidad), §10 (máquina de estados event-driven con terminación como transición gobernada)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; la baja se solicita por correo o teléfono y se tramita a mano."},{"nivel":1,"ancla":"1 La solicitud de baja se registra en hoja de cálculo o formulario suelto, sin distinguir el tipo ni disparar el flujo."},{"nivel":2,"ancla":"2 Software especializado que registra la baja pero con un único flujo, sin diferenciar voluntaria de forzosa ni encadenar aprobaciones."},{"nivel":3,"ancla":"3 Plataforma que ofrece una baja voluntaria self-service y un flujo de terminación forzosa con las aprobaciones que cada uno requiere."},{"nivel":4,"ancla":"4 Plataforma que ejecuta ambos flujos con estados y aprobaciones auditables en tiempo real y bloquea saltos fuera del camino que corresponde."},{"nivel":5,"ancla":"5 Ecosistema donde la iniciación de la baja dispara de forma encadenada los efectos downstream (recompra, cierre de accesos, genealogía) sin trámite manual."}]},"agentico":{"referenciaMp":"§6 (predicción de churn/próximo estado + next-best-action, caso mejor documentado del vertical)","anclas":[{"nivel":0,"ancla":"0 Sin IA; nadie anticipa qué vendedores están por solicitar la baja ni qué casos deben escalar a terminación forzosa."},{"nivel":1,"ancla":"1 Alertas por regla fija cuando se recibe una solicitud de baja o cuando un caso de compliance cruza un umbral."},{"nivel":2,"ancla":"2 Copiloto que orienta al vendedor o al operador sobre los pasos y requisitos de cada tipo de baja."},{"nivel":3,"ancla":"3 Agente supervisado que clasifica la baja entrante (voluntaria/forzosa), la enruta al flujo y decisor correctos y señala requisitos pen
1dientes."},{"nivel":4,"ancla":"4 Agentes que correlacionan señales de comportamiento y compliance para anticipar bajas y coordinar su enrutamiento de forma continua."},{"nivel":5,"ancla":"5 Orquestación autónoma dentro de políticas que inicia y enruta la baja según el caso, con escalamiento por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Motor de estados y flujos de offboarding","tipo":"S4DS","categoria":"Orquestación de ciclo de vida / máquina de estados","coberturaS4DS":"módulo Ciclo de Vida · flujos diferenciados de baja voluntaria/forzosa · MCP offboarding/state tools","nota":"Enruta la baja al flujo, aprobaciones y decisor correctos según su origen, sin trámite manual indistinto."},{"nombre":"DMS / plataforma núcleo del sector","tipo":"tercero","categoria":"Distributor Management System (registro de baja y aprobaciones)","ejemplos":["Exigo","DirectScale","ByDesign (Freedom)","Epixel"],"nota":"Sistemas núcleo del sector que registran la solicitud de baja y encadenan aprobaciones cuando el flujo está configurado como tal, no como trámite único."},{"nombre":"Case management / workflow de compliance","tipo":"tercero","categoria":"Gestión de casos y escalamiento","ejemplos":["ServiceNow","Zendesk"],"nota":"Para el flujo de terminación forzosa —escalamiento, aprobaciones documentadas, decisor asignado— cuando el DMS no cubre nativamente la orquestación de compliance."}],"agentesYUseCase":[{"useCase":"Clasificador/enrutador de la baja: determina si la solicitud entrante es voluntaria o forzosa a partir de su origen y señales, y la enruta al flujo, aprobaciones y decisor correctos.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — enruta y señala pendientes, humano confirma casos límite","valor":"evita que una baja se tramite por el camino que no le corresponde"},{"useCase":"Copiloto de autoservicio: guía al vendedor que solicita la baja voluntaria por los pasos y requisitos sin intervención humana.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — sugiere y guía, humano decide en excepciones","valor":"mantiene la baja voluntaria de baja fricción sin depender de que alguien la 'gestione'"},{"useCase":"Predicción de próxima baja / next-best-action (patrón Rallyware/Exigo AI): anticipa señales de abandono o de riesgo de compliance antes de que se solicite formalmente la baja.","tipo":"tercero","nivelAutonomia":"agente supervisado (nivel 3)","ejemplos":["Rallyware Intelligent Field Orchestration","Exigo AI"],"valor":"caso de uso mejor documentado del vertical; permite preparar el flujo correcto antes de que la baja ocurra"}],"metadata":{"evidenciaEsperada":"Definición documentada de los flujos de baja voluntaria (self-service) y forzosa (por causa/compliance) con sus disparadores, aprobaciones y decisor, más evidencia de bajas recientes tramitadas por el flujo que les corresponde.","dolorAsociado":"Salidas manejadas caso por caso sin distinguir renuncia voluntaria de terminación por causa: la voluntaria queda atrapada en fricción manual y la forzosa se ejecuta sin las aprobaciones ni el decisor que exige, exponiendo a la compañía en una salida disputada.","frenteRecomendacion":"Eficiencia/Simplificación de Proceso","fuente":"MASTER-C01 §2.9 (Terminación: hand-off multi-departamental legal/finanzas/field —recompra, clawback, reasignación de downline), §3 (RACI de Terminación: Compliance + Legal responsible, Comité de Compliance/General Counsel accountable; escalamiento progresivo llamada de cortesía → carta de advertencia → suspensión → terminación, con enfoque de educar antes de sancionar), §2 (offboarding como parte de la máquina de estados; baja por volumen, pagos y flags de compliance)"},"camposFaltantes":[]},{"practiceId":"C01-08-PR-02","processId":"C01","temaId":"c01-terminacion-offboarding-y-buyback","nombre":"Recompra (buyback) ≥90% ejecutable en sistema y ofrecida proactivamente a todo vendedor que termina y califica","pregunta":"¿La recompra (≥90% del costo neto del inventario revendible y kit, dentro del plazo) se ofrece de forma proactiva a todo vendedor que termina y califica y se ejecuta como flujo en sistema reservado desde el alta, en lugar de una cláusula que el vendedor debe descubrir y reclamar?","enunciado":"La organización opera una política de recompra que ofrece de forma proactiva —a todo vendedor que termina y califica— la recompra del inventario revendible y del kit a un mínimo del 90% del costo neto dentro del plazo definido, como un flujo ejecutable y financieramente reservado desde el alta, en lugar de una cláusula que existe en el contrato pero que en la práctica el vendedor debe descubrir y reclamar. La oferta se emite proactivamente al calificar la terminación, y su cálculo y liquidación quedan registrados, de modo que la recompra cumple el piso que fijan los códigos de ética del sector y los requisitos legales aplicables sin depender de la iniciativa del vendedor.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 No hay política de recompra operativa; si un vendedor pide que le recompren el inventario se resuelve caso por caso o no se resuelve."},{"nivel":1,"ancla":"1 Existe una cláusula de recompra en el contrato pero se aplica solo si el vendedor la reclama y a criterio de quien la atienda."},{"nivel":2,"ancla":"2 Política de recompra escrita (≥90%/plazo) pero de aplicación reactiva; no se ofrece proactivamente ni de forma consistente a quien califica."},{"nivel":3,"ancla":"3 Política definida que se OFRECE proactivamente a todo vendedor que termina y califica, con el cálculo (≥90% del costo neto) y el plazo documentados."},{"nivel":4,"ancla":"4 Recompra gestionada; se mide la cobertura de la oferta y el cumplimiento del plazo y del porcentaje, y se detectan casos que c
1alificaban y no recibieron oferta."},{"nivel":5,"ancla":"5 Ninguna terminación que califica para recompra queda sin la oferta proactiva: el cumplimiento del porcentaje, el plazo y la alineación con los requisitos legales estatales se audita al 100% de los casos, no por muestreo."}]},"sistemas":{"referenciaMp":"§2.4 (recompra ≥90% como salvaguarda anti-inventory-loading; flujo de recompra pre-configurado y financieramente reservado desde el día 1), §10 quick-win (publicar y operativizar la buyback policy ≥90%/12 meses como flujo ejecutable en sistema, no manual)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; la recompra, si ocurre, se calcula y liquida a mano sin registro estructurado."},{"nivel":1,"ancla":"1 El cálculo de la recompra se hace en hoja de cálculo cuando alguien lo solicita, sin reserva financiera ni trazabilidad."},{"nivel":2,"ancla":"2 Software especializado que registra la solicitud de recompra pero no la ofrece automáticamente ni la liquida de forma integrada."},{"nivel":3,"ancla":"3 Plataforma con un flujo de recompra que calcula el ≥90% del costo neto del inventario elegible y lo dispara al calificar la terminación."},{"nivel":4,"ancla":"4 Plataforma que ejecuta la recompra con reserva financiera desde el alta, la ofrece automáticamente a quien califica y audita el porcentaje y el plazo en tiempo real."},{"nivel":5,"ancla":"5 Ecosistema donde la terminación dispara la oferta, el cálculo y la liquidación de la recompra encadenados con inventario, finanzas y comisiones, sin trámite manual."}]},"agentico":{"referenciaMp":"§6 (detección de anomalías sobre el ciclo de vida; asistencia sobre elegibilidad y cálculo)","anclas":[{"nivel":0,"ancla":"0 Sin IA; identificar quién califica para recompra y qué inventario es elegible es manual."},{"nivel":1,"ancla":"1 Alertas por regla fija cuando una terminación podría calificar para recompra."},{"nivel":2,"ancla":"2 Copiloto que explica al vendedor o al operador qué inventario es recomprable y cuánto correspondería."},{"nivel":3,"ancla":"3 Agente supervisado que determina la elegibilidad y calcula la oferta de recompra para revisión antes de emitirla."},{"nivel":4,"ancla":"4 Agentes que cruzan inventario, terminaciones y requisitos por jurisdicción para asegurar que toda terminación que califica reciba la oferta de forma continua."},{"nivel":5,"ancla":"5 Gestión autónoma dentro de políticas de la oferta y el cálculo de recompra, con escalamiento de casos límite."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Recompra/Buyback con reserva financiera desde el alta","tipo":"S4DS","categoria":"Motor de recompra y reserva financiera","coberturaS4DS":"módulo Recompra · reserva financiera desde el alta · disparo automático al calificar terminación · MCP buyback/inventory tools","nota":"Calcula y dispara la oferta de recompra (≥90% del costo neto) de forma proactiva sin depender de que el vendedor la reclame."},{"nombre":"DMS / plataforma núcleo del sector","tipo":"tercero","categoria":"Distributor Management System (inventario y comisiones)","ejemplos":["Exigo","Epixel","DirectScale"],"nota":"Sistemas del sector donde vive el registro de inventario adquirido por el vendedor, insumo para determinar qué es 'revendible' y elegible a recompra."},{"nombre":"Inventory / WMS","tipo":"tercero","categoria":"Gestión de inventario y devoluciones","ejemplos":["SAP EWM","Oracle WMS","Manhattan Associates"],"nota":"Valida el estado (revendible/no revendible) del inventario devuelto antes de liquidar el porcentaje de recompra."},{"nombre":"Payout / e-wallet y cuentas por pagar","tipo":"tercero","categoria":"Liquidación de pagos y reembolsos","ejemplos":["Tipalti","Trolley","módulo de cuentas por pagar del ERP"],"nota":"Ejecuta el desembolso o crédito de la recompra al vendedor terminado de forma trazable."}],"agentesYUseCase":[{"useCase":"Determinador de elegibilidad y cálculo de oferta: identifica automáticamente qué terminaciones califican para recompra y calcula el monto (≥90% del costo neto) sobre el inventario elegible.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — calcula, humano revisa antes de emitir en casos límite","valor":"garantiza que ninguna terminación que califica quede sin oferta"},{"useCase":"Emisor proactivo de la oferta de recompra: dispara automáticamente la comunicación de la oferta al vendedor en el momento en que la terminación califica.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3)","valor":"elimina la dependencia de que el vendedor descubra y reclame la cláusula"},{"useCase":"Auditor de cobertura y cumplimiento: cruza terminaciones, inventario y requisitos por jurisdicción (estados que exigen ≥90% por ley) para detectar casos que c
1alificaban y no recibieron oferta.","tipo":"tercero","nivelAutonomia":"agente supervisado (nivel 3-4)","ejemplos":["herramientas de GRC / compliance analytics"],"valor":"cierra la brecha de exposición legal tipo LuLaRoe antes de que se convierta en litigio"}],"metadata":{"evidenciaEsperada":"Política de recompra publicada (≥90% del costo neto, plazo ≤12 meses) con evidencia de que se ofrece proactivamente a todo vendedor que termina y califica y de que la recompra se calcula y liquida como flujo en sistema con reserva financiera.","dolorAsociado":"Recompra que existe en el contrato pero que el vendedor debe descubrir y reclamar: su ausencia práctica fue exactamente lo litigado en el sector (caso LuLaRoe, US$4.75M) y varios estados la exigen por ley ≥90%, por lo que no ofrecerla proactivamente es exposición legal directa, no una ineficiencia.","frenteRecomendacion":"Gobierno/Roles/Tercerización","fuente":"MASTER-C01 §2 (offboarding es la mayor exposición legal: el buyback debe ofrecerse a TODO vendedor que termina y califica, con proceso eficiente y publicado; su ausencia práctica fue lo litigado en LuLaRoe —US$4.75M, AG Washington 2022—; al menos seis estados —Georgia, Louisiana, Massachusetts, Maryland, Puerto Rico, Wyoming— exigen recompra ≥90% por ley; el Código de Ética de la DSA exige recompra ≤12 meses a ≥90% del costo y el WFDSA Code of Ethics sept-2025 fija el piso global), §2.4 (recompra ≥90% como salvaguarda Amway/FTC 1979 junto con la regla del 70% y la de 10 clientes; flujo de recompra pre-configurado y financieramente reservado desde el día 1), §8.2 (una política de buyback no blinda un diseño que premia reclutamiento sobre venta), §10 quick-win (publicar y operativizar la buyback policy ≥90%/12 meses como flujo ejecutable en sistema; medir % kits recomprados en 90 días)"},"camposFaltantes":[]},{"practiceId":"C01-08-PR-03","processId":"C01","temaId":"c01-terminacion-offboarding-y-buyback","nombre":"Reconciliación financiera del cierre: comisiones pendientes, deudas, monedero electrónico y clawbacks","pregunta":"¿La terminación ejecuta una reconciliación financiera de cierre que salda en un único corte conciliado y auditable las comisiones pendientes, las deudas, el saldo del monedero electrónico y los clawbacks, en lugar de dejar saldos abiertos que se disputan después?","enunciado":"La organización ejecuta, como parte de la terminación, una reconciliación financiera completa del cierre que salda en un único corte las comisiones y bonos pendientes, las deudas del vendedor con la compañía, el saldo del monedero electrónico y los clawbacks aplicables (por fraude o por devoluciones), en lugar de dejar saldos abiertos que se descubren y disputan meses después. El resultado es un estado de cuenta de cierre conciliado y auditable que determina el pago o cobro neto final y deja sin saldos vivos la relación económica con el vendedor.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 No hay reconciliación de cierre; al terminar quedan saldos abiertos (comisiones, deudas, wallet) que nadie concilia."},{"nivel":1,"ancla":"1 El cierre financiero se hace a mano y de forma inconsistente; a veces se saldan las comisiones, a veces se olvidan las deudas o el clawback."},{"nivel":2,"ancla":"2 Existe una rutina de cierre repetible pero parcial; no cubre de forma consistente comisiones, deudas, wallet y clawbacks en un mismo corte."},{"nivel":3,"ancla":"3 Reconciliación de cierre definida que salda en un corte comisiones/bonos pendientes, deudas, saldo de wallet y clawbacks, con estado de cuenta final."},{"nivel":4,"ancla":"4 Reconciliación gestionada; se mide que ningún cierre deje saldos abiertos y se auditan las diferencias entre lo calculado y lo liquidado."},{"nivel":5,"ancla":"5 Ningún cierre deja saldos abiertos sin explicar: los patrones recurrentes de saldo pendiente y clawback se corrigen en el proceso que los origina, no solo en la reconciliación del cierre."}]},"sistemas":{"referenciaMp":"§2.9 (clawback de comisiones si hubo fraude como parte del hand-off de terminación), §5 (integración ERP/CRM; DMS como sistema de registro de la comisión que sincroniza hacia ERP; evitar la fragmentación de fuente de verdad)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; los saldos del vendedor viven en sistemas separados que nadie concilia al cerrar."},{"nivel":1,"ancla":"1 El cierre financiero se arma en hoja de cálculo cruzando reportes de comisiones, deudas y wallet a mano."},{"nivel":2,"ancla":"2 Software especializado por concepto (comisiones, wallet, cuentas por cobrar) sin integración; se reconcilian manualmente al cierre."},{"nivel":3,"ancla":"3 Plataforma que consolida comisiones, deudas, wallet y clawbacks del vendedor y produce el estado de cuenta de cierre."}
1,{"nivel":4,"ancla":"4 Plataforma integrada con finanzas/ERP que calcula el neto de cierre en tiempo real y lo deja auditable con su desglose."},{"nivel":5,"ancla":"5 Ecosistema donde la terminación dispara la reconciliación de cierre encadenada entre comisiones, wallet, cuentas por cobrar y ERP, sin conciliación manual."}]},"agentico":{"referenciaMp":"§6 (detección de anomalías de comisión; Exigo AI marca autoships perdidos y progresión estancada como señales que anteceden ajustes)","anclas":[{"nivel":0,"ancla":"0 Sin IA; detectar saldos pendientes o clawbacks aplicables al cerrar es manual y tardío."},{"nivel":1,"ancla":"1 Alertas por regla fija cuando una terminación tiene comisiones o deudas pendientes."},{"nivel":2,"ancla":"2 Copiloto que resume los saldos abiertos del vendedor a pedido al iniciar el cierre."},{"nivel":3,"ancla":"3 Agente supervisado que arma el estado de cuenta de cierre (comisiones, deudas, wallet, clawbacks) para revisión antes de liquidar."},{"nivel":4,"ancla":"4 Agentes que correlacionan comisiones, devoluciones y fraude para calcular clawbacks y el neto de cierre de forma continua."},{"nivel":5,"ancla":"5 Reconciliación de cierre autónoma dentro de políticas, con liquidación del neto y escalamiento de casos disputados."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Reconciliación de cierre financiero","tipo":"S4DS","categoria":"Cierre financiero / conciliación multi-concepto","coberturaS4DS":"módulo Comisiones + Finanzas · estado de cuenta de cierre consolidado (comisiones, deudas, wallet, clawbacks) · MCP reconciliation tools","nota":"Consolida en un único corte lo que hoy vive fragmentado entre motor de comisiones, cuentas por cobrar y wallet."},{"nombre":"Motor de comisiones del DMS","tipo":"tercero","categoria":"Cálculo y liquidación de comisiones","ejemplos":["Exigo (Exigo AI)","DirectScale","Epixel"],"nota":"Fuente de las comisiones y bonos devengados que entran al corte de cierre; Exigo AI marca anomalías de comisión que pueden anteceder un ajuste o clawback."},{"nombre":"ERP financiero","tipo":"tercero","categoria":"Sistema financiero de registro","ejemplos":["SAP","Oracle NetSuite","Microsoft Dynamics 365"],"nota":"Fuente contable de deudas y cuentas por cobrar del vendedor; debe sincronizarse con el DMS para evitar una segunda verdad divergente en el cierre."},{"nombre":"Payout / e-wallet processor","tipo":"tercero","categoria":"Liquidación de saldo de monedero electrónico","ejemplos":["Tipalti","Trolley","Papaya Global"],"nota":"Liquida o retiene el saldo del wallet del vendedor terminado como parte del neto de cierre."}],"agentesYUseCase":[{"useCase":"Armador del estado de cuenta de cierre: agente que consolida automáticamente comisiones pendientes, deudas, wallet y clawbacks de una terminación en un único estado de cuenta para revisión antes de liquidar.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — arma el estado de cuenta, humano liquida","valor":"elimina el cruce manual de reportes entre sistemas al cerrar una salida"},{"useCase":"Detector de anomalías de comisión y clawback (patrón Exigo AI): correlaciona devoluciones, fraude y progresión de comisión para calcular el clawback aplicable antes del cierre.","tipo":"tercero","nivelAutonomia":"agente supervisado (nivel 3)","ejemplos":["Exigo AI"],"valor":"evita clawbacks descubiertos tarde que obligan a reabrir un cierre ya liquidado"},{"useCase":"Copiloto de resumen de saldos: presenta al operador de finanzas los saldos abiertos de un vendedor al iniciar el proceso de cierre.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2)","valor":"acelera el armado del cierre sin reemplazar la decisión de liquidación"}],"metadata":{"evidenciaEsperada":"Estado de cuenta de cierre de terminaciones recientes mostrando el saldo conciliado de comisiones/bonos pendientes, deudas, monedero electrónico y clawbacks, y el pago o cobro neto final auditable.","dolorAsociado":"Terminaciones que dejan saldos abiertos —comisiones sin pagar, deudas sin cobrar, wallet sin liquidar, clawbacks sin aplicar— que se descubren meses después y derivan en disputas, ajustes retroactivos y reclamos difíciles de defender sin un cierre conciliado.","frenteRecomendacion":"Tecnología e Integración","fuente":"MASTER-C01 §2.9 (Terminación como hand-off multi-departamental legal/finanzas/field: recompra, clawback de comisiones si hubo fraude, reasignación de downline), §3 (RACI de Terminación: Finance consulted en la liquidación), §5 (el riesgo típico es la fragmentación de fuente de verdad; DMS como sistema de registro de la relación vendedor-compañía —incluida la comisión— que sincroniza unidireccionalmente hacia ERP), §8.9 (retención fiscal y screening OFAC en el pago que impactan el neto liquidable en el cierre)"},"camposFaltantes":[]},{"practiceId":"C01-08-PR-04","processId":"C01","temaId":"c01-terminacion-offboarding-y-buyback","nombre":"Cierre y revocación completa de accesos: back-office, sitios replicados, apps, pago e identidad","pregunta":"¿La terminación revoca de forma completa y en el momento del cambio de estado todos los accesos y credenciales del vendedor —back-office, sitios replicados, apps, pago/wallet e identidad autorizada—, en lugar de dejar accesos vivos que permiten seguir operando tras la salida?","enunciado":"La organización revoca, como parte de la terminación, todos los accesos y credenciales del vendedor —back-office, sitios web replicados, aplicaciones, método de pago/monedero y cualquier identidad autorizada a hacer afirmaciones de producto o de ingresos— en el momento en que el estado cambia a terminado y de forma completa, en lugar de dejar accesos vivos que permiten seguir operando o comunicando en nombre de la compañía tras la salida. El cierre de accesos es verificable y queda registrado, de modo que ningún acceso residual sobrevive a la terminación.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 No hay cierre de accesos definido; tras la terminación el vendedor puede seguir entrando al back-office o a su sitio replicado."},{"nivel":1,"ancla":"1 El cierre de accesos se hace a mano y de forma incompleta; se revoca lo que alguien recuerda revocar."},{"nivel":2,"ancla":"2 Existe una lista de accesos a cerrar pero se aplica parcialmente y sin verificar que queden todos revocados."},{"nivel":3,"ancla":"3 Cierre de accesos definido que revoca back-office, sitios replicados, apps, wallet e identidad al pasar a terminado, con checklist verificable."},{"nivel":4,"ancla":"4 Cierre gestionado; se mide que ningún acceso quede vivo tras la terminación y se detectan y corrigen credenciales no revocadas."},{"nivel":5,"ancla":"5 Cierre optimizado; la revocación se dispara en origen con el cambio de estado y se previene cualquier acceso residual sin intervención."}]},"sistemas":{"referenciaMp":"§4 (2.9 Terminación: IT en cierre/portabilidad), §5 (compliance gating de sitios replicados; DMS como sistema de registro del estado), §2.3 (el estado de terminación debe ser verificable externamente —patrón 'delisted' de India)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; no hay forma sistemática de cortar los accesos de un vendedor terminado."},{"nivel":1,"ancla":"1 Los accesos se dan de baja a mano en cada sistema por separado, sin garantía de completitud."},{"nivel":2,"ancla":"2 Software especializado donde se desactiva la cuenta, pero los sitios replicados, apps o wallet siguen en otros sistemas no conectados."}
1,{"nivel":3,"ancla":"3 Plataforma donde el cambio a terminado revoca los accesos del vendedor (back-office, sitio replicado, wallet) de forma coordinada."},{"nivel":4,"ancla":"4 Plataforma que revoca y verifica en tiempo real todos los accesos al terminar y expone el estado terminado a los sistemas que dependen de él."},{"nivel":5,"ancla":"5 Ecosistema donde el estado terminado propaga la revocación de accesos a todas las capas (back-office, réplicas, pago, identidad) sin corte manual."}]},"agentico":{"referenciaMp":"§6 (detección de anomalías; vigilancia de actividad post-terminación)","anclas":[{"nivel":0,"ancla":"0 Sin IA; verificar que no quede ningún acceso vivo tras una terminación es manual."},{"nivel":1,"ancla":"1 Alertas por regla fija cuando un vendedor terminado registra actividad de acceso."},{"nivel":2,"ancla":"2 Copiloto que lista los accesos y credenciales asociados a un vendedor al iniciar el cierre."},{"nivel":3,"ancla":"3 Agente supervisado que verifica la revocación completa de accesos tras la terminación y señala credenciales residuales."},{"nivel":4,"ancla":"4 Agentes que vigilan de forma continua accesos y actividad post-terminación en todos los sistemas para detectar residuos de forma coordinada."},{"nivel":5,"ancla":"5 Revocación y verificación de accesos autónoma dentro de políticas, con escalamiento de accesos residuales por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Revocación de accesos ligada al estado","tipo":"S4DS","categoria":"Gestión de accesos / identidad ligada a la máquina de estados","coberturaS4DS":"módulo Ciclo de Vida · revocación coordinada al cambio a terminado (back-office, sitio replicado, wallet) · MCP access-revocation tools","nota":"Dispara y verifica la revocación de todos los accesos del vendedor en el momento del cambio de estado, sin depender de tareas manuales por sistema."},{"nombre":"IAM / identity governance","tipo":"tercero","categoria":"Gestión de identidad y accesos","ejemplos":["Okta","SailPoint","Auth0","Microsoft Entra ID"],"nota":"Coordina la desactivación de credenciales de un vendedor a través de todos los sistemas que federan su identidad, no solo el DMS principal."},{"nombre":"Sitios replicados / storefront del vendedor","tipo":"tercero","categoria":"Plataforma de sitio replicado","ejemplos":["Exigo storefronts","Epixel replicated website","DirectScale"],"nota":"Sistema donde el sitio del vendedor debe despublicarse o pasar a inaccesible al terminar; Epixel expone áreas editables controladas que deben bloquearse en el cierre."},{"nombre":"Payment / wallet provider","tipo":"tercero","categoria":"Desactivación de método de pago y monedero","ejemplos":["Tipalti","Trolley"],"nota":"Recibe la señal de terminación para congelar el método de pago o wallet del vendedor."}],"agentesYUseCase":[{"useCase":"Verificador de revocación completa: agente que confirma, tras cada terminación, que back-office, sitio replicado, app y wallet quedaron efectivamente revocados y señala credenciales residuales.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3)","valor":"cierra la brecha entre 'se intentó revocar' y 'se revocó verificablemente'"},{"useCase":"Vigilancia de actividad post-terminación: monitorea de forma continua intentos de acceso o actividad de un vendedor ya terminado en cualquier sistema.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3)","valor":"detecta accesos residuales o intentos de uso indebido antes de que generen exposición"},{"useCase":"Copiloto de checklist de cierre: presenta al operador de IT o compliance la lista de accesos asociados a un vendedor al iniciar el proceso de terminación.","tipo":"tercero","nivelAutonomia":"copiloto (nivel 2)","ejemplos":["flujos de IT service management (p.ej. ServiceNow)"],"valor":"reduce el riesgo de olvidar un sistema en el cierre manual"}],"metadata":{"evidenciaEsperada":"Checklist o registro de cierre de accesos de terminaciones recientes mostrando la revocación verificada de back-office, sitios replicados, apps, método de pago/wallet e identidad, con timestamp y responsable.","dolorAsociado":"Acce
1sos que quedan vivos tras la salida: el vendedor terminado sigue entrando al back-office, su sitio replicado sigue publicado o su identidad sigue autorizada a hacer afirmaciones de ingresos, generando exposición regulatoria y operativa post-terminación.","frenteRecomendacion":"Tecnología e Integración","fuente":"MASTER-C01 §2.9 (el ciclo no termina limpiamente en 'cuenta cerrada'; los mensajes de earnings publicados durante la actividad generan exposición post-terminación), §4 (2.9 Terminación: IT responsable de cierre/portabilidad), §5 (compliance gating de sitios replicados con campos editables limitados; DMS como sistema de registro del estado del vendedor), §2.3 (India: registro público de vendedores 'delisted' consultable —el estado de terminación debe ser verificable externamente)"},"camposFaltantes":[]},{"practiceId":"C01-08-PR-05","processId":"C01","temaId":"c01-terminacion-offboarding-y-buyback","nombre":"Reestructuración de la genealogía al salir: roll-up permanente y comunicación a downline y upline","pregunta":"¿La salida de un vendedor dispara la reestructuración de la genealogía con la regla de roll-up permanente definida y la comunicación a la downline reasignada y al upline impactado, en lugar de dejar un nodo huérfano o reasignar caso por caso?","enunciado":"La organización reestructura la genealogía cuando un vendedor sale, aplicando la regla de roll-up permanente definida —que mueve de forma definitiva a la downline afectada hacia el upline calificado que corresponde— y comunica el cambio tanto a la downline reasignada como al upline impactado, en lugar de dejar un nodo huérfano o resolver la reasignación caso por caso. La reestructuración preserva la integridad de la genealogía y su efecto sobre las comisiones queda registrado y es explicable a los afectados, con la aprobación y trazabilidad que exige un cambio de estructura.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 No hay reestructuración definida al salir; la downline de un vendedor terminado queda huérfana o se reasigna sin criterio."},{"nivel":1,"ancla":"1 La reasignación de la downline al salir se hace caso por caso, según lo decida quien atiende la terminación."},{"nivel":2,"ancla":"2 Existe una noción de roll-up al salir pero no está documentada como regla ni se comunica de forma consistente a los afectados."},{"nivel":3,"ancla":"3 Regla de roll-up permanente al salir definida y documentada, con reasignación de la downline al upline calificado y comunicación a downline y upline."},{"nivel":4,"ancla":"4 Reestructuración gestionada; se audita que la genealogía quede íntegra tras cada salida y que el efecto en comisiones se comunique a los afectados."},{"nivel":5,"ancla":"5 Ninguna regla de roll-up de salida permanece vigente sin una revisión documentada de su efecto medido sobre el pago del upline y la integridad de la red."}]},"sistemas":{"referenciaMp":"§2 (roll-up mueve la comisión hacia arriba hasta el primer upline calificado; la regla debe estar en la P&P, no solo en la lógica del motor), §2.8 (regla explícita de roll-up u orphan placement para posiciones que quedan sin titular), §3 (SoD maker-checker y control de cambios de genealogía con aprobación en dos factores, simulación de impacto y audit log inmutable donde el movimiento es visible, atribuible y reversible)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; el efecto de la salida sobre la genealogía no es visible ni reproducible fuera del cálculo mismo."},{"nivel":1,"ancla":"1 La reasignación de la downline al salir se resuelve a mano en el árbol, sin dejar trazabilidad del movimiento."},{"nivel":2,"ancla":"2 El software permite mover nodos pero no aplica una regla de roll-up de salida ni registra quién movió qué."},{"nivel":3,"ancla":"3 Plataforma que aplica la regla de roll-up permanente al terminar y deja visible la reasignación de la downline."},{"nivel":4,"ancla":"4 Plataforma que ejecuta y audita el roll-up de salida en tiempo real con aprobación dual (maker-checker) y simulación de impacto antes de confirmar."},{"nivel":5,"ancla":"5 Ecosistema donde la terminación dispara el roll-up permanente y su efecto en comisiones y genealogía fluye encadenado y trazable sin ajuste manual."}]},"agentico":{"referenciaMp":"§6 (simulación/explicación asistida del efecto en comisiones sobre la downline)","anclas":[{"nivel":0,"ancla":"0 Sin IA; simular el efecto de la salida sobre la downline y el upline antes de reasignar es manual."},{"nivel":1,"ancla":"1 Cálculo automatizado del efecto de la reasignación en una hoja con parámetros cargados a mano."},{"nivel":2,"ancla":"2 Copiloto que explica a la downline o al upline por qué su posición o su pago cambió por la salida."},{"nivel":3,"ancla":"3 Agente supervisado que simula el roll-up de salida sobre la genealogía y el pago del upline antes de aplicarlo."},{"nivel":4,"ancla":"4 Agentes que evalúan el impacto de la salida en toda la downline y anticipan efectos no deseados sobre el pago de forma coordinada."},{"nivel":5,"ancla":"5 Simulación y aplicación autónomas dentro de políticas del roll-up de salida óptimo, con escalamiento de casos límite."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Roll-up permanente de salida","tipo":"S4DS","categoria":"Motor de genealogía / reestructuración de salida","coberturaS4DS":"módulo Genealogía · roll-up permanente al terminar · simulación de impacto en comisión · maker-checker · MCP genealogy/rollup tools","nota":"Aplica 
1y audita la regla de roll-up permanente al salir, distinta de la compresión temporal, con aprobación dual y simulación previa."},{"nombre":"DMS núcleo (motor de genealogía y comisiones)","tipo":"tercero","categoria":"Motor de genealogía y comisiones","ejemplos":["DirectScale","Exigo","Epixel"],"nota":"DirectScale ofrece modelado de escenarios de plan de compensación aplicable a simular el impacto del roll-up de salida antes de confirmarlo."},{"nombre":"Herramienta de simulación what-if","tipo":"tercero","categoria":"Simulación de impacto en comisión","ejemplos":["motores de simulación embebidos en el DMS"],"nota":"Proyecta el efecto del roll-up sobre el pago del upline receptor antes de aplicarlo de forma irreversible."}],"agentesYUseCase":[{"useCase":"Simulador de roll-up de salida: agente que proyecta el efecto de la reasignación permanente sobre la genealogía y el pago del upline antes de aplicarla.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — simula, humano aprueba (maker-checker)","valor":"evita reasignaciones irreversibles sin conocer su impacto en comisión"},{"useCase":"Copiloto explicador: genera la explicación en lenguaje claro de por qué cambió la posición o el pago de la downline o el upline afectados por la salida.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2)","valor":"reduce disputas por reasignaciones no comunicadas o mal entendidas"},{"useCase":"Evaluador de impacto en toda la downline: agente que analiza el efecto de la salida en toda la rama afectada, no solo en el primer upline calificado, y anticipa efectos no deseados sobre el pago.","tipo":"tercero","nivelAutonomia":"agente supervisado (nivel 3-4)","ejemplos":["analítica de comisión embebida en DMS de nicho"],"valor":"detecta efectos en cascada de la reestructuración antes de que lleguen al pago liquidado"}],"metadata":{"evidenciaEsperada":"Regla documentada de roll-up permanente al salir (movimiento de la downline al upline calificado) con evidencia de su aplicación en terminaciones recientes, de la aprobación dual del cambio de genealogía y de la comunicación a la downline y al upline afectados.","dolorAsociado":"Downline que queda huérfana o se reasigna caso por caso al salir un vendedor: sin una regla de roll-up permanente y su comunicación, la genealogía pierde integridad, los uplines no entienden por qué cambió su pago y una reasignación disputada no tiene documento ni trazabilidad que la resuelva.","frenteRecomendacion":"Tecnología e Integración","fuente":"MASTER-C01 §2 (distinguir compresión —temporal/reversible, sin alterar la genealogía— de roll-up —mueve la comisión hacia arriba hasta el primer upline calificado—; la regla debe estar en la Política y Procedimientos), §2.8 (un no-renovado/terminado no debe generar ni recibir comisión, pero su posición requiere regla explícita de roll-up u orphan placement), §2.9 (reasignación de downline como parte del hand-off de terminación), §3 (SoD: maker-checker en cambios de genealogía, aprobación en dos factores, simulación de impacto antes de confirmar y audit log inmutable donde 'admins cannot silently move partners; the move is visible, attributable, and reversible'), §6 (deuda técnica y riesgo de la migración/edición de genealogía por su enlace directo a comisiones)"},"camposFaltantes":[]},{"practiceId":"C01-08-PR-06","processId":"C01","temaId":"c01-terminacion-offboarding-y-buyback","nombre":"Registro del motivo de terminación y expediente auditable para defensa regulatoria","pregunta":"¿Cada terminación registra su motivo tipificado y conserva un expediente auditable —causa, aprobaciones, cierre financiero y de accesos, reestructuración de genealogía y archivo recuperable de comunicaciones— que permite reconstruir y defender la salida ante el vendedor o el regulador?","enunciado":"La organización registra el motivo tipificado de cada terminación y conserva un expediente auditable de la salida —causa, aprobaciones, reconciliación financiera, cierre de accesos, reestructuración de la genealogía y archivo recuperable de las comunicaciones del vendedor durante y después de la relación—, de modo que pueda reconstruir y defender cualquier terminación ante el vendedor, un tercero o el regulador. El estado de terminación es además verificable de forma que impide el re-ingreso indebido, y el expediente se conserva por el periodo de retención exigido y es recuperable a demanda.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 No se registra el motivo de la terminación ni se conserva expediente; una salida no se puede reconstruir después."},{"nivel":1,"ancla":"1 El motivo se anota de forma informal y esporádica; no hay expediente que reúna causa, aprobaciones y efectos de la salida."},{"nivel":2,"ancla":"2 Se registra el motivo pero de forma incompleta y sin reunir en un expediente los efectos (cierre financiero, accesos, genealogía) ni el archivo de comunicaciones."},{"nivel":3,"ancla":"3 Motivo de terminación registrado con causa tipificada y expediente que reúne aprobaciones, cierre financiero y de accesos, reestructuración y comunicaciones archivadas."},{"nivel":4,"ancla":"4 Expediente gestionado e inmutable; se audita su completitud por terminación y se conserva por el periodo de retención exigido, recuperable a demanda."},{"nivel":5,"ancla":"5 Ningún expediente de terminación queda incompleto: la evidencia es recuperable en el 100% de los casos, y los motivos y patrones recurrentes de terminación retroalimentan una revisión documentada de las reglas del proceso."}]},"sistemas":{"referenciaMp":"§2.9 (un proceso maduro archiva las comunicaciones del vendedor de forma recuperable durante y después de la relación), §2.3 (registro público de vendedores 'delisted' verificable externamente), §10 largo plazo (registro verificable externamente de vendedores terminados y archivo recuperable de comunicaciones para defensa regulatoria post-terminación)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; el motivo y los documentos de la salida, si existen, quedan dispersos y no recuperables."},{"nivel":1,"ancla":"1 El motivo y algunos documentos se guardan en carpetas o correos sueltos, sin expediente unificado ni retención garantizada."},{"nivel":2,"ancla":"2 Software especializado que registra el motivo, pero el expediente y las comunicaciones viven en sistemas separados sin consolidar."},{"nivel":3,"ancla":"3 Plataforma que consolida el expediente de terminación (motivo, aprobaciones, efectos, comunicaciones) y lo conserva de forma consultable."},{"nivel":4,"ancla":"4 Plataforma con expediente inmutable y retención por el periodo exigido, con el estado terminado verificable para impedir el re-ingreso indebido."},{"nivel":5,"ancla":"5 Ecosistema donde la terminación arma el expediente encadenando causa, efectos y comunicaciones y lo conserva verificable end-to-e
1nd sin armado manual."}]},"agentico":{"referenciaMp":"§6 (síntesis asistida de expedientes; riesgo de earnings claims generados por IA que deben quedar auditados contra la guía FTC)","anclas":[{"nivel":0,"ancla":"0 Sin IA; reunir el expediente de una terminación y verificar que esté completo es manual y tardío."},{"nivel":1,"ancla":"1 Alertas por regla fija cuando una terminación queda sin motivo registrado o con expediente incompleto."},{"nivel":2,"ancla":"2 Copiloto que reúne a pedido los documentos y comunicaciones de una terminación en un borrador de expediente."},{"nivel":3,"ancla":"3 Agente supervisado que arma el expediente de terminación, verifica su completitud y señala lo que falta para la defensa."},{"nivel":4,"ancla":"4 Agentes que consolidan de forma continua causa, efectos y comunicaciones de cada salida y vigilan la completitud del expediente."},{"nivel":5,"ancla":"5 Armado y verificación del expediente autónomos dentro de políticas, con escalamiento de expedientes incompletos por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Expediente de terminación","tipo":"S4DS","categoria":"Case management / expediente auditable","coberturaS4DS":"módulo Ciclo de Vida · consolidación automática de motivo, aprobaciones, cierre financiero, cierre de accesos y reestructuración en un expediente único · retención configurable · MCP case/records tools","nota":"Arma el expediente a partir de lo que las demás prácticas del tema ya generan, sin ensamblado manual."},{"nombre":"Archivado de comunicaciones","tipo":"tercero","categoria":"Compliance / records archiving","ejemplos":["Smarsh","Global Relay","Proofpoint Archive"],"nota":"Conserva de forma recuperable las comunicaciones del vendedor (redes, mensajería, email) durante y después de la relación, insumo obligatorio del expediente."},{"nombre":"Enterprise content / records management","tipo":"tercero","categoria":"Gestión documental y retención","ejemplos":["OpenText","iManage","Microsoft Purview"],"nota":"Gobierna el periodo de retención y la recuperabilidad a demanda del expediente completo de la terminación."},{"nombre":"Registro externo verificable (patrón 'delisted')","tipo":"tercero","categoria":"Portal público de verificación de estado","ejemplos":["registros regulatorios equivalentes al modelo de India"],"nota":"Expone el estado terminado de forma consultable externamente, cerrando el vector de re-ingreso indebido."}],"agentesYUseCase":[{"useCase":"Armador de expediente: agente que consolida automáticamente motivo, aprobaciones, cierre financiero, cierre de accesos, reestructuración de genealogía y comunicaciones archivadas de cada terminación.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3)","valor":"elimina el ensamblado manual y tardío del expediente cuando ya se necesita para una disputa"},{"useCase":"Verificador de completitud: revisa cada expediente cerrado y señala qué piezas faltan (aprobación, cierre financiero, archivo de comunicaciones) antes de considerarlo listo para defensa.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3)","valor":"garantiza que ningún expediente quede incompleto sin que alguien lo note"},{"useCase":"Auditor de earnings claims generados por IA: revisa mensajes y contenido generado por agentes de IA durante la relación (proyecciones de ingreso, coaching de ganancias) y los deja auditados contra la guía FTC dentro del expediente.","tipo":"tercero","nivelAutonomia":"agente supervisado (nivel 3-4)","ejemplos":["herramientas de GenAI compliance auditing"],"valor":"cierra el riesgo regulatorio emergente de earnings claims no verificadas generadas por IA"}],"metadata":{"evidenciaEsperada":"Expediente de terminaciones recientes con el motivo tipificado, las aprobaciones, el cierre financiero y de accesos, la reestructuración de la genealogía y el archivo recuperable de comunicaciones, más la política de retención aplicada y la verificabilidad del estado terminado.","dolorAsociado":"Terminaciones sin motivo registrado ni expediente: cuando el vendedor, un tercero o el regulador cuestiona una s
1alida, la compañía no puede reconstruir por qué y cuándo se terminó ni demostrar que cumplió recompra, cierre y reasignación; y las comunicaciones de earnings publicadas durante la actividad siguen generando exposición post-terminación sin archivo recuperable.","frenteRecomendacion":"Gobierno/Roles/Tercerización","fuente":"MASTER-C01 §2.9 (el ciclo no termina limpiamente en 'cuenta cerrada'; el DSSRC documentó 608 reclamos evaluados; un proceso maduro archiva las comunicaciones del vendedor de forma recuperable durante y después de la relación), §2.3 (India: registro público de vendedores 'delisted' consultable —el estado de terminación debe ser verificable externamente), §1 (un diseño maduro debe quedar 'listo para la regla': logging de sustentación, versión de claims, timestamps, retención 3 años), §8.1 (income claims indebidos como frente regulatorio más activo; enforcement por casos individuales continúa), §10 largo plazo (registro verificable externamente de vendedores terminados y archivo recuperable de comunicaciones para defensa regulatoria post-terminación)"},"camposFaltantes":[]},{"practiceId":"C01-09-PR-01","processId":"C01","temaId":"c01-cumplimiento-y-etica-del-enrolamiento","nombre":"Marco regulatorio como piso vivo y versionado","pregunta":"¿Mantenemos un mapeo vigente y versionado de las obligaciones regulatorias del enrolamiento, con un responsable que lo actualiza y lo traduce en controles operativos?","enunciado":"La organización mantiene un mapeo vigente y versionado de las obligaciones regulatorias que gobiernan el enrolamiento y la compensación (reglas anti-pirámide, divulgación de ingresos, periodos de retracto, códigos de autorregulación y normativa estatal y multi-país), con un responsable de cumplimiento que lo actualiza ante cambios normativos y traduce cada obligación en un control operativo verificable. De este modo el diseño del proceso parte de un piso regulatorio explícito y trazable, en lugar de descansar en el conocimiento tácito de algunas personas o en supuestos que quedan obsoletos cuando la norma cambia.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin mapeo regulatorio; las obligaciones se conocen de forma dispersa o se descubren cuando ocurre un incidente."},{"nivel":1,"ancla":"1 Conocimiento regulatorio informal en algunas personas; sin documento ni responsable definido."},{"nivel":2,"ancla":"2 Existe un listado de obligaciones, pero desactualizado, sin versión ni cobertura multi-jurisdicción."},{"nivel":3,"ancla":"3 Mapeo regulatorio documentado y versionado, con responsable de cumplimiento y cobertura por jurisdicción."},{"nivel":4,"ancla":"4 Mapeo gestionado: cada obligación ligada a un control operativo verificable, con revisión periódica y registro de cambios normativos."},{"nivel":5,"ancla":"5 Vigilancia regulatoria continua que anticipa cambios (reglas emergentes) y ajusta los controles antes de su entrada en vigor."}]},"sistemas":{"referenciaMp":"§2 (marco regulatorio como piso), §3 (versionado de P&P)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; la normativa aplicable no está registrada en ningún repositorio."},{"nivel":1,"ancla":"1 Documento suelto o correo con notas regulatorias, sin control de versión."},{"nivel":2,"ancla":"2 Repositorio documental con las normas y políticas, versionado manual básico."},{"nivel":3,"ancla":"3 Gestor documental con versionado y control de acceso que liga cada norma a la política interna correspondiente."},{"nivel":4,"ancla":"4 Plataforma de gestión de cumplimiento (GRC) que mapea obligación→control→evidencia con trazabilidad por jurisdicción."},{"nivel":5,"ancla":"5 Ecosistema GRC integrado con feeds regulatorios y con los procesos operativos; el cambio normativo propaga la actualización del control."}]},"agentico":{"referenciaMp":"§6 (IA de cumplimiento)","anclas":[{"nivel":0,"ancla":"0 Sin IA; el seguimiento de cambios normativos es completamente manual."},{"nivel":1,"ancla":"1 Alertas simples de novedades regulatorias por palabras clave o suscripción."},{"nivel":2,"ancla":"2 Copiloto que resume normativa y borradores de cambio regulatorio para revisión del responsable."},{"nivel":3,"ancla":"3 Agente supervisado que rastrea fuentes regulatorias, detecta cambios relevantes y propone impacto sobre los controles."},{"nivel":4,"ancla":"4 Agentes que correlacionan cambios normativos multi-jurisdicción con el mapa de controles y priorizan brechas."},{"nivel":5,"ancla":"5 Vigilancia regulatoria autónoma que actualiza el mapeo y señala controles a ajustar dentro de políticas, con revisión por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Mapeo y control de cumplimiento regulatorio","tipo":"S4DS","categoria":"Gobierno de cumplimiento del CRM transaccional","coberturaS4DS":"módulo Compliance · mapeo obligación→jurisdicción→control versionado · MCP compliance tools","nota":"Mantiene el mapeo regulatorio como dato vivo, ligado al control operativo real que lo hace cumplir, no como documento legal aislado."},{"nombre":"Plataforma de gestión de cumplimiento (GRC)","tipo":"tercero","categoria":"Gobierno, riesgo y cumplimiento (GRC)","ejemplos":["OneTrust","AuditBoard","ServiceNow GRC"],"nota":"Mapea obligación→control→evidencia con trazabilidad por jurisdicción y soporta la revisión periódica."},{"nombre":"Inteligencia y vigilancia regulatoria","tipo":"tercero","categoria":"Vigilancia y gestión de cambio normativo","ejemplos":["Thomson Reuters Regulatory Intelligence","Compliance.ai"],"nota":"Rastrea fuentes regulatorias multi-jurisdicción y alerta sobre cambios relevantes antes de su entrada en vigor."},{"nombre":"DMS / plataforma núcleo de venta directa","tipo":"tercero","categoria":"Distributor Management System (DMS)","ejemplos":["Exigo","DirectScale","ByDesign Freedom","
1Epixel"],"nota":"Sistema donde cada obligación mapeada se materializa como control operativo real (límites de compra, gating de contenido, retención de evidencia)."}],"agentesYUseCase":[{"useCase":"Vigilancia regulatoria: agente que rastrea fuentes normativas y de autorregulación (federal, estatal, multi-país) y detecta cambios relevantes para el mapeo vigente.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — detecta y reporta; el responsable de cumplimiento valida el impacto","valor":"reduce el tiempo entre un cambio normativo real y su reflejo en el mapeo de controles"},{"useCase":"Copiloto de traducción obligación→control: dado un cambio normativo, sugiere qué control operativo debe crearse o ajustarse y en qué sistema.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — sugiere, el responsable de cumplimiento decide","valor":"cierra la brecha entre saber que cambió la norma y saber qué hacer operativamente al respecto"},{"useCase":"Correlación multi-jurisdicción de cambios normativos con el mapa de controles existente, priorizando las brechas de mayor riesgo.","tipo":"tercero","nivelAutonomia":"agentes coordinados (nivel 4)","ejemplos":["plataformas de regulatory change management con IA"],"valor":"prioriza la atención de compliance en las brechas de mayor exposición cuando el volumen de cambios normativos supera la capacidad de revisión manual"}],"metadata":{"evidenciaEsperada":"Mapeo regulatorio vigente y versionado (obligación→jurisdicción→control) con responsable de cumplimiento asignado y fecha de última revisión.","dolorAsociado":"Obligaciones regulatorias conocidas de forma tácita que quedan obsoletas al cambiar la norma; incidentes descubiertos por enforcement en lugar de por control preventivo.","frenteRecomendacion":"Gobierno/Roles/Tercerización","fuente":"MASTER-C01 §2 (marco regulatorio como piso; FTC Business Guidance MLM 2024, 16 CFR 437), §3 (versionado de P&P), §9 (tendencias regulatorias); DSA Code of Ethics; WFDSA Code of Ethics (2025)"},"camposFaltantes":[]},{"practiceId":"C01-09-PR-02","processId":"C01","temaId":"c01-cumplimiento-y-etica-del-enrolamiento","nombre":"Divulgación precontractual y derecho de retracto gobernados end-to-end","pregunta":"¿La divulgación precontractual y el derecho de retracto se ofrecen, registran y honran end-to-e
1nd, de modo que cada alta solo se confirma tras vencer la ventana de cancelación?","enunciado":"La divulgación precontractual y el derecho de retracto o periodo de reflexión operan como un control gobernado de extremo a extremo: la organización asegura que la información precontractual se entregue, que el periodo de cancelación se ofrezca y registre, y que toda solicitud de retracto dentro del plazo se honre efectivamente con reverso de cargos y del estado de alta. La madurez no es que exista una cláusula firmada, sino poder demostrar por cada alta que el derecho se comunicó, se pudo ejercer y se cumplió, de modo que el estado de \\"activo confirmado\\" solo se consolide una vez vencida la ventana de cancelación.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin control; no se entrega divulgación precontractual ni se ofrece un periodo de retracto verificable."},{"nivel":1,"ancla":"1 El derecho de retracto se menciona informalmente; su ejercicio depende de que el prospecto lo reclame y de la buena voluntad de campo."},{"nivel":2,"ancla":"2 Existe divulgación y cláusula de cooling-off, pero sin registro de entrega ni de cómo se honran las cancelaciones."},{"nivel":3,"ancla":"3 Proceso definido: se registra la entrega de la divulgación y las cancelaciones dentro del plazo se reversan de forma estandarizada."},{"nivel":4,"ancla":"4 Control gestionado: el alta solo se confirma tras la ventana; se mide la tasa de retracto y el SLA de reverso de cargos y estado."},{"nivel":5,"ancla":"5 Ningún alta se confirma antes de vencer la ventana de cooling-off; la divulgación y el retracto se honran en el 100% de los casos, con capacidad ya operativa para incorporar una ventana precontractual más larga si la norma cambia."}]},"sistemas":{"referenciaMp":"§2 (Cooling-Off Rule 16 CFR 429), §4 (2.1 divulgación precontractual, 2.2 cooling-off)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; ni la entrega de divulgación ni las cancelaciones quedan registradas."},{"nivel":1,"ancla":"1 Registro manual esporádico de cancelaciones en planilla o correo."},{"nivel":2,"ancla":"2 Formulario de divulgación y de cancelación gestionados por separado, sin ligarse al registro del alta."},{"nivel":3,"ancla":"3 Sistema que registra la entrega de la divulgación y la solicitud de retracto ligadas al alta, con timestamp."},{"nivel":4,"ancla":"4 Plataforma que retiene el estado en ventana de cancelación y ejecuta el reverso de cargos y de alta con trazabilidad."},{"nivel":5,"ancla":"5 Ecosistema donde alta, cobro, cooling-off y reverso están integrados;
1 la confirmación de estado depende del vencimiento de la ventana sin intervención manual."}]},"agentico":{"anclas":[{"nivel":0,"ancla":"0 Sin IA; el seguimiento del periodo de retracto y de su cumplimiento es manual."},{"nivel":1,"ancla":"1 Recordatorios automáticos de la ventana de cooling-off al prospecto o al back-office."},{"nivel":2,"ancla":"2 Copiloto que verifica que la divulgación se entregó antes de firmar y marca altas sin registro de retracto."},{"nivel":3,"ancla":"3 Agente supervisado que detecta altas confirmadas antes de vencer la ventana o cancelaciones no honradas y las reporta."},{"nivel":4,"ancla":"4 Agentes que reconcilian entrega, plazo, cancelación y reverso de cargos de forma coordinada con supervisión."},{"nivel":5,"ancla":"5 Gestión autónoma del cooling-off dentro de políticas: honra retractos y consolida estado, con escalamiento por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Gestión de divulgación precontractual y cooling-off","tipo":"S4DS","categoria":"Enrolamiento y compliance del CRM transaccional","coberturaS4DS":"módulo Enrolamiento · registro de entrega de divulgación y ventana de retracto ligados al alta · consolidación de estado tras vencimiento · MCP enrollment/compliance tools","nota":"Retiene el alta en estado provisional hasta vencer la ventana de cancelación, ejecutando el reverso de cargos y de estado sin intervención manual."},{"nombre":"Firma electrónica","tipo":"tercero","categoria":"e-Signature / aceptación auditable","ejemplos":["DocuSign eSignature","Adobe Acrobat Sign"],"nota":"Liga el certificado de aceptación a la versión exacta del documento y aporta evidencia de entrega con timestamp e IP/dispositivo."},{"nombre":"DMS / plataforma núcleo de venta directa","tipo":"tercero","categoria":"Distributor Management System (DMS)","ejemplos":["Exigo","DirectScale","ByDesign Freedom","Epixel"],"nota":"Gestiona el flujo de alta con hold de estado durante el periodo de cooling-off antes de confirmar 'activo'."},{"nombre":"Plataforma de cobros con reverso de cargos","tipo":"tercero","categoria":"Billing / subscription management","ejemplos":["Stripe Billing","Chargebee"],"nota":"Ejecuta el reverso de cargos dentro del SLA cuando una cancelación se ejerce dentro de la ventana de retracto."}],"agentesYUseCase":[{"useCase":"Verificador de entrega de divulgación: detecta altas confirmadas antes de que la divulgación quede registrada o antes de vencer la ventana de retracto.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — detecta y reporta; el humano corrige","valor":"cierra la brecha entre la política firmada y su ejercicio real, antes de que se convierta en una disputa"},{"useCase":"Copiloto de reverso: ante una solicitud de retracto, arma el paquete de reverso de cargos y de estado de alta para aprobación inmediata.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — presenta, humano aprueba","valor":"reduce el SLA de honrar una cancelación de días a minutos"},{"useCase":"Recordatorios automáticos multicanal de la ventana de cooling-off al prospecto y al back-office.","tipo":"S4DS","nivelAutonomia":"asistido (nivel 1) — notifica sin intervenir en el estado","valor":"reduce la probabilidad de que una cancelación válida se pierda por falta de aviso oportuno"}],"metadata":{"evidenciaEsperada":"Para una muestra de altas: evidencia de entrega de la divulgación precontractual, registro de la ventana de retracto y prueba de reverso de las cancelaciones honradas dentro del plazo.","dolorAsociado":"Cooling-off tratado como cláusula firmada pero no honrado en la práctica (kits vendidos en reuniones domiciliarias); KPI de conversión inflado con altas reversibles no consolidadas.","frenteRecomendacion":"Gobierno/Roles/Tercerización","fuente":"MASTER-C01 §2 (Cooling-Off Rule 16 CFR 429; divulgación precontractual), §4 (2.1, 2.2 cooling-off, altas reversibles), §9 (transparencia integrada al flujo); FTC NPRM Business Opportunity Rule (ene-2025, periodo de espera emergente)"},"camposFaltantes":[]},{"practiceId":"C01-09-PR-03","processId":"C01","temaId":"c01-cumplimiento-y-etica-del-enrolamiento","nombre":"Regla del 70% y venta a usuario final como salvaguarda anti-pirámide","pregunta":"¿Medimos y hacemos cumplir que las comisiones depen
1dan de la venta real a usuario final (regla del 70%, ratio de venta externa), bloqueando la calificación basada en autocompra?","enunciado":"La organización mide y hace cumplir que la compensación dependa de la venta real a consumidores finales y no del reclutamiento ni del autoconsumo, aplicando salvaguardas anti-pirámide como la regla del 70% de reventa, límites de compra ligados a demanda real y el ratio de venta a usuario final por vendedor y periodo. La calificación a bonos y rangos se bloquea cuando el volumen proviene de compra propia para calificar (inventory loading) en vez de demanda genuina, de manera que la estructura de incentivos quede instrumentada con evidencia de consumo o reventa, no solo con el evento de pago.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin salvaguarda; la calificación a bonos no distingue venta a usuario final de autocompra ni de reclutamiento."},{"nivel":1,"ancla":"1 Se reconoce el principio de venta a usuario final, pero no se mide ni se aplica de forma consistente."},{"nivel":2,"ancla":"2 Regla del 70% o umbral de clientes enunciada en la política, sin medición sistemática por vendedor."},{"nivel":3,"ancla":"3 Salvaguardas definidas: ratio de venta a usuario final medido por vendedor y periodo, con criterios de calificación documentados."},{"nivel":4,"ancla":"4 Enforcement gestionado: bloqueo de calificación por autocompra, bandera de inventory loading auditable y KPI de venta externa vigilado."},{"nivel":5,"ancla":"5 Ninguna política de incentivos permanece vigente sin una revisión documentada contra los datos de venta real a consumidor final del periodo anterior."}]},"sistemas":{"referenciaMp":"§2 (regla del 70%, salvaguardas Amway), §4 (2.4 anti-inventory-loading), §7 (ratio venta-a-usuario-final)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; no se puede calcular qué proporción del volumen fue venta a usuario final."},{"nivel":1,"ancla":"1 Cálculo manual en hoja de cálculo para casos puntuales."},{"nivel":2,"ancla":"2 Reporte periódico de compras por vendedor, sin distinguir reventa de autoconsumo automáticamente."},{"nivel":3,"ancla":"3 Motor de comisiones que registra volumen con marca de venta a usuario final y aplica reglas de calificación."},{"nivel":4,"ancla":"4 Plataforma que calcula el ratio de venta externa en tiempo casi real y bloquea la calificación por autocompra con audit trail."},{"nivel":5,"ancla":"5 Ecosistema donde venta, comisión y evidencia de reventa están integrados; el ratio se audita por vendedor y periodo sin transferencias manuales."}]},"agentico":{"referenciaMp":"§6 (detección de fraude estructural)","anclas":[{"nivel":0,"ancla":"0 Sin IA; la detección de patrones de autocompra para calificar es manual o inexistente."},{"nivel":1,"ancla":"1 Alertas por umbral cuando la compra propia supera un porcentaje del volumen."},{"nivel":2,"ancla":"2 Copiloto que señala vendedores con patrón de compra incoherente con demanda real para revisión."},{"nivel":3,"ancla":"3 Agente supervisado que detecta inventory loading y anomalías de ratio de venta externa y los reporta a cumplimiento."},{"nivel":4,"ancla":"4 Agentes que correlacionan compras, reventa y estructura de red para priorizar riesgo anti-pirámide de forma coordinada."},{"nivel":5,"ancla":"5 Vigilancia autónoma del ratio de venta a usuario final que bloquea calificaciones no conformes dentro de políticas, con escalamiento por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Motor de comisiones con marca de venta a usuario final","tipo":"S4DS","categoria":"Motor de comisiones del CRM transaccional","coberturaS4DS":"módulo Comisiones · marca de venta a usuario final por transacción · bloqueo de calificación por autocompra · MCP commission-engine tools","nota":"Calcula el ratio de venta externa por vendedor y periodo y aplica el bloqueo de calificación en el momento del cálculo, no como auditoría posterior."},{"nombre":"Motor de comisiones especializado (capa de cálculo)","tipo":"tercero","categoria":"Motor de cálculo de comisiones (venta directa)","ejemplos":["Exigo Core","DirectScale","ByDesign Freedom","
1Epixel"],"nota":"Sistema donde se configuran los límites de compra por periodo y las reglas de calificación anti-inventory-loading."},{"nombre":"BI / analítica de ratio de venta","tipo":"tercero","categoria":"Analítica de venta y calidad de volumen","ejemplos":["Power BI","Tableau","Looker"],"nota":"Monitorea la tendencia del ratio venta-a-usuario-final por vendedor, rango y periodo para detectar deterioro antes de que escale."},{"nombre":"Detección de anomalías transaccionales","tipo":"tercero","categoria":"Analítica de fraude / anomalías de compra","ejemplos":["SAS Detection & Investigation","Feedzai"],"nota":"Adapta modelos de detección de anomalías a patrones de compra atípicos incoherentes con demanda real."}],"agentesYUseCase":[{"useCase":"Auditor del ratio de venta a usuario final: calcula el ratio por vendedor y periodo y bloquea la calificación cuando no cumple el umbral definido.","tipo":"S4DS","nivelAutonomia":"agente supervisado → gestionado (nivel 3-4) — bloquea dentro de reglas, con revisión por excepción","valor":"convierte la regla del 70% de un principio de política a un control ejecutado en cada corrida de comisiones"},{"useCase":"Copiloto de detección de inventory loading: señala vendedores con patrón de compra incoherente con la demanda real para revisión de compliance.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — sugiere, humano investiga","valor":"adelanta la detección de autocompra para calificar antes de que se consolide el pago del bono"},{"useCase":"Correlación de compras, reventa y estructura de red para priorizar riesgo anti-pirámide de forma coordinada.","tipo":"tercero","nivelAutonomia":"agentes coordinados (nivel 4)","ejemplos":["plataformas de fraud analytics / network anomaly detection"],"valor":"eleva la detección de inventory loading de un caso aislado a un patrón visible a nivel de red"}],"metadata":{"evidenciaEsperada":"Cálculo del ratio de venta a usuario final por vendedor y periodo + regla de calificación que bloquea bonos derivados de autocompra o reclutamiento (regla del 70% / límite de clientes).","dolorAsociado":"Comisiones ligadas a compra propia para calificar (inventory loading) que configuran el vector legal central de esquema piramidal; una buyback policy no blinda un diseño que premia reclutamiento sobre venta.","frenteRecomendacion":"Tecnología e Integración","fuente":"MASTER-C01 §2 (regla del 70% DSA; salvaguardas In re Amway 1979: 70%/10 clientes/recompra 90%), §4 (2.4 anti-inventory-loading), §7 (ratio venta-a-usuario-final), §8.2 (inventory loading; estándar Koscot); FTC Business Guidance MLM 2024; órdenes FTC Herbalife (2016) y Vemma (2015)"},"camposFaltantes":[]},{"practiceId":"C01-09-PR-04","processId":"C01","temaId":"c01-cumplimiento-y-etica-del-enrolamiento","nombre":"Sustanciación de earnings claims e IDS con ingresos netos","pregunta":"¿Cada afirmación de ingresos y el IDS descansan en datos transaccionales netos sustanciados, con un proceso de aprobación que impide difundir cifras sin respaldo documentado?","enunciado":"Toda afirmación de ingresos o ganancias que la organización o su fuerza de ventas presenta descansa en una base de datos que la sustenta, y la divulgación de ingresos refleja ingresos netos reales —descontando gastos y deducciones, no ingresos brutos— generada desde datos transaccionales verdaderos. Existe un proceso de aprobación por el que ninguna cifra de ingreso o proyección de ganancia se difunde sin sustentación documentada y retención suficiente, de manera que la organización pueda acreditar el respaldo de cada claim ante el escrutinio de afirmaciones de ingresos, en lugar de difundir cifras optimistas sin base reconstruible.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin sustanciación; se difunden cifras de ingreso o proyecciones sin base ni aprobación, o el IDS reporta solo brutos."},{"nivel":1,"ancla":"1 El IDS existe pero se arma manualmente y no descuenta gastos; los claims de campo circulan sin respaldo."},{"nivel":2,"ancla":"2 Criterios de sustanciación enunciados, aplicados de forma desigual; el IDS mezcla fuentes sin base transaccional consistente."},{"nivel":3,"ancla":"3 Proceso definido: el IDS se genera desde datos transaccionales netos y todo claim requiere sustentación documentada y aprobación."},{"nivel":4,"ancla":"4 Sustanciación gestionada: base de respaldo por claim con retención definida, auditoría de la coherencia del IDS y trazabilidad de aprobaciones."},{"nivel":5,"ancla":"5 Ningún earnings claim se difunde sin su respaldo documentado; el IDS se genera y sustenta en el 100% de los ciclos, con la retención de evidencia lista para el periodo que exija la norma."}]},"sistemas":{"referenciaMp":"§2 (IDS: gastos/deducciones, no solo brutos), §8.1 (income claims indebidos)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; las cifras de ingreso se calculan a mano y sin fuente única."},{"nivel":1,"ancla":"1 Planilla con ingresos brutos; sin vínculo a transacciones ni a gastos."},{"nivel":2,"ancla":"2 Reporte de ingresos por vendedor, sin base neta ni repositorio de sustentación de claims."},{"nivel":3,"ancla":"3 Sistema que genera el IDS desde datos transaccionales netos y almacena la sustentación de cada claim aprobado."},{"nivel":4,"ancla":"4 Plataforma con log de sustentación y retención configurable por claim, y generación auditable del IDS con gastos."},{"nivel":5,"ancla":"5 Ecosistema donde transacciones, gastos, IDS y sustentación de claims fluyen integrados; el respaldo queda disponible para auditoría sin intervención manual."}]},"agentico":{"referenciaMp":"§6 (riesgo GenAI: earnings claims no verificadas)","anclas":[{"nivel":0,"ancla":"0 Sin IA; la verificación de respaldo de cada claim es manual, si ocurre."},{"nivel":1,"ancla":"1 IA que ayuda a redactar el IDS o resúmenes de ingresos bajo demanda, sin verificación de sustentación."},{"nivel":2,"ancla":"2 Copiloto que contrasta un claim con la base de datos y marca cifras sin respaldo para revisión."},{"nivel":3,"ancla":"3 Agente supervisado que detecta claims de ingreso sin sustentación o incoherentes con los datos netos y alerta antes de difundirse."},{"nivel":4,"ancla":"4 Agentes que correlacionan claims, transacciones y gastos para armar el expediente de sustentación de forma coordinada."},{"nivel":5,"ancla":"5 Sustanciación autónoma que bloquea la difusión de claims no respaldados dentro de políticas, con revisión por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Generación de IDS y sustentación de earnings claims","tipo":"S4DS","categoria":"Compliance y reporting del CRM transaccional","coberturaS4DS":"módulo Comisiones/Reporting · generación de IDS desde datos transaccionales netos · repositorio de sustentación y aprobación de claims · MCP compliance/reporting tools","nota":"Genera el IDS con gastos/deducciones desde la fuente transaccional real y bloquea la difusión de un claim sin sustentación aprobada."},{"nombre":"DMS / motor de cálculo (fuente transaccional del IDS)","tipo":"tercero","categoria":"Distributor Management System (DMS)","ejemplos":["Exigo","DirectScale","ByDesign Freedom","
1Epixel"],"nota":"Fuente de los datos transaccionales netos (ingresos, gastos, deducciones) desde donde debería generarse el IDS."},{"nombre":"Plataforma de gestión de cumplimiento (GRC)","tipo":"tercero","categoria":"Gobierno, riesgo y cumplimiento (GRC)","ejemplos":["OneTrust","AuditBoard"],"nota":"Retiene y traza la sustentación de cada earnings claim aprobado, con periodo de retención configurable."},{"nombre":"Gobernanza de contenido generado por IA","tipo":"tercero","categoria":"AI governance / content compliance","ejemplos":["Credo AI"],"nota":"Audita earnings claims o proyecciones generadas o asistidas por IA antes de su difusión, cerrando el riesgo específico de GenAI."}],"agentesYUseCase":[{"useCase":"Generador/verificador de IDS neto: construye el IDS desde datos transaccionales descontando gastos y señala inconsistencias frente a periodos previos.","tipo":"S4DS","nivelAutonomia":"copiloto → agente supervisado (nivel 2-3) — genera borrador, humano certifica","valor":"elimina la dependencia de un armado manual del IDS que omite gastos por defecto"},{"useCase":"Auditor de sustentación de claims: contrasta cada earnings claim contra la base de datos transaccional y marca cifras sin respaldo documentado antes de difundirse.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — detecta y bloquea difusión hasta aprobación","valor":"convierte la sustanciación en un requisito de sistema, no en un criterio que depende de quién redacta el claim"},{"useCase":"Vigilancia de contenido generado por IA con proyecciones de ingreso no verificadas antes de su publicación.","tipo":"tercero","nivelAutonomia":"agente supervisado (nivel 3)","ejemplos":["plataformas de AI governance / content compliance"],"valor":"cierra el vector de riesgo específico que la IA generativa introduce en earnings claims no verificados"}],"metadata":{"evidenciaEsperada":"IDS vigente generado desde datos transaccionales con gastos/deducciones + base de sustentación y registro de aprobación de una muestra de earnings claims.","dolorAsociado":"IDS que reporta solo ingresos brutos y claims de ganancia sin respaldo reconstruible; exposición ante la Earnings Claims Rule y el escrutinio de afirmaciones de ingresos (la mayoría de participantes gana ≤US$1,000/año).","frenteRecomendacion":"Tecnología e Integración","fuente":"MASTER-C01 §2 (IDS con gastos/deducciones; sustentación de earnings claims), §8.1 (income claims indebidos;
1 enforcement por casos), §6 (riesgo de GenAI en earnings claims); FTC Staff Report 70 IDS (sept-2024); FTC NPRM Earnings Claims Rule (ene-2025); IDS 2025 Amway"},"camposFaltantes":[]},{"practiceId":"C01-09-PR-05","processId":"C01","temaId":"c01-cumplimiento-y-etica-del-enrolamiento","nombre":"Monitoreo y gating del contenido de la fuerza de ventas en todos los canales","pregunta":"¿Vigilamos el contenido de la fuerza de ventas en todos los canales de forma continua, con detección, revisión, retiro y régimen disciplinario sobre las afirmaciones indebidas de ingresos o salud?","enunciado":"La organización vigila de forma continua el contenido y las afirmaciones que la fuerza de ventas difunde en todos los canales durante toda la relación —no solo al reclutar—, detectando afirmaciones indebidas de ingresos o de salud, revisándolas, ordenando su retiro y aplicando el régimen disciplinario correspondiente. El control cierra la brecha entre el cumplimiento corporativo y el marketing de campo no oficial, de modo que ninguna comunicación de un vendedor tergiverse la oportunidad o el producto sin que la organización la detecte, la corrija y deje registro de la acción tomada.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin monitoreo; el contenido de campo circula sin vigilancia y las infracciones se conocen solo por denuncia externa."},{"nivel":1,"ancla":"1 Revisión reactiva y ocasional; material problemático detectado por casualidad, sin proceso de retiro ni sanción."},{"nivel":2,"ancla":"2 Política de contenido enunciada y buzón de reportes, aplicada de forma inconsistente y sin cobertura de todos los canales."},{"nivel":3,"ancla":"3 Proceso definido: monitoreo de canales, revisión de contenido y flujo de retiro con régimen disciplinario documentado."},{"nivel":4,"ancla":"4 Control gestionado: detección continua en todos los canales, SLA de takedown, escalamiento progresivo y métricas de reincidencia."},{"nivel":5,"ancla":"5 Vigilancia optimizada; el contenido no conforme se detecta, corrige y sanciona de forma sistemática con tendencia decreciente de infracciones."}]},"sistemas":{"referenciaMp":"§10 (compliance gating de sitios replicados y UGC), §2 (marketing de campo no oficial)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; no hay forma de capturar ni revisar lo que publica la fuerza de ventas."},{"nivel":1,"ancla":"1 Capturas manuales de contenido problemático guardadas de forma suelta."},{"nivel":2,"ancla":"2 Formulario o buzón de reporte de contenido, sin monitoreo activo ni flujo de decisión."},{"nivel":3,"ancla":"3 Herramienta de captura y revisión de creatividades con flujo de aprobación/retiro y registro de la decisión."},{"nivel":4,"ancla":"4 Social listening integrado con el flujo de cumplimiento; detección de contenido no conforme en múltiples canales con alertas."},{"nivel":5,"ancla":"5 Ecosistema que monitorea canales, enruta a revisión y ejecuta retiro y acción disciplinaria de forma integrada y trazable."}]},"agentico":{"referenciaMp":"§6 (detección con IA; brecha de fraude/compliance)","anclas":[{"nivel":0,"ancla":"0 Sin IA; la detección de afirmaciones indebidas es manual y reactiva."},{"nivel":1,"ancla":"1 Alertas simples por palabras clave de riesgo (ingresos, curas, garantías) en el contenido reportado."},{"nivel":2,"ancla":"2 Copiloto que clasifica el contenido de campo y marca posibles infracciones de ingresos o salud para revisión."},{"nivel":3,"ancla":"3 Agente supervisado que rastrea canales, detecta earnings/health claims indebidos y los enruta a cumplimiento con evidencia."},{"nivel":4,"ancla":"4 Agentes que monitorean, clasifican y priorizan el contenido no conforme en todos los canales de forma coordinada con supervisión."},{"nivel":5,"ancla":"5 Monitoreo autónomo del marketing de campo con enforcement (retiro y disciplina) dentro de políticas y escalamiento por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Compliance gating de sitios replicados y UGC","tipo":"S4DS","categoria":"Compliance de contenido del CRM transaccional","coberturaS4DS":"módulo Compliance · gating de campos editables en réplicas y captura de UGC · flujo de revisión-retiro-sanción con registro · MCP compliance tools","nota":"Limita lo que un vendedor puede editar en su sitio replicado y captura el material generado por la fuerza de ventas para revisión."},{"nombre":"Social listening / brand monitoring","tipo":"tercero","categoria":"Escucha social y monitoreo de marca","ejemplos":["Brandwatch","Talkwalker","Meltwater"],"nota":"Detecta contenido de campo (ingresos, salud, garantías) en redes sociales y canales públicos que el corporativo no controla."},{"nombre":"Archivo y supervisión de comunicaciones reguladas","tipo":"tercero","categoria":"Compliance archiving / eDiscovery","ejemplos":["Smarsh","Proofpoint"],"nota":"Captura y retiene de forma recuperable las comunicaciones de la fuerza de ventas para defensa post-terminación."},{"nombre":"DMS / gestor de sitios replicados","tipo":"tercero","categoria":"Distributor Management System (DMS)","ejemplos":["Exigo","Epixel","DirectScale"],"nota":"Plataforma donde viven las réplicas y las áreas editables sujetas a gating de compliance."}],"agentesYUseCase":[{"useCase":"Clasificador de contenido de campo: rastrea canales y clasifica publicaciones detectando earnings/health claims indebidos con evidencia para enrutar a compliance.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — detecta y enruta con evidencia","valor":"cierra la brecha de visibilidad entre el compliance corporativo y el marketing de campo no oficial"},{"useCase":"Copiloto de revisión de creatividades: evalúa material antes de su publicación en sitios replicados y marca lenguaje no conforme.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — sugiere, humano aprueba antes de publicar","valor":"previene la infracción antes de que el contenido salga a producción, en vez de detectarla después"},{"useCase":"Monitoreo coordinado multi-canal con priorización de riesgo y enrutamiento automático a compliance.","tipo":"tercero","nivelAutonomia":"agentes coordinados (nivel 4)","ejemplos":["plataformas de social listening con IA"],"valor":"escala la vigilancia a la magnitud real del contenido generado por la fuerza de ventas"}
1,{"useCase":"Enforcement de retiro y disciplina dentro de políticas, con escalamiento por excepción a compliance humano.","tipo":"S4DS","nivelAutonomia":"agente supervisado → autónomo (nivel 4-5) — ejecuta dentro de políticas, escala por excepción","valor":"sostiene una tendencia decreciente de infracciones sin depender de capacidad de revisión manual creciente"}],"metadata":{"evidenciaEsperada":"Registro de casos de contenido de la fuerza de ventas monitoreados en distintos canales, con la revisión, la orden de retiro y la acción disciplinaria aplicada.","dolorAsociado":"Brecha entre el compliance corporativo y el marketing de campo no oficial (redes, grupos, videos) vigente durante toda la relación —vector de settlements FTC (AdvoCare, LuLaRoe, Neora) y de referidos del DSSRC—; exposición post-terminación por mensajes que siguen publicados.","frenteRecomendacion":"Modelos Agénticos/IA","fuente":"MASTER-C01 §2 (brecha compliance corporativo vs. marketing de campo no oficial), §8.1 (income claims indebidos), §10 (compliance gating de sitios replicados y UGC), §4 (2.9 exposición post-terminación); DSSRC Activity Report 2025; settlements FTC AdvoCare/LuLaRoe/Neora"},"camposFaltantes":[]},{"practiceId":"C01-09-PR-06","processId":"C01","temaId":"c01-cumplimiento-y-etica-del-enrolamiento","nombre":"Gobierno del programa de compliance y ética","pregunta":"¿Operamos un programa de compliance/ética con políticas versionadas, capacitación recurrente, régimen disciplinario, auditoría y expediente de defensa regulatoria recuperable?","enunciado":"Existe un programa formal de cumplimiento y ética que gobierna el ciclo de vida del vendedor: políticas y procedimientos versionados y comunicados, capacitación recurrente de la fuerza de ventas y del personal, un régimen disciplinario de escalamiento progresivo con un órgano decisor, auditoría periódica de los controles y un expediente de defensa regulatoria que consolida la evidencia de cumplimiento de forma recuperable. Con ello la ética del enrolamiento se sostiene como un sistema gobernado con responsables y rendición de cuentas, en lugar de depender de esfuerzos aislados o reactivos ante cada incidente.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin programa; el cumplimiento se atiende caso a caso sin políticas, capacitación ni órgano responsable."},{"nivel":1,"ancla":"1 Políticas básicas dispersas; capacitación esporádica y sanciones ad-hoc sin criterio consistente."},{"nivel":2,"ancla":"2 Políticas y régimen disciplinario enunciados, aplicados de forma desigual; sin auditoría ni expediente de defensa."},{"nivel":3,"ancla":"3 Programa definido: P&P versionadas y comunicadas, capacitación recurrente, régimen disciplinario con órgano decisor y expediente de cumplimiento."},{"nivel":4,"ancla":"4 Programa gestionado: auditoría periódica de controles, métricas de cumplimiento y capacitación, y escalamiento progresivo documentado (educar antes de sancionar)."},{"nivel":5,"ancla":"5 Ninguna política, control o módulo de capacitación de compliance permanece vigente sin una revisión documentada contra los hallazgos de auditoría e incidentes del periodo anterior."}]},"sistemas":{"referenciaMp":"§3 (RACI, comité de compliance, versionado de P&P), §10 (expediente/archivo recuperable)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; políticas, capacitación y sanciones sin registro centralizado."},{"nivel":1,"ancla":"1 Documentos y registros sueltos en repositorios personales, sin control de versión."},{"nivel":2,"ancla":"2 Repositorio documental de P&P y registro básico de capacitación y sanciones."},{"nivel":3,"ancla":"3 Plataforma de gestión de cumplimiento y capacitación (LMS) con versionado de P&P y registro de casos disciplinarios."},{"nivel":4,"ancla":"4 GRC integrada: controles, auditoría, capacitación y expediente disciplinario trazables, con archivo recuperable de evidencia."},{"nivel":5,"ancla":"5 Ecosistema donde políticas, controles, capacitación, sanciones y evidencia de defensa fluyen integrados y disponibles para auditoría externa."}]},"agentico":{"anclas":[{"nivel":0,"ancla":"0 Sin IA; la consolidación de evidencia y el seguimiento del programa son manuales."},{"nivel":1,"ancla":"1 IA que ayuda a redactar políticas o materiales de capacitación bajo demanda."},{"nivel":2,"ancla":"2 Copiloto que consolida evidencia de cumplimiento y prepara borradores de reporte para revisión."},{"nivel":3,"ancla":"3 Agente supervisado que rastrea vencimientos de capacitación, casos disciplinarios y brechas de control y los reporta."},{"nivel":4,"ancla":"4 Agentes que arman el expediente de defensa regulatoria correlacionando controles, evidencia y sanciones de forma coordinada."},{"nivel":5,"ancla":"5 Gestión autónoma del programa (recordatorios, consolidación de evidencia, alertas de brecha) dentro de políticas, con revisión por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Gestión del programa de compliance y ética","tipo":"S4DS","categoria":"Gobierno de cumplimiento del CRM transaccional","coberturaS4DS":"módulo Compliance · versionado de P&P · registro de casos disciplinarios · expediente de defensa regulatoria recuperable · MCP compliance/governance tools","nota":"Consolida políticas, capacitación, sanciones y evidencia de auditoría en un expediente único y recuperable."},{"nombre":"Plataforma de gestión de cumplimiento (GRC)","tipo":"tercero","categoria":"Gobierno, riesgo y cumplimiento (GRC)","ejemplos":["OneTrust","AuditBoard","ServiceNow GRC"],"nota":"Mapea controles, auditoría y expediente disciplinario de forma trazable y exportable ante un regulador."},{"nombre":"LMS (capacitación recurrente)","tipo":"tercero","categoria":"Learning management / habilitación de campo","ejemplos":["Cornerstone OnDemand","Litmos","Rallyware"],"nota":"Sostiene la capacitación recurrente de la fuerza de ventas y del personal, con seguimiento de vencimientos y finalización."},{"nombre":"Gestión documental de políticas (policy management)","tipo":"tercero","categoria":"Policy management","ejemplos":["PowerDMS","Ironclad"],"nota":"Versiona, comunica y controla el acceso a las políticas y procedimientos vigentes."}],"agentesYUseCase":[{"useCase":"Copiloto de consolidación de evidencia: agrega controles, capacitación y sanciones en un borrador de expediente de defensa regulatoria para revisión.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — arma el borrador, humano valida y firma","valor":"reduce a horas la preparación de un expediente que de otro modo requeriría búsqueda manual dispersa"},{"useCase":"Agente supervisado que rastrea vencimientos de capacitación, casos disciplinarios abiertos y brechas de control detectadas en auditoría, y los reporta al comité de compliance.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — reporta, el comité decide","valor":"sostiene la disciplina del programa sin depender de que alguien recuerde revisar cada frente por separado"},{"useCase":"Correlación automática de controles, evidencia y sanciones para armar el expediente de defensa regulatoria de forma coordinada.","t
1ipo":"tercero","nivelAutonomia":"agentes coordinados (nivel 4)","ejemplos":["plataformas GRC con módulos de case management"],"valor":"prepara el expediente de defensa antes de que un regulador lo exija, no durante la crisis"}],"metadata":{"evidenciaEsperada":"P&P versionadas y comunicadas + plan de capacitación recurrente + régimen disciplinario con actas del órgano decisor + informe de auditoría de controles y expediente de defensa regulatoria.","dolorAsociado":"Gobierno de compliance fragmentado sin dueño único ni comité; sanciones inconsistentes y ausencia de expediente de defensa cuando llega el escrutinio regulatorio.","frenteRecomendacion":"Gobierno/Roles/Tercerización","fuente":"MASTER-C01 §3 (co-propiedad Field Ops/Compliance; comité de compliance; CRO; escalamiento progresivo; versionado de P&P), §10 (archivo recuperable para defensa post-terminación); orden FTC Herbalife (2016, Independent Compliance Auditor); DSA/WFDSA Code of Ethics"},"camposFaltantes":[]},{"practiceId":"C01-09-PR-07","processId":"C01","temaId":"c01-cumplimiento-y-etica-del-enrolamiento","nombre":"Vigilancia de la clasificación contratista independiente vs. empleado","pregunta":"¿Vigilamos que la clasificación como contratista independiente sea genuina y sustentada por contrato y por los factores de realidad económica aplicables por jurisdicción, con evidencia de defensa?","enunciado":"La organización gobierna y vigila la clasificación del vendedor como contratista independiente, asegurando que la relación se sustente en el contrato escrito exigido y que los factores de la realidad económica y de control no deriven, en la práctica, en una relación de dependencia laboral encubierta. Se monitorean los criterios de clasificación aplicables por jurisdicción y se conserva evidencia de que la independencia es genuina, de modo que la base legal sobre la que descansa todo el modelo —fiscal, de comisiones y de responsabilidad— quede protegida frente al riesgo de reclasificación en litigio o auditoría.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin gobierno de la clasificación; se asume el estatus de contratista sin contrato ni revisión de los factores de dependencia."},{"nivel":1,"ancla":"1 Existe un contrato tipo, pero no se vigilan los factores de control ni las diferencias por jurisdicción."},{"nivel":2,"ancla":"2 Criterios de clasificación conocidos, aplicados de forma desigual; sin monitoreo ni evidencia de independencia."},{"nivel":3,"ancla":"3 Clasificación definida: contrato escrito vigente, criterios por jurisdicción documentados y responsable de la revisión."},{"nivel":4,"ancla":"4 Vigilancia gestionada: monitoreo de factores de reclasificación, evidencia de independencia conservada y revisión ante cambios normativos o de práctica."},{"nivel":5,"ancla":"5 Ninguna jurisdicción opera sin una evaluación vigente del riesgo de reclasificación: la práctica se ajusta con evidencia documentada de independencia antes de cada cambio normativo relevante, no después de un litigio."}]},"sistemas":{"referenciaMp":"§8.3 (misclassification; captura y versión de la cláusula), §3 (versionado de P&P)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; el estatus contractual no queda registrado ni la cláusula versionada."},{"nivel":1,"ancla":"1 Contrato en archivo suelto, sin control de versión ni vínculo al registro del vendedor."},{"nivel":2,"ancla":"2 Repositorio con los contratos, sin seguimiento de los factores de clasificación por jurisdicción."},{"nivel":3,"ancla":"3 Sistema que registra y versiona la cláusula contractual de contratista y la liga al registro del vendedor."},{"nivel":4,"ancla":"4 Plataforma que consolida evidencia de independencia y monitorea indicadores de riesgo de reclasificación por jurisdicción."},{"nivel":5,"ancla":"5 Ecosistema donde contrato, evidencia de independencia y criterios por jurisdicción están integrados y disponibles para auditoría o litigio."}]},"agentico":{"anclas":[{"nivel":0,"ancla":"0 Sin IA; la evaluación del riesgo de clasificación es completamente manual."},{"nivel":1,"ancla":"1 IA que ayuda a resumir criterios de clasificación por jurisdicción bajo demanda."},{"nivel":2,"ancla":"2 Copiloto que contrasta la práctica con los factores de clasificación y marca indicadores de riesgo para revisión."},{"nivel":3,"ancla":"3 Agente supervisado que detecta señales de dependencia laboral encubierta (control, exclusividad) y las reporta a Legal/Compliance."},{"nivel":4,"ancla":"4 Agentes que correlacionan factores de realidad económica por jurisdicción y priorizan el riesgo de reclasificación de forma coordinada."},{"nivel":5,"ancla":"5 Vigilancia autónoma del riesgo de clasificación dentro de políticas, con alertas y expediente de defensa, y escalamiento por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Registro y versionado de la clasificación contractual","tipo":"S4DS","categoria":"Contratos y compliance del CRM transaccional","coberturaS4DS":"módulo Contratos/Compliance · versionado de la cláusula de contratista independiente ligada al vendedor · MCP compliance/contract tools","nota":"Liga la cláusula contractual vigente al registro del vendedor con historial de versiones, disponible para auditoría o litigio."},{"nombre":"Gestión del ciclo de vida de contratos (CLM)","tipo":"tercero","categoria":"Contract Lifecycle Management","ejemplos":["Ironclad","DocuSign CLM"],"nota":"Versiona y liga el contrato de contratista a cada vendedor con historial de cambios y firma auditable."},{"nombre":"Plataforma de gestión de cumplimiento (GRC)","tipo":"tercero","categoria":"Gobierno, riesgo y cumplimiento (GRC)","ejemplos":["OneTrust","AuditBoard"],"nota":"Monitorea indicadores de riesgo de reclasificación por jurisdicción y conserva la evidencia de independencia genuina."},{"nombre":"Análisis normativo laboral multi-jurisdicción","tipo":"tercero","categoria":"Compliance laboral / HR regulatory intelligence","ejemplos":["Mineral","Littler CaseSmart"],"nota":"Mantiene actualizados los criterios de clasificación aplicables por estado/país frente a cambios normativos o de enforcement."}],"agentesYUseCase":[{"useCase":"Copiloto que contrasta la práctica de campo con los factores de clasificación (control, exclusividad, riesgo económico) y marca indicadores de riesgo por jurisdicción.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — contrasta y marca, humano evalúa","valor":"hace visible el riesgo de reclasificación antes de que un litigio o auditoría lo exponga"},{"useCase":"Agente supervisado que detecta señales de dependencia laboral encubierta (control excesivo, exclusividad de facto) y las reporta a Legal/Compliance con la jurisdicción aplicable.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — detecta y reporta; Legal decide","valor":"convierte una revisión legal ad-hoc en una vigilancia continua de los factores que realmente definen la relación"},{"useCase":"Correlación de factores de realidad económica por jurisdicción para priorizar el riesgo de reclasificación de forma coordinada.","t
1ipo":"tercero","nivelAutonomia":"agentes coordinados (nivel 4)","ejemplos":["plataformas de compliance laboral multi-jurisdicción"],"valor":"prioriza la atención de Legal en las jurisdicciones de mayor exposición cuando la red opera en múltiples países/estados"}],"metadata":{"evidenciaEsperada":"Contrato escrito de contratista independiente versionado y ligado al vendedor + criterios de clasificación por jurisdicción + evidencia conservada de que la independencia es genuina.","dolorAsociado":"Clasificación errónea empleado vs. contratista —base legal de todo el modelo— expuesta a litigio privado y a tests estatales más estrictos; ausencia de evidencia de independencia cuando llega la auditoría.","frenteRecomendacion":"Gobierno/Roles/Tercerización","fuente":"MASTER-C01 §8.3 (misclassification; contrato escrito 26 U.S.C. §3508; captura y versión de la cláusula), §3 (versionado de P&P); DOL/FLSA regla 2024 y cambio de enforcement may-2025; California AB5/ABC test"},"camposFaltantes":[]},{"practiceId":"C01-10-PR-01","processId":"C01","temaId":"c01-datos-fuente-unica-y-gobierno","nombre":"Sistema de registro único del vendedor (identidad-genealogía-contrato-comisión) como dato maestro coherente","pregunta":"¿Existe un sistema de registro único y autoritativo que unifica identidad, genealogía, contrato y comisión del vendedor como un solo dato maestro coherente, en lugar de mantener esas piezas dispersas en silos por área?","enunciado":"La organización mantiene un sistema de registro único y autoritativo del vendedor que unifica su identidad, su posición en la genealogía, su contrato y su relación de comisión como un solo dato maestro coherente, en lugar de dispersar esas piezas en silos que cada área captura y mantiene por separado. El registro maestro es el origen del que derivan las demás vistas: la relación vendedor-compañía se define una sola vez y se propaga, de modo que no conviven versiones duplicadas ni contradictorias del mismo vendedor entre las áreas que lo operan.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 No hay registro maestro; identidad, genealogía, contrato y comisión viven en silos distintos que cada área captura y mantiene por su cuenta."},{"nivel":1,"ancla":"1 Se reconoce la necesidad de un registro unificado, pero en la práctica cada pieza se lleva por separado y se concilia a mano cuando surge un problema."},{"nivel":2,"ancla":"2 Algunas piezas del registro conviven en un mismo lugar, pero sin una definición de cuál es la fuente autoritativa ni reglas de propagación."},{"nivel":3,"ancla":"3 Registro único definido: identidad, genealogía, contrato y comisión se gestionan como un dato maestro coherente con fuente autoritativa declarada."},{"nivel":4,"ancla":"4 Registro maestro gestionado; se mide y audita que las áreas operen sobre la misma versión y se corrigen las duplicidades o divergencias detectadas."},{"nivel":5,"ancla":"5 Registro maestro optimizado; la coherencia del dato del vendedor es continua y las divergencias se previenen en origen, sin reconciliación manual entre áreas."}]},"sistemas":{"referenciaMp":"§5 (DMS como sistema de registro de la relación vendedor-compañía —identidad, genealogía, contrato, comisión— que sincroniza unidireccionalmente hacia ERP y CRM), §10 (largo plazo: DMS como sistema de registro único de identidad-genealogía-contrato-comisión)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta de registro; los datos del vendedor viven en hojas de cálculo y sistemas sueltos sin un sistema de registro que mande."},{"nivel":1,"ancla":"1 Varias herramientas o planillas guardan partes del registro del vendedor, reconciliadas a mano y con duplicados frecuentes."},{"nivel":2,"ancla":"2 Sistemas especializados por función (identidad, genealogía, contrato, comisión), cada uno con su copia, transferida manualmente entre ellos."},{"nivel":3,"ancla":"3 Plataforma de gestión de vendedores que consolida identidad, genealogía, contrato y comisión como registro del que los demás sistemas leen."},{"nivel":4,"ancla":"4 Plataforma que expone el registro maestro en tiempo real y sincroniza unidireccionalmente hacia los sistemas corporativos, con la fuente de verdad clara."},{"nivel":5,"ancla":"5 Ecosistema donde el dato maestro del vendedor se define una vez y fluye a todas las capas sin transferencias ni reconciliación manual."}]},"agentico":{"referenciaMp":"§6 (detección de inconsistencias de dato maestro entre sistemas; anomalías sobre el ciclo de vida)","anclas":[{"nivel":0,"ancla":"0 Sin IA; detectar que dos sistemas guardan datos distintos del mismo vendedor es manual y tardío."},{"nivel":1,"ancla":"1 Alertas por regla fija cuando una reconciliación encuentra un registro divergente o duplicado."},{"nivel":2,"ancla":"2 Copiloto que consulta y compara el registro de un vendedor entre sistemas a pedido."},{"nivel":3,"ancla":"3 Agente supervisado que reconcilia el registro maestro entre sistemas y señala divergencias y duplicados para corregirlos."},{"nivel":4,"ancla":"4 Agentes que vigilan la coherencia del dato maestro a través de todas las capas y anticipan divergencias de forma continua."},{"nivel":5,"ancla":"5 Reconciliación autónoma dentro de políticas del registro maestro entre sistemas, con corrección en origen y escalamiento por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Registro maestro del vendedor (DMS transaccional)","tipo":"S4DS","categoria":"Sistema de registro / dato maestro del CRM transaccional","coberturaS4DS":"módulo Vendedores · identidad-genealogía-contrato-comisión como registro único · MCP master-data tools","nota":"Actúa como la fuente autoritativa única de la relación vendedor-compañía, de la que leen los demás módulos y sistemas."},{"nombre":"Distributor Management System (DMS/MLM software)","tipo":"tercero","categoria":"Plataforma núcleo de gestión de vendedores","ejemplos":["Exigo","DirectScale","ByDesign (Freedom)","Epixel"],"nota":"Plataformas de referencia del vertical que operan como sistema de registro de genealogía, comisiones y compliance."},{"nombre":"Plataforma de gobierno y calidad de dato maestro (MDM)","tipo":"tercero","categoria":"Master Data Management","ejemplos":["Collibra","Informatica MDM","Talend"],"nota":"Cuando el dato maestro del vendedor se gobierna con una capa MDM dedicada por encima o junto al DMS, con linaje y reglas de propagación explícitas."},{"nombre":"ERP corporativo (consumidor, no fuente)","tipo":"tercero","categoria":"Sistema financiero de registro","ejemplos":["SAP","Oracle NetSuite","Microsoft Dynamics 365"],"nota":"Recibe el dato maestro del vendedor por sincronización unidireccional desde el DMS; nunca debe convertirse en una segunda fuente que lo reescriba."}],"agentesYUseCase":[{"useCase":"Auditor de coherencia del registro maestro: compara periódicamente identidad, genealogía, contrato y comisión del mismo vendedor entre sistemas y reporta cualquier pieza que no coincida con la versión declarada como autoritativa.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — detecta y reporta; el humano corrige","valor":"expone el drift entre silos antes de que se traduzca en una comisión o una genealogía incorrecta"},{"useCase":"Copiloto de resolución 360°: ante una consulta sobre un vendedor, ensambla en segundos la vista unificada de identidad-genealogía-contrato-comisión desde el registro maestro, sin que el analista reconstruya manualmente entre sistemas.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — responde y explica; el humano decide","valor":"elimina el trabajo manual de reconciliación que hoy sustituye a un registro único de verdad"},{"useCase":"Agente de linaje de dato maestro: rastrea de qué sistema y en qué momento se originó cada atributo del registro del distribiuidor, útil para diagnosticar dónde se rompió la jerarquía de fuente única cuando aparece una divergencia.","tipo":"tercero","nivelAutonomia":"agente supervisado (nivel 3)","ejemplos":["capacidades de linaje de datos de plataformas MDM (p. ej. Collibra, Informatica)"],"valor":"convierte una discrepancia de dato en un diagnóstico trazable en vez de una investigación manual"}],"metadata":{"evidenciaEsperada":"Definición del sistema de registro único del vendedor (identidad, genealogía, contrato y comisión como dato maestro) con su fuente autoritativa declarada y sus reglas de propagación, más evidencia de que las áreas operan sobre la misma versión.","dolorAsociado":"Identidad, genealogía, contrato y comisión dispersos en silos que cada área captura por separado: conviven versiones duplicadas y contradictorias del mismo vendedor y la fragmentación de la fuente de verdad se vuelve la falla estructural más citada del sector.","frenteRecomendacion":"Tecnología e Integración","fuente":"MASTER-C01 §1 (el enrolamiento abre una relación contractual, un nodo de genealogía y una identidad autorizada; IT es dueño de la integridad del dato maestro/genealogía), §5 (DMS como sistema de registro de la relación vendedor-compañía —identidad, genealogía, contrato, comisión— que sincroniza unidireccionalmente hacia ERP y CRM, nunca al revés), §10 (largo plazo: DMS como sistema de registro único de identidad-genealogía-contrato-comisión)"},"camposFaltantes":[]},{"practiceId":"C01-10-PR-02","processId":"C01","temaId":"c01-datos-fuente-unica-y-gobierno","nombre":"Calidad y unicidad del dato maestro: i
1dentidad única, deduplicación e integridad referencial","pregunta":"¿El dato maestro del vendedor tiene identificador único, controles de deduplicación e integridad referencial entre identidad-genealogía-contrato-pago, de modo que no se abren cuentas repetidas ni nodos huérfanos y cada posición apunta a una identidad y un contrato consistentes?","enunciado":"La organización garantiza la calidad y la unicidad del dato maestro del vendedor mediante un identificador único por persona, controles de deduplicación que impiden abrir posiciones o cuentas repetidas de un mismo individuo, e integridad referencial entre identidad, genealogía, contrato y pago, de modo que cada nodo de la red apunta a un contrato y a una identidad verificada consistentes. Los duplicados, las cuentas fantasma y los nodos huérfanos se previenen y se detectan como defectos de calidad del dato, en lugar de descubrirse tarde por una disputa de comisión o un hallazgo de fraude.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin controles de unicidad; un mismo individuo puede abrir varias cuentas o posiciones y nadie garantiza que genealogía, contrato e identidad se correspondan."},{"nivel":1,"ancla":"1 La unicidad y la correspondencia entre datos se revisan de forma manual y esporádica, después del hecho."},{"nivel":2,"ancla":"2 Algunas reglas de deduplicación existen pero se aplican parcialmente; los nodos huérfanos y las cuentas fantasma aparecen sin control."},{"nivel":3,"ancla":"3 Identificador único por vendedor y reglas de deduplicación e integridad referencial definidas entre identidad, genealogía, contrato y pago."},{"nivel":4,"ancla":"4 Calidad del dato gestionada; se miden duplicados, huérfanos e inconsistencias referenciales y se corrigen contra un umbral definido."},{"nivel":5,"ancla":"5 Calidad del dato optimizada; los defectos de unicidad e integridad se previenen en la captura y la tendencia de calidad se sostiene y mejora."}]},"sistemas":{"referenciaMp":"§2.3 (KYC como base de identidad verificada), §5 (integridad del dato maestro; deuda técnica de registros duplicados y bases duales), §8.5 (cuentas fantasma, cross-lining/dual enrollment que corrompen genealogía y comisiones)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; no hay forma sistemática de impedir cuentas duplicadas ni de validar que un nodo apunte a un contrato e identidad reales."},{"nivel":1,"ancla":"1 La deduplicación se hace a mano en hoja de cálculo, sin identificador único que la respalde."},{"nivel":2,"ancla":"2 Sistema especializado que registra vendedores, pero sin control de unicidad ni validación referencial entre identidad, genealogía y contrato."},{"nivel":3,"ancla":"3 Plataforma con identificador único que aplica reglas de deduplicación y verifica la integridad referencial al crear o modificar el registro."},{"nivel":4,"ancla":"4 Plataforma que valida unicidad e integridad en tiempo real y bloquea de forma auditable la creación de duplicados o de nodos huérfanos."},{"nivel":5,"ancla":"5 Ecosistema donde la identidad verificada, la genealogía, el contrato y el pago se enlazan y validan de extremo a extremo sin capturas redundantes."}]},"agentico":{"referenciaMp":"§6 (scoring de anomalías; detección de cuentas fantasma y velocidad/geografía), §8.5 (control SOTA: scoring de anomalías de estructura)","anclas":[{"nivel":0,"ancla":"0 Sin IA; identificar duplicados sutiles, cuentas fantasma o nodos incoherentes depende de la revisión manual."},{"nivel":1,"ancla":"1 Alertas por regla fija ante coincidencias exactas de datos (mismo documento o correo)."},{"nivel":2,"ancla":"2 Copiloto que consulta posibles duplicados o incoherencias de un vendedor a pedido."},{"nivel":3,"ancla":"3 Agente supervisado que puntúa candidatos a duplicado o cuenta fantasma y señala inconsistencias referenciales para revisión."},{"nivel":4,"ancla":"4 Agentes que correlacionan identidad, genealogía y patrones de comportamiento en la red para detectar duplicados y estructuras anómalas de forma continua."},{"nivel":5,"ancla":"5 Depuración autónoma dentro de políticas de la calidad del dato maestro, con corrección en origen y escalamiento de casos límite."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Validación de unicidad e integridad referencial del registro","tipo":"S4DS","categoria":"Calidad de dato maestro del CRM transaccional","coberturaS4DS":"identificador único por vendedor · reglas de deduplicación en tiempo real · validación referencial identidad-genealogía-contrato-pago · MCP data-quality tools","nota":"Bloquea en la escritura la creación de duplicados o de nodos que no apuntan a una identidad y un contrato reales."},{"nombre":"Plataforma de verificación de identidad / KYC","tipo":"tercero","categoria":"Identity verification","ejemplos":["Trulioo","Onfido","Jumio","Persona"],"nota":"Ancla el identificador único a una identidad realmente verificada, la base de la que depende toda deduplicación posterior."},{"nombre":"Herramienta de resolución de identidad / detección de duplicados","tipo":"tercero","categoria":"Identity resolution / data matching","ejemplos":["Senzing","Melissa Data"],"nota":"Correlaciona señales de contacto y documento entre registros para detectar duplicados sutiles que un match exacto no captura."}
1,{"nombre":"Plataforma de calidad y gobierno de datos (MDM/data quality)","tipo":"tercero","categoria":"Master Data Management / Data Quality","ejemplos":["Collibra","Informatica Data Quality","Talend"],"nota":"Mide y gestiona duplicados, huérfanos e inconsistencias referenciales como un indicador de calidad con tendencia, no como hallazgos aislados."}],"agentesYUseCase":[{"useCase":"Puntuador de candidatos a duplicado: analiza cada alta nueva contra el dato maestro existente y puntúa la probabilidad de que sea la misma persona ya registrada, incluso ante variaciones de nombre, dirección o documento.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — puntúa y señala; el humano confirma antes de bloquear el alta","valor":"detecta duplicados sutiles que un match exacto de documento o correo no captura"},{"useCase":"Detector de cuentas fantasma y estructuras anómalas: correlaciona identidad, genealogía y patrones de comportamiento en la red (velocidad de alta, geografía) para señalar posiciones que no corresponden a una persona real activa.","tipo":"S4DS","nivelAutonomia":"agente supervisado → multi-agente (nivel 3-4)","valor":"cierra el vector de fraude interno de cross-lining, spillover abuse y cuentas fantasma antes de que corrompa comisiones"},{"useCase":"Copiloto de consulta de integridad: responde a pedido si un nodo, contrato o identidad específicos tienen alguna inconsistencia referencial pendiente, sin que el analista deba cruzar manualmente los sistemas.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — responde; el humano decide la corrección","valor":"acelera el diagnóstico de un caso puntual reportado por soporte o por el propio vendedor"}],"metadata":{"evidenciaEsperada":"Reglas de identificador único y deduplicación vigentes, definición de la integridad referencial entre identidad-genealogía-contrato-pago, y un reporte de calidad del dato (duplicados, huérfanos, inconsistencias) con su evolución.","dolorAsociado":"Sin unicidad ni integridad referencial se multiplican los duplicados, las cuentas fantasma y los nodos huérfanos: la genealogía se corrompe, las comisiones se calculan sobre posiciones irreales y el problema se descubre por una disputa o un fraude, no por control de calidad.","frenteRecomendacion":"Eficiencia/Simplificación de Proceso","fuente":"MASTER-C01 §1 (nodo en árbol de genealogía que altera comisiones de terceros; identidad autorizada), §2.3 (KYC que ancla identidad verificada), §5 (integridad del dato maestro; la deuda técnica de registros duplicados y bases duales es el principal obstáculo de modernización), §8.5 (cross-lining/dual enrollment y cuentas fantasma corrompen genealogía y comisiones; control SOTA de scoring de anomalías)"},"camposFaltantes":[]},{"practiceId":"C01-10-PR-03","processId":"C01","temaId":"c01-datos-fuente-unica-y-gobierno","nombre":"Audit trail inmutable del dato maestro y del ciclo de vida (quién, qué, cuándo y por qué), con retención y no-repudio","pregunta":"¿Todo cambio en el dato maestro y en el ciclo de vida del vendedor queda en un audit trail inmutable —quién, qué (antes/después), cuándo y por qué— con retención y no-repudio, en lugar de sobrescribir los datos y perder el historial?","enunciado":"La organización registra todo cambio en el dato maestro del vendedor y en su ciclo de vida en un rastro de auditoría inmutable que captura quién lo hizo, qué cambió (valor anterior y nuevo), cuándo y por qué, con un periodo de retención definido y garantía de no-repudio, en lugar de sobrescribir los datos y perder el historial. Ningún cambio —de identidad, genealogía, contrato o comisión— puede ejecutarse de forma silenciosa: cada modificación es visible, atribuible y reconstruible después del hecho, de modo que la organización puede defender una decisión ante el vendedor, un auditor o un regulador.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin registro de cambios; los datos del vendedor se sobrescriben y no queda rastro de quién los cambió, qué cambió ni por qué."},{"nivel":1,"ancla":"1 Se anotan algunos cambios de forma informal y esporádica, sin capturar actor, motivo o valor anterior de forma consistente."},{"nivel":2,"ancla":"2 Se registran cambios pero con datos incompletos (falta el motivo o el actor) y sin garantía de que el registro no se altere."}
1,{"nivel":3,"ancla":"3 Cada cambio del dato maestro y del ciclo de vida se registra con actor, valor anterior/nuevo, timestamp y motivo, con retención definida."},{"nivel":4,"ancla":"4 Audit trail gestionado e inmutable; se audita la completitud de los registros y se detectan cambios sin motivo, sin actor o fuera de política de retención."},{"nivel":5,"ancla":"5 Ningún cambio del dato maestro carece de causa, actor o verificación de no-repudio; el historial completo se usa para depurar los controles que generan los cambios detectados."}]},"sistemas":{"referenciaMp":"§3 (audit log inmutable donde los cambios son visibles, atribuibles y reversibles; 'admins cannot silently move partners'), §4 (cada transición es un evento versionado y auditable end-to-end), §10 (retención de sustentación por 3 años; archivo recuperable de comunicaciones durante y después de la relación)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; los cambios del dato del vendedor no dejan rastro recuperable."},{"nivel":1,"ancla":"1 Bitácora manual en hoja de cálculo, editable y sin garantía de integridad ni retención."},{"nivel":2,"ancla":"2 Sistema especializado que registra algunos cambios, sin inmutabilidad ni captura completa de actor/motivo/valor anterior."},{"nivel":3,"ancla":"3 Plataforma que registra cada cambio con actor, valor anterior/nuevo, timestamp y motivo, con historial consultable y retención configurada."},{"nivel":4,"ancla":"4 Plataforma con audit log inmutable en tiempo real donde cada cambio es visible, atribuible y reversible de forma trazable, con no-repudio garantizado."},{"nivel":5,"ancla":"5 Ecosistema donde los cambios fluyen como eventos versionados encadenados entre capas, con retención y no-repudio aplicad
1os sin registro manual."}]},"agentico":{"referenciaMp":"§6 (detección de anomalías sobre el historial de cambios; riesgo regulatorio de earnings claims generados por IA a auditar)","anclas":[{"nivel":0,"ancla":"0 Sin IA; revisar si un cambio del dato maestro fue legítimo o anómalo es manual y esporádico."},{"nivel":1,"ancla":"1 Alertas por regla fija ante un tipo de cambio marcado como sensible."},{"nivel":2,"ancla":"2 Copiloto que resume el historial de cambios de un vendedor a pedido."},{"nivel":3,"ancla":"3 Agente supervisado que revisa el audit trail y señala cambios sin motivo, fuera de secuencia o atípicos."},{"nivel":4,"ancla":"4 Agentes que correlacionan cambios a través de la red y del tiempo para detectar patrones anómalos de manipulación del dato de forma continua."},{"nivel":5,"ancla":"5 Vigilancia autónoma dentro de políticas del historial del dato maestro, con escalamiento de anomalías a revisión humana."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Audit log inmutable del dato maestro y del ciclo de vida","tipo":"S4DS","categoria":"Auditoría / trazabilidad del CRM transaccional","coberturaS4DS":"registro de cambios con actor/valor anterior-nuevo/timestamp/motivo · retención configurable · MCP audit-trail tools","nota":"Hace visible, atribuible y reconstruible cada cambio de identidad, genealogía, contrato o comisión, con garantía de no-repudio."},{"nombre":"Plataforma de gestión de vendedores (DMS) con audit log nativo","tipo":"tercero","categoria":"Plataforma núcleo con auditoría integrada","ejemplos":["Exigo","DirectScale","ByDesign (Freedom)","Epixel"],"nota":"El audit trail debe evaluarse como capacidad nativa del DMS, no como un log genérico de aplicación agregado después."},{"nombre":"Plataforma de gestión documental y retención","tipo":"tercero","categoria":"Records management / retención regulatoria","ejemplos":["OpenText","Iron Mountain InSight","SharePoint/Purview"],"nota":"Sostiene la política de retención de largo plazo (p. ej. años de sustentación) y el archivo recuperable de comunicaciones del vendedor."},{"nombre":"Plataforma de logging inmutable / WORM storage","tipo":"tercero","categoria":"Almacenamiento append-only / integridad de logs","ejemplos":["AWS QLDB / S3 Object Lock","Azure Immutable Blob Storage"],"nota":"Garantiza a nivel de infraestructura que el rastro de auditoría no puede editarse ni borrarse una vez escrito."}],"agentesYUseCase":[{"useCase":"Revisor de completitud del audit trail: verifica que cada cambio sensible tenga actor, motivo y valor anterior/nuevo capturados, y señala los registros incompletos o fuera de la política de retención.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — detecta y reporta; el humano corrige el proceso de captura","valor":"evita que un audit trail incompleto se descubra recién cuando se necesita para una defensa regulatoria"},{"useCase":"Detector de anomalías en el historial de cambios: correlaciona cambios a través del tiempo y de la red para señalar patrones atípicos de manipulación del dato maestro (por ejemplo, una secuencia de cambios de sponsor fuera del horario o del rol habitual del actor).","tipo":"S4DS","nivelAutonomia":"agente supervisado → multi-agente (nivel 3-4)","valor":"convierte el audit trail de un registro pasivo en un mecanismo de vigilancia activa contra fraude interno"},{"useCase":"Copiloto de reconstrucción de caso: ante una disputa de comisión o una sanción cuestionada, ensambla la línea de tiempo completa de cambios relevantes del vendedor con su motivo y actor, lista para presentarse a un auditor o regulador.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — ensambla y explica; el humano presenta y decide","valor":"reduce de días a minutos el tiempo de preparar la sustentación documental de un caso"}],"metadata":{"evidenciaEsperada":"Muestra del audit trail del dato maestro y del ciclo de vida mostrando actor, valor anterior/nuevo, timestamp y motivo por cambio, con la política de retención vigente y evidencia de que el registro es inmutable y garantiza no-repudio.","dolorAsociado":"Dato que se sobrescribe sin dejar rastro de quién, qué, cuándo y por qué: sin audit trail inmutable no se puede reconstruir un ajuste de comisión disputado, defender una suspensión ni demostrar la sustentación que exige el regulador, y un administrador puede mover posiciones de forma silenciosa.","frenteRecomendacion":"Gobierno/Roles/Tercerización","fuente":"MASTER-C01 §3 (audit log inmutable donde 'admins cannot silently move partners; the move is visible, attributable, and reversible'), §4 (cada transición es un evento versionado y auditable end-to-e
1nd), §8.5 (audit trail inmutable de cambios de sponsor con aprobación dual como control SOTA), §10 (retención de sustentación por 3 años; archivo recuperable de comunicaciones del vendedor durante y después de la relación para defensa regulatoria)"},"camposFaltantes":[]},{"practiceId":"C01-10-PR-04","processId":"C01","temaId":"c01-datos-fuente-unica-y-gobierno","nombre":"Segregación de funciones (maker-checker) sobre operaciones sensibles del dato del vendedor","pregunta":"¿Las operaciones sensibles del vendedor —altas, cambios de genealogía/sponsor, sanciones y liberación de comisiones— están sujetas a segregación de funciones (maker-checker), de modo que quien origina el cambio no es quien lo aprueba, con simulación de impacto en los casos de mayor riesgo?","enunciado":"La organización aplica segregación de funciones sobre las operaciones sensibles del dato del vendedor —altas, cambios de genealogía o de sponsor, sanciones y liberación de comisiones o pagos retenidos— mediante un esquema de maker-checker en el que quien origina un cambio no es quien lo aprueba, con roles y niveles de aprobación definidos y, en los casos de mayor riesgo, simulación del impacto antes de confirmar. De este modo ningún cambio crítico depende de una sola persona y las decisiones de alto riesgo quedan sujetas a un segundo control explícito antes de surtir efecto.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin segregación de funciones; una sola persona origina y ejecuta cambios sensibles (genealogía, sanciones, pagos) sin segundo control."},{"nivel":1,"ancla":"1 La doble revisión ocurre de manera informal y solo cuando alguien lo recuerda, sin roles ni reglas definidas."},{"nivel":2,"ancla":"2 Hay una intención de maker-checker para algunos casos, pero se aplica de forma inconsistente y sin cubrir todas las operaciones sensibles."},{"nivel":3,"ancla":"3 Maker-checker definido sobre las operaciones sensibles: originador y aprobador separados, con roles y niveles de aprobación documentados."},{"nivel":4,"ancla":"4 Segregación gestionada; se audita que quien origina no apruebe, se mide el cumplimiento y los casos de mayor riesgo exigen simulación de impacto previa."},{"nivel":5,"ancla":"5 Segregación optimizada; los umbrales de aprobación y los controles se ajustan según el riesgo observado, sin puntos únicos de decisión en operaciones críticas."}]},"sistemas":{"referenciaMp":"§3 (maker-checker en decisiones de alto riesgo —camb
1io de sponsor, aprobación de KYC, liberación de comisión retenida—; control de cambios de genealogía con aprobación en dos factores y simulación de impacto antes de confirmar)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; cualquiera con acceso puede ejecutar un cambio sensible sin que el sistema exija una segunda aprobación."},{"nivel":1,"ancla":"1 La doble aprobación se coordina por correo o mensaje, sin que el sistema la imponga ni la registre."},{"nivel":2,"ancla":"2 Sistema especializado con permisos básicos, pero sin flujo de maker-checker que separe origen de aprobación."},{"nivel":3,"ancla":"3 Plataforma que aplica maker-checker sobre las operaciones sensibles: exige un aprobador distinto del originador y deja registro."},{"nivel":4,"ancla":"4 Plataforma que impone aprobación en dos factores y simulación de impacto antes de confirmar cambios críticos, de forma auditable."},{"nivel":5,"ancla":"5 Ecosistema donde la segregación de funciones y la simulación de impacto se aplican encadenadas a cada operación sensible sin intervención manual del control."}]},"agentico":{"referenciaMp":"§6 (scoring de riesgo para priorizar revisiones; detección de anomalías en cambios de sponsor/genealogía)","anclas":[{"nivel":0,"ancla":"0 Sin IA; evaluar el riesgo de un cambio sensible antes de aprobarlo depende del criterio del revisor."},{"nivel":1,"ancla":"1 Alertas por regla fija cuando un cambio sensible supera un umbral simple."},{"nivel":2,"ancla":"2 Copiloto que resume al aprobador el contexto y el posible impacto de un cambio antes de decidir."},{"nivel":3,"ancla":"3 Agente supervisado que puntúa el riesgo de cada operación sensible y prioriza cuáles requieren revisión más estricta."},{"nivel":4,"ancla":"4 Agentes que correlacionan el cambio con patrones de la red para anticipar impactos no deseados y sugerir aprobar/rechazar de forma coordinada."},{"nivel":5,"ancla":"5 Verificación autónoma dentro de políticas del control de operaciones sensibles, con aprobación automática de bajo riesgo y escalamiento del resto."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Flujo de maker-checker sobre operaciones sensibles","tipo":"S4DS","categoria":"Workflow de aprobación / control de cambios del CRM transaccional","coberturaS4DS":"aprobador distinto del originador exigido por el sistema · aprobación en dos factores · simulación de impacto pre-confirmación en cambios de genealogía · MCP approval-workflow tools","nota":"Impide técnicamente que una sola sesión origine y confirme un cambio sensible, y muestra el impacto proyectado antes de aplicarlo."},{"nombre":"Plataforma de gestión de vendedores (DMS) con permisos y aprobación por rol","tipo":"tercero","categoria":"Plataforma núcleo con control de acceso granular","ejemplos":["Exigo","DirectScale","ByDesign (Freedom)","Epixel"],"nota":"El maker-checker debe evaluarse como capacidad de permisos/flujo del propio DMS, no como un acuerdo informal entre roles."},{"nombre":"Plataforma de GRC / gestión de flujos de aprobación","tipo":"tercero","categoria":"Governance, Risk & Compliance / workflow","ejemplos":["ServiceNow GRC","MetricStream","Camunda"],"nota":"Formaliza y audita la matriz de aprobación por tipo de operación sensible cuando el gobierno excede lo que cubre el DMS."},{"nombre":"Plataforma de detección de fraude/AML","tipo":"tercero","categoria":"AML / fraud detection","ejemplos":["ComplyAdvantage","Sardine.ai"],"nota":"Aporta señales de riesgo que alimentan el criterio de qué operaciones requieren el nivel de aprobación más estricto."}],"agentesYUseCase":[{"useCase":"Puntuador de riesgo de operación sensible: evalúa cada solicitud de alta, cambio de sponsor, sanción o liberación de pago y asigna un nivel de riesgo que determina cuántos aprobadores y qué simulación se requieren.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — puntúa y prioriza; el humano aprueba o rechaza","valor":"concentra el esfuerzo de revisión humana en los casos de mayor riesgo real, no en todos por igual"},{"useCase":"Copiloto de simulación de impacto: ante un cambio de genealogía o sponsor propuesto, proyecta de forma inmediata qué comisiones de terceros se verían afectadas antes de que el aprobador confirme.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — proyecta y explica; el humano decide","valor":"convierte la aprobación de un cambio estructural en una decisión informada en vez de una firma ciega"},{"useCase":"Verificador de segregación efectiva: audita de forma continua que ningún originador haya aprobado su propia solicitud y señala cualquier excepción del flujo de maker-checker para revisión.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3)","valor":"confirma que la segregación de funciones se cumple en la práctica, no solo en el diseño del proceso"}],"metadata":{"evidenciaEsperada":"Matriz de operaciones sensibles con su esquema de maker-checker (originador y aprobador separados, niveles de aprobación), evidencia de que el sistema impide que quien origina apruebe, y muestra de una simulación de impacto en un cambio de genealogía de alto riesgo.","dolorAsociado":"Sin segregación de funciones un solo actor puede dar de alta, mover genealogía, levantar una sanción o liberar una comisión retenida sin segundo control: es el vector directo de fraude interno (cross-lining, spillover abuse, liberación indebida de pagos) y de errores irreversibles sin trazabilidad de quién decidió.","frenteRecomendacion":"Gobierno/Roles/Tercerización","fuente":"MASTER-C01 §3 (SoD apoyada en principios AML/KYC: maker-checker en decisiones de alto riesgo —camb
1io de sponsor, aprobación de KYC, liberación de comisión retenida— y control de cambios de genealogía con aprobación en dos factores, simulación de impacto antes de confirmar y audit log inmutable), §8.5 (fraude interno sobre la estructura: cross-lining, spillover abuse y cuentas fantasma; control SOTA de aprobación dual)"},"camposFaltantes":[]},{"practiceId":"C01-10-PR-05","processId":"C01","temaId":"c01-datos-fuente-unica-y-gobierno","nombre":"RACI y ownership del ciclo de vida del vendedor end-to-end, con comité y escalamiento","pregunta":"¿Existe un RACI del ciclo de vida del vendedor end-to-end —con responsable, accountable, consultado e informado por etapa— que resuelve la co-propiedad entre operaciones de campo, cumplimiento, finanzas y tecnología, con un comité de gobierno y rutas de escalamiento explícitas?","enunciado":"La organización define y comunica un RACI del ciclo de vida del vendedor de extremo a extremo que asigna, etapa por etapa (alta, verificación, activación, monitoreo, sanciones, terminación y versionado de políticas), quién es responsable, quién rinde cuentas, a quién se consulta y a quién se informa, resolviendo la co-propiedad típica entre las funciones de operaciones de campo, cumplimiento, finanzas y tecnología con una instancia de gobierno (comité) y rutas de escalamiento explícitas. El gobierno del proceso no depende de la buena voluntad ni del poder informal, sino de un mandato claro sobre quién decide qué en cada etapa.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Sin dueño ni RACI; el ciclo de vida del vendedor se opera en co-propiedad difusa y nadie rinde cuentas por el proceso end-to-end."},{"nivel":1,"ancla":"1 Los roles se conocen de forma informal y dependen de relaciones personales; no hay RACI escrito ni instancia de gobierno."},{"nivel":2,"ancla":"2 Existe un RACI parcial o en papel para algunas etapas, no comunicado ni aplicado de forma consistente."},{"nivel":3,"ancla":"3 RACI del ciclo de vida definido, documentado y comunicado por etapa, con un comité de gobierno y rutas de escalamiento explícitas."},{"nivel":4,"ancla":"4 Gobierno gestionado; el comité opera con cadencia, se mide el cumplimiento de responsabilidades y se resuelven las decisiones no escaladas que generan retrabajo."},{"nivel":5,"ancla":"5 Ninguna decisión no escalada del ciclo de vida queda sin resolver: el RACI y las rutas de escalamiento se revisan contra la fricción y las fallas de proceso documentadas en el periodo anterior."}]},"sistemas":{"referenciaMp":"§3 (modelo de gobierno/RACI por etapa; co-propiedad Field Ops-Compliance-Finance-IT; comité de compliance como órgano decisor; versionado de P&P)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta; el RACI y las decisiones de gobierno, si existen, viven en la memoria de las personas."},{"nivel":1,"ancla":"1 RACI en un documento suelto sin repositorio compartido ni control de versión."},{"nivel":2,"ancla":"2 Repositorio documental con el RACI y las actas del comité, de acceso y actualización manual."},{"nivel":3,"ancla":"3 Gestión documental con versionado y control de acceso del RACI, las políticas y las decisiones de gobierno."},{"nivel":4,"ancla":"4 Sistema de gobierno donde responsabilidades, decisiones y escalamientos quedan trazables y vinculados a las etapas del ciclo de vida."},{"nivel":5,"ancla":"5 Ecosistema donde el RACI se refleja en los permisos y flujos del proceso y se actualiza al cambiar los roles, sin desincronización manual."}]},"agentico":{"referenciaMp":"§6 (asistencia de gobierno; verificación de cumplimiento de responsabilidades y desvíos)","anclas":[{"nivel":0,"ancla":"0 Sin IA; verificar que cada etapa la ejecutó el responsable correcto es manual."},{"nivel":1,"ancla":"1 Recordatorios automáticos de responsables y fechas del ciclo de vida por calendario."},{"nivel":2,"ancla":"2 Copiloto que responde quién es responsable de una etapa o decisión según el RACI vigente."},{"nivel":3,"ancla":"3 Agente supervisado que verifica el cumplimiento de responsabilidades del RACI y señala decisiones tomadas fuera de su dueño."},{"nivel":4,"ancla":"4 Agentes que consolidan el estado de gobierno multi-etapa, detectan escalamientos pendientes y preparan el material del comité de forma coordinada."},{"nivel":5,"ancla":"5 Consolidación autónoma del estado de gobierno multi-etapa dentro de políticas, que detecta desviaciones del RACI y las escala a decisión humana; ninguna corrección del RACI se aplica sin esa decisión."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Trazabilidad de responsabilidades del ciclo de vida","tipo":"S4DS","categoria":"Gobierno del proceso / workflow del CRM transaccional","coberturaS4DS":"vinculación de responsables por etapa del ciclo de vida · registro de decisiones y escalamientos · MCP governance tools","nota":"Vincula el RACI declarado a las etapas reales del proceso, de modo que cada decisión queda asociada a su dueño esperado."},{"nombre":"Plataforma de gestión documental y control de versiones","tipo":"tercero","categoria":"Document management / gobierno de políticas","ejemplos":["SharePoint","Confluence","OpenText"],"nota":"Sostiene el RACI, las actas del comité de gobierno y el versionado de políticas y procedimientos (P&P) como documentos vivos y controlados."}
1,{"nombre":"Plataforma de GRC (Governance, Risk & Compliance)","tipo":"tercero","categoria":"Governance, Risk & Compliance","ejemplos":["ServiceNow GRC","MetricStream","Diligent"],"nota":"Formaliza el comité de gobierno, sus decisiones, escalamientos y el seguimiento de responsabilidades entre Field Ops, Compliance, Finance e IT."},{"nombre":"Herramienta de gestión de proyectos y workflow interdepartamental","tipo":"tercero","categoria":"Workflow / colaboración interdepartamental","ejemplos":["Asana","Jira","Monday.com"],"nota":"Operacionaliza el RACI en tareas y aprobaciones concretas cuando la co-propiedad Field Ops-Compliance-Finance-IT requiere coordinación de trabajo, no solo un documento de roles."}],"agentesYUseCase":[{"useCase":"Copiloto de RACI: responde a pedido quién es responsable, accountable, consultado o informado de una etapa o decisión concreta del ciclo de vida, según el RACI vigente.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — responde; el humano actúa","valor":"elimina la ambigüedad de 'quién decide esto' que hoy se resuelve preguntando por correo o chat"},{"useCase":"Verificador de cumplimiento del RACI: monitorea las decisiones tomadas en cada etapa y señala las que se ejecutaron fuera de su dueño declarado o sin la consulta requerida.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — detecta y reporta; el humano corrige el proceso","valor":"hace visible el patrón de decisiones fuera de ámbito antes de que se convierta en retrabajo recurrente"},{"useCase":"Agente preparador del comité de gobierno: consolida el estado de las etapas del ciclo de vida, los escalamientos pendientes y las excepciones de las últimas semanas en un resumen listo para la sesión del comité.","tipo":"S4DS","nivelAutonomia":"agente supervisado → multi-agente (nivel 3-4) — prepara y coordina; el comité decide","valor":"reduce el tiempo de preparación administrativa del comité y enfoca la sesión en las decisiones que realmente requieren su criterio"}],"metadata":{"evidenciaEsperada":"Matriz RACI vigente del ciclo de vida del vendedor por etapa (alta, verificación, activación, monitoreo, sanciones, terminación, versionado de P&P), acta o charter del comité de gobierno y las rutas de escalamiento documentadas y comunicadas.","dolorAsociado":"Co-propiedad difusa sin RACI ni comité: la fragmentación de gobierno entre operaciones de campo, cumplimiento, finanzas y tecnología es la falla estructural más citada del sector; sin dueño claro por etapa las decisiones se posponen, se toman fuera de su ámbito y generan retrabajo y exposición.","frenteRecomendacion":"Gobierno/Roles/Tercerización","fuente":"MASTER-C01 §1 (gobierno fragmentado: co-propiedad entre Field/Distributor Operations y Compliance, con Finance en KYC fiscal/comisiones e IT en la integridad del dato maestro; falla estructural más citada), §3 (no hay dueño único; matriz RACI por etapa del ciclo de vida; comité de compliance como órgano decisor de sanciones; escalamiento progresivo; versionado de P&P; gap de comité de Junta dedicado)"},"camposFaltantes":[]},{"practiceId":"C01-10-PR-06","processId":"C01","temaId":"c01-datos-fuente-unica-y-gobierno","nombre":"Integración con los sistemas corporativos como fuente única sincronizada, sin reconciliación manual","pregunta":"¿El registro maestro del vendedor se sincroniza con los sistemas corporativos de contabilidad, cliente y comisiones como fuente única de verdad (una sola dirección, una sola verdad consumida por todos), en lugar de que cada sistema mantenga su copia reconciliada a mano?","enunciado":"La organización integra el registro maestro del vendedor con los sistemas corporativos de contabilidad, de relación con el cliente y de liquidación de comisiones bajo un modelo de fuente única de verdad: el dato del vendedor se define una sola vez en su sistema de registro y se sincroniza hacia los demás de forma controlada y en una sola dirección, en lugar de que cada sistema conserve su propia copia que se concilia a mano. Una sola verdad del vendedor es consumida por todos los sistemas, de modo que la contabilidad, la atribución comercial y la comisión no divergen ni requieren reconciliaciones periódicas entre bases duplicadas.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 Cada sistema corporativo mantiene su propia copia del dato del vendedor; contabilidad, atribución y comisión pueden contradecirse."},{"nivel":1,"ancla":"1 Se intenta mantener el mismo dato en varios sistemas de forma manual, con desincronizaciones frecuentes y reconciliaciones a destiempo."},{"nivel":2,"ancla":"2 Hay un dato de referencia, pero los sistemas lo copian y se desactualiza entre sincronizaciones periódicas manuales."},{"nivel":3,"ancla":"3 Fuente única definida: el registro maestro se sincroniza hacia los sistemas corporativos con reglas claras de propagación en una sola dirección."},{"nivel":4,"ancla":"4 Integración gestionada; se mide y audita la consistencia del dato entre sistemas y se corrigen las divergencias detectadas."},{"nivel":5,"ancla":"5 Integración optimizada; la consistencia es continua y las divergencias se previenen en origen, sin re
1conciliación manual entre bases."}]},"sistemas":{"referenciaMp":"§5 (fragmentación de fuente de verdad entre DMS, ERP y CRM; DMS como sistema de registro que sincroniza unidireccionalmente hacia ERP y CRM, nunca al revés; migración con metodología Discovery→Extract→Transform→Validate→Parallel-run→Go-live), §8.6 (deuda técnica de fuente de datos fragmentada; bases duales reconciliadas manualmente)","anclas":[{"nivel":0,"ancla":"0 Sin integración; el dato del vendedor se transfiere entre sistemas por exportación manual o re-captura."},{"nivel":1,"ancla":"1 Cargas manuales periódicas entre sistemas mediante archivos, con divergencias entre bases duales."},{"nivel":2,"ancla":"2 Sistemas especializados conectados por interfaces puntuales, con reconciliación manual antes de cerrar contabilidad o comisiones."},{"nivel":3,"ancla":"3 Sistema de registro integrado que sincroniza el dato maestro hacia los sistemas corporativos de forma unidireccional y programada."},{"nivel":4,"ancla":"4 Plataforma que sincroniza en tiempo real hacia contabilidad, cliente y comisiones, con la fuente de verdad clara y trazable."},{"nivel":5,"ancla":"5 Ecosistema donde el dato del vendedor fluye a todas las capas corporativas sin transferencias ni reconciliación manual entre sistemas."}]},"agentico":{"referenciaMp":"§6 (detección de inconsistencias de dato maestro entre sistemas)","anclas":[{"nivel":0,"ancla":"0 Sin IA; detectar que contabilidad, cliente y comisiones muestran datos distintos del mismo vendedor es manual y tardío."},{"nivel":1,"ancla":"1 Alertas por regla fija cuando una reconciliación encuentra un dato divergente entre sistemas."},{"nivel":2,"ancla":"2 Copiloto que compara el dato de un vendedor entre los sistemas corporativos a pedido."},{"nivel":3,"ancla":"3 Agente supervisado que reconcilia el dato entre sistemas y señala las divergencias para corregirlas."},{"nivel":4,"ancla":"4 Agentes que vigilan la consistencia del dato maestro a través de todos los sistemas corporativos y anticipan divergencias de forma continua."},{"nivel":5,"ancla":"5 Reconciliación autónoma dentro de políticas entre sistemas, con corrección en origen y escalamiento por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Sincronización unidireccional hacia sistemas corporativos","tipo":"S4DS","categoria":"Integración / propagación de dato maestro del CRM transaccional","coberturaS4DS":"sincronización unidireccional DMS→ERP/CRM · validación de consistencia post-sincronización · MCP integration tools","nota":"Propaga el registro maestro hacia contabilidad, cliente y comisiones sin permitir que ningún sistema consumidor lo reescriba."},{"nombre":"ERP corporativo","tipo":"tercero","categoria":"Sistema financiero de registro","ejemplos":["SAP","Oracle NetSuite","Microsoft Dynamics 365"],"nota":"Consumidor de la fuente única para contabilidad; el riesgo a evitar es que se convierta en una segunda verdad del vendedor."},{"nombre":"CRM de marketing / atribución","tipo":"tercero","categoria":"CRM de marketing corporativo","ejemplos":["Salesforce","HubSpot","Microsoft Dynamics 365 CE"],"nota":"Consumidor de la fuente única para la atribución comercial del lead al sponsor; debe leer del DMS, no mantener su propia genealogía."},{"nombre":"Plataforma de integración (iPaaS/ETL)","tipo":"tercero","categoria":"Integration Platform as a Service / ETL","ejemplos":["MuleSoft","Boomi","Workato","Informatica"],"nota":"Ejecuta la metodología Discovery→Extract→Transform→Validate→Parallel-run→Go-live de una migración de genealogía con capacidad de rollback."}],"agentesYUseCase":[{"useCase":"Reconciliador continuo entre sistemas: compara el dato del vendedor entre el registro maestro y cada sistema corporativo consumidor (contabilidad, cliente, comisiones) y señala cualquier divergencia detectada tras la sincronización.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — detecta y reporta; el humano corrige el origen de la divergencia","valor":"sustituye la reconciliación manual periódica por vigilancia continua, cerrando el gap antes del cierre contable"},{"useCase":"Copiloto de validación de migración: durante una corrida en paralelo Discovery→Extract→Transform →Validate, compara el sistema legacy contra el nuevo registro maestro y resume las discrepancias que deben resolverse antes del go-live.","tipo":"S4DS","nivelAutonomia":"copiloto (nivel 2) — compara y resume; el humano decide si avanzar o hacer rollback","valor":"reduce el riesgo de una migración de genealogía de alto impacto en comisiones al hacer visibles las discrepancias antes de apagar el origen"},{"useCase":"Agente de anticipación de divergencia: vigila la consistencia del dato maestro a través de todos los sistemas corporativos de forma continua y anticipa una divergencia antes de que impacte un cierre contable o una liquidación de comisión.","tipo":"S4DS","nivelAutonomia":"agente supervisado → multi-agente (nivel 3-4)","valor":"convierte la fuente única de una promesa de arquitectura en una garantía verificada de forma continua"}],"metadata":{"evidenciaEsperada":"Diagrama de integración que muestre el registro maestro como fuente única sincronizando unidireccionalmente hacia los sistemas corporativos de contabilidad, cliente y comisiones, con evidencia de medición de la consistencia del dato y de eliminación de reconciliaciones manuales entre bases.","dolorAsociado":"El registro de vendedores, la contabilidad y la atribución comercial en sistemas separados sin fuente única divergen: reporting blackouts por lote, bases duales reconciliadas a mano y una migración de genealogía de alto riesgo por su enlace directo a comisiones; la fragmentación de la fuente de verdad es la falla estructural más citada del sector.","frenteRecomendacion":"Tecnología e Integración","fuente":"MASTER-C01 §5 (Integración ERP/CRM: el riesgo típico es la fragmentación de fuente de verdad; estándar recomendado de DMS como sistema de registro de la relación vendedor-compañía que sincroniza unidireccionalmente hacia ERP y CRM, nunca al revés; migración con metodología Discovery→Extract→Transform→Validate→Parallel-run→Go-live con rollback), §8.6 (deuda técnica de fuente de datos fragmentada: reporting blackouts por batch, bases duales reconciliadas manualmente, migración de genealogía de alto riesgo), §10 (largo plazo: retiro de la reconciliación manual entre bases duales)"},"camposFaltantes":[]},{"practiceId":"C01-10-PR-07","processId":"C01","temaId":"c01-datos-fuente-unica-y-gobierno","nombre":"Arquitectura escalable y multi-país del dato del vendedor (moneda, idioma, impuesto, privacidad y altas masivas)","pregunta":"¿La arquitectura del dato del vendedor soporta de forma nativa la operación multi-país (multi-moneda, idioma, reglas fiscales y privacidad/residencia de datos) y absorbe los picos de altas masivas sin degradarse, con identidad, comercio y comisión escalables de forma independiente?","enunciado":"La organización sostiene el dato del vendedor sobre una arquitectura escalable y preparada para operar en varios países, que gestiona de forma nativa la multi-moneda, el multi-idioma, las reglas fiscales por jurisdicción y los requisitos de privacidad y residencia de datos, y que absorbe los picos de altas masivas (lanzamientos, promociones y convenciones) sin degradarse. La capacidad de crecer a nuevos países y de resistir picos de demanda es una propiedad diseña
1da del dato y de la plataforma —con los componentes de identidad, comercio y comisión capaces de escalar de forma independiente— y no un parche que se improvisa cuando la operación se expande.","rubricas":{"proceso":{"anclas":[{"nivel":0,"ancla":"0 El dato del vendedor se diseñó para un solo país y un solo escenario; cada nueva jurisdicción o pico de altas se resuelve con parches improvisados."},{"nivel":1,"ancla":"1 La expansión multi-país y los picos se manejan caso por caso, sin un diseño que contemple moneda, idioma, impuesto o privacidad por jurisdicción."},{"nivel":2,"ancla":"2 Se soportan algunas jurisdicciones, pero con reglas fiscales o de privacidad parcialmente cableadas y sin plan claro para picos de demanda."},{"nivel":3,"ancla":"3 Arquitectura definida como multi-país: multi-moneda, idioma, reglas fiscales y privacidad/residencia por jurisdicción, con capacidad prevista para altas masivas."},{"nivel":4,"ancla":"4 Escalabilidad gestionada; se mide la disponibilidad en picos y el cumplimiento por jurisdicción, y se ajusta la capacidad contra objetivos."},{"nivel":5,"ancla":"5 Arquitectura optimizada; incorporar un nuevo país o absorber un pico es una operación configurable y probada, con disponibilidad sostenida y sin degradación."}]},"sistemas":{"referenciaMp":"§8.6 (genealogías globales multi-moneda/multi-jurisdicción que ahogan sistemas legacy), §8.7 (escalabilidad de altas masivas; exigir ≥99.99% de disponibilidad en picos y arquitectura desacoplada: comisión/comercio/identidad escalables independientemente), §10 (arquitectura desacoplada con ≥99.99% de disponibilidad en picos)","anclas":[{"nivel":0,"ancla":"0 Sin herramienta preparada; el sistema soporta una moneda/idioma y colapsa o se satura ante un pico de altas."},{"nivel":1,"ancla":"1 Multi-país resuelto con instancias o planillas separadas por país, sin un modelo común de dato del vendedor."},{"nivel":2,"ancla":"2 Sistema especializado con soporte parcial de moneda/idioma/impuesto, sobre una base transaccional que comparte checkout y comisión y sufre en picos."},{"nivel":3,"ancla":"3 Plataforma multi-país que gestiona moneda, idioma, reglas fiscales y privacidad por jurisdicción sobre un mismo modelo de dato del vendedor."},{"nivel":4,"ancla":"4 Plataforma con arquitectura desacoplada (identidad, comercio y comisión escalables por separado) que sostiene la disponibilidad objetivo en picos de altas."},{"nivel":5,"ancla":"5 Ecosistema elástico donde nuevos países y picos de demanda se absorben por configuración y escalado automático, sin reingeniería ni degradación."}]},"agentico":{"referenciaMp":"§6 (monitoreo/anticipación de carga y anomalías); §8.7 (evidencia de disponibilidad en picos)","anclas":[{"nivel":0,"ancla":"0 Sin IA; anticipar la carga de un lanzamiento o detectar un cuello de botella de escala es manual y reactivo."},{"nivel":1,"ancla":"1 Alertas por regla fija cuando el uso de recursos supera un umbral."},{"nivel":2,"ancla":"2 Copiloto que reporta el estado de capacidad y disponibilidad a pedido."},{"nivel":3,"ancla":"3 Agente supervisado que proyecta la demanda de un pico de altas y recomienda el escalado o la configuración por jurisdicción."},{"nivel":4,"ancla":"4 Agentes que monitorean carga y cumplimiento multi-país de forma coordinada y anticipan saturaciones antes de que impacten la operación."},{"nivel":5,"ancla":"5 Gestión autónoma de capacidad y cumplimiento por jurisdicción dentro de políticas, con escalado y ajuste sin intervención y escalamiento por excepción."}]}},"tecnologiasSoporte":[{"nombre":"S4DS — Arquitectura multi-país desacoplada del dato del vendedor","tipo":"S4DS","categoria":"Arquitectura escalable / multi-tenant del CRM transaccional","coberturaS4DS":"identidad, comercio y comisión escalables de forma independiente · soporte nativo multi-moneda/idioma/jurisdicción · MCP scalability/capacity tools","nota":"Sostiene el mismo modelo de dato maestro operando en múltiples países sin reingeniería, y absorbe picos de altas sin degradar el resto del sistema."},{"nombre":"Plataforma de gestión de vendedores (DMS) con soporte multi-país nativo","tipo":"tercero","categoria":"Plataforma núcleo con cobertura multi-jurisdicción","ejemplos":["Exigo","DirectScale","ByDesign (Freedom)","Epixel"],"nota":"La cobertura multi-país declarada por el vendor debe verificarse con evidencia de disponibilidad en picos, no asumirse por el marketing."},{"nombre":"Motor de cálculo de impuestos por jurisdicción","tipo":"tercero","categoria":"Tax engine multi-jurisdicción","ejemplos":["Avalara","Vertex","Sovos"],"nota":"Resuelve las reglas fiscales por país/estado sin cablear lógica tributaria dentro del propio DMS."},{"nombre":"Plataforma de nube pública con arquitectura desacoplada","tipo":"tercero","categoria":"Infraestructura cloud / microservicios","ejemplos":["AWS","Microsoft Azure","Google Cloud"],"nota":"Habilita el escalado independiente de identidad, comercio y comisión mediante servicios desacoplados y auto-scaling en picos de demanda."},{"nombre":"Plataforma de gestión de privacidad y residencia de datos","tipo":"tercero","categoria":"Privacy / data residency management","ejemplos":["OneTrust","TrustArc"],"nota":"Gestiona los requisitos de privacidad y residencia de datos que varían por jurisdicción a medida que la operación se expande a nuevos países."}],"agentesYUseCase":[{"useCase":"Proyector de demanda de picos: estima, antes de un lanzamiento o convención, el volumen esperado de altas y recomienda el escalado de capacidad y la configuración por jurisdicción necesaria para sostenerlo.","tipo":"S4DS","nivelAutonomia":"agente supervisado (nivel 3) — proyecta y recomienda; el humano aprueba el escalado","valor":"convierte la preparación de un pico de altas masivas en una decisión anticipada en lugar de una respuesta reactiva a la saturación"},{"useCase":"Monitor de disponibilidad y cumplimiento multi-país: vigila de forma coordinada la disponibilidad de identidad, comercio y comisión por país y anticipa saturaciones antes de que impacten la operación.","tipo":"S4DS","nivelAutonomia":"agente supervisado → multi-agente (nivel 3-4)","valor":"detecta el cuello de botella específico (identidad, comercio o comisión) antes de que arrastre a todo el sistema"},{"useCase":"Copiloto de expansión a nuevo país: consolida los requisitos de moneda, idioma, impuesto y privacidad/residencia de datos de una jurisdicción nueva y valida que la configuración del dato del vendedor los cubre antes del lanzamiento.","tipo":"tercero","nivelAutonomia":"copiloto (nivel 2) — recopila y valida; el humano decide el lanzamiento","ejemplos":["asistentes de compliance regulatorio multi-jurisdicción sobre plataformas de privacidad/tax"],"valor":"reduce el riesgo de lanzar en un país nuevo con una brecha fiscal o de privacidad no detectada"}],"metadata":{"evidenciaEsperada":"Documento de arquitectura del dato del vendedor que evidencie soporte nativo multi-moneda/idioma, reglas fiscales y privacidad/residencia por jurisdicción, desacople de identidad-comercio-comisión, y evidencia de disponibilidad (p. ej. ≥99.99%) sostenida en un pico de altas masivas.","dolorAsociado":"Sistemas legacy diseña
1dos para 'cheques mensuales y envíos domésticos' que ahogan genealogías globales multi-moneda/multi-jurisdicción, y monolitos que comparten base transaccional entre checkout y motor de comisión y colapsan en lanzamientos o convenciones; la expansión y los picos se vuelven riesgo operativo en vez de una capacidad diseñada.","frenteRecomendacion":"Tecnología e Integración","fuente":"MASTER-C01 §8.6 (deuda técnica: sistemas legacy diseñados para cheques mensuales y envíos domésticos luchan con genealogías globales multi-moneda/multi-jurisdicción), §8.7 (escalabilidad de altas masivas análogas a un flash-sale; exigir evidencia de ≥99.99% de disponibilidad en picos y arquitectura desacoplada con comisión/comercio/identidad escalables independientemente), §10 (largo plazo: arquitectura desacoplada con ≥99.99% de disponibilidad en picos de altas masivas)"},"camposFaltantes":[]}]`);export{e as default};

Line numbers count LF bytes from the start of the resource, as the search results do. Vendor segments are library code the classifier recognised; they are stored but not indexed. Bytes are shown as Latin1 characters, one per byte.