Saltar a contenido

Customer Ownership Analytics

Fecha: 2026-06-09

Estado: DISENO CONCEPTUAL FUTURO / VALIDACION REAL EXPLORATORIA 2026-06-09

Scope: tenant

tenant_id: alpuntodeventa

Owner: Gabi / Carlos Canu

Fuente de verdad: docs/tenants/alpuntodeventa/business-observer/analytics/CUSTOMER-OWNERSHIP-ANALYTICS.md

Documentos relacionados:

  • docs/tenants/alpuntodeventa/business-observer/analytics/SELLER-RECONCILIATION-RULES.md
  • docs/tenants/alpuntodeventa/business-observer/analytics/SELLER-COMMERCIAL-TERRITORY-VIEW.md
  • docs/tenants/alpuntodeventa/business-observer/BUSINESS-OBSERVER-DATA-CONTRACT-001.md
  • docs/tenants/alpuntodeventa/business-observer/sources/SOURCE-003-CHANNEL-TAXONOMY.md
  • docs/tenants/alpuntodeventa/business-observer/sources/SOURCE-001-SGC-CLIENTES.md
  • docs/tenants/alpuntodeventa/business-observer/sources/SOURCE-002-SGC-PRODUCTOS.md
  • docs/tenants/alpuntodeventa/business-observer/sources/SOURCE-003-SGC-VENTAS-COMPROBANTES.md
  • docs/governance/standards/DATA-DESIGN-STANDARD.md

1. Objetivo

Definir conceptualmente como identificar quien trabaja realmente cada cliente en APV, combinando:

  • ownership comercial formal desde SOURCE-001
  • actividad transaccional real desde SOURCE-003
  • enriquecimiento de mix y desarrollo comercial desde SOURCE-002

Este documento existe antes de disenar SQL, vistas fisicas, materialized views, automatizaciones, ML o IA.

Objetivos de negocio de esta capa:

  • identificar quien trabaja realmente cada cliente
  • detectar cuentas abandonadas
  • detectar cuentas desarrolladas por terceros
  • detectar recuperacion de clientes
  • detectar crecimiento de cuentas
  • alimentar KPIs de vendedores
  • alimentar alertas, automatizaciones, ML e IA

Preguntas rectoras de esta capa:

  • quien trabaja realmente cada cliente
  • quien fue el ultimo vendedor que le vendio
  • si el vendedor asignado sigue trabajando la cuenta
  • si otro vendedor esta desarrollando la cuenta
  • si la cuenta fue abandonada por el vendedor asignado
  • quien recupero la cuenta
  • que vendedor esta haciendo crecer la cuenta

2. Regla madre

En APV deben convivir dos lecturas sin mezclarse:

  • SOURCE-001 define ownership_assigned
  • SOURCE-003 define la autoria real de cada venta

Reglas obligatorias:

  • la venta se computa siempre al vendedor que la hizo realmente
  • la cartera asignada no debe sobrescribir la autoria real de la venta
  • la autoria real de la venta no debe borrar la cartera asignada
  • la diferencia entre assigned y transactional debe preservarse como senal analitica
  • ownership_effective no reemplaza automaticamente ownership_assigned

3. Relacion con fuentes

3.1 SOURCE-001 Clientes

Gobierna:

  • cliente
  • vendedor asignado
  • estado cliente
  • localidad y provincia
  • zona logistica
  • frecuencia

Lectura correcta:

  • define la responsabilidad comercial esperada
  • representa la cartera formal del cliente
  • aporta el punto de partida para medir abandono, riesgo y recuperacion

3.2 SOURCE-003 Ventas / Comprobantes

Gobierna:

  • fecha de venta
  • vendedor transaccional
  • cliente
  • importe
  • unidades
  • SKU
  • comprobante

Lectura correcta:

  • define quien realizo realmente cada venta
  • gobierna la atribucion real de facturacion
  • permite medir recencia, concentracion y reactivacion de la cuenta
  • la base sincronizada futura recomendada para esta lectura es source_003_sales_items derivada de SOURCE-003 / Tabla 2

3.3 SOURCE-002 Productos

Gobierna:

  • SKU
  • marca
  • proveedor
  • categoria
  • atributos de producto

Lectura correcta:

  • no define vendedor
  • enriquece crecimiento y desarrollo comercial
  • permite analizar expansion de surtido, marcas, proveedores y frecuencia

4. Mapa conceptual minimo

Lectura conceptual obligatoria por cliente:

  • ownership_assigned: cartera formal y responsabilidad esperada desde SOURCE-001
  • ownership_last_sale: ultimo vendedor real observado en SOURCE-003
  • ownership_effective: concentracion reciente de actividad comercial real dentro de una ventana futura validada
  • ownership_recovery: vendedor que reactiva la cuenta luego de una inactividad relevante
  • ownership_growth: vendedor que expande importe, recurrencia, mix, marcas, proveedores o SKU
  • ownership_risk: senal de deterioro del ownership asignado
  • ownership_abandonment: senal de no trabajo reciente del vendedor asignado

5. Conceptos principales

5.1 ownership_assigned

Vendedor formalmente asignado al cliente desde SOURCE-001.

Representa:

  • responsabilidad esperada
  • cartera formal
  • ownership comercial teorico

5.2 ownership_last_sale

Vendedor que hizo la ultima venta real observada en SOURCE-003.

Lectura correcta:

  • no necesariamente coincide con ownership_assigned
  • no redefine por si solo la cartera formal

5.3 ownership_effective

Vendedor que concentra la actividad comercial reciente del cliente.

Lectura correcta:

  • debe derivarse de ventas reales dentro de una ventana temporal futura
  • debe apoyarse en umbrales de concentracion, recencia o recurrencia validados
  • no debe reemplazar automaticamente ownership_assigned

5.4 ownership_recovery

Vendedor que reactiva una cuenta luego de una inactividad relevante.

Lectura correcta:

  • debe definirse con ventana temporal futura
  • debe distinguir recuperacion del vendedor asignado versus recuperacion por otro vendedor

5.5 ownership_growth

Vendedor que hace crecer la cuenta.

Lectura correcta:

  • debe considerar ventas, SKU, marcas, proveedores o frecuencia
  • debe cruzar SOURCE-003 y SOURCE-002
  • no debe limitarse a importe vendido

5.6 ownership_risk

Senal de riesgo cuando una cuenta asignada es trabajada principalmente por terceros o no tiene actividad reciente del vendedor asignado.

5.7 ownership_abandonment

Senal de abandono cuando el vendedor asignado no registra actividad reciente sobre el cliente, aunque otro vendedor si pueda estar vendiendo.

6. Estados analiticos sugeridos

Estados conceptuales futuros:

  • assigned_and_worked
  • assigned_but_inactive
  • worked_by_other_seller
  • shared_ownership
  • effectively_owned_by_other_seller
  • recovered_by_assigned_seller
  • recovered_by_other_seller
  • growing_under_assigned_seller
  • growing_under_other_seller
  • abandoned_by_assigned_seller
  • no_recent_activity
  • manual_review

Lectura prudente:

  • estos estados son derivados
  • no deben cargarse como verdad primaria
  • sus ventanas y umbrales quedan pendientes

7. Preguntas de negocio que debe responder

  • quien trabaja realmente este cliente
  • quien fue el ultimo vendedor que le vendio
  • el vendedor asignado sigue trabajando la cuenta
  • otro vendedor esta desarrollando la cuenta
  • la cuenta fue abandonada por el vendedor asignado
  • quien recupero la cuenta
  • que vendedor esta haciendo crecer la cuenta
  • que marcas o SKU esta colocando el vendedor real
  • cuantas cuentas asignadas no tienen actividad reciente
  • cuantas cuentas de baja podrian recuperarse
  • cuantos clientes necesita captar o recuperar un vendedor para recomponer masa comercial

8. Metricas futuras por cliente

Metricas conceptuales futuras:

  • vendedor_asignado
  • vendedor_ultima_venta
  • vendedor_efectivo
  • fecha_ultima_venta_general
  • fecha_ultima_venta_vendedor_asignado
  • fecha_ultima_venta_otro_vendedor
  • dias_sin_venta_general
  • dias_sin_venta_asignado
  • cantidad_vendedores_recientes
  • porcentaje_ventas_vendedor_asignado
  • porcentaje_ventas_otros_vendedores
  • cantidad_skus_recientes
  • marcas_recientes
  • proveedores_recientes
  • estado_ownership

Lectura adicional recomendada:

  • vendedor_ultima_venta y vendedor_efectivo no deben confundirse
  • fecha_ultima_venta_vendedor_asignado debe compararse contra fecha_ultima_venta_general
  • porcentaje_ventas_vendedor_asignado y porcentaje_ventas_otros_vendedores deben leerse como senales de concentracion y posible drift comercial

9. Metricas futuras por vendedor

Metricas conceptuales futuras:

  • clientes_asignados
  • clientes_trabajados
  • clientes_asignados_sin_actividad
  • clientes_trabajados_por_terceros
  • clientes_recuperados
  • clientes_desarrollados_fuera_de_cartera
  • ventas_en_cartera_propia
  • ventas_fuera_de_cartera
  • cuentas_compartidas
  • cuentas_abandonadas
  • oportunidades_de_recuperacion

10. Lectura analitica recomendada

Secuencia conceptual futura:

  1. partir de ownership_assigned desde SOURCE-001
  2. medir la ultima venta real con ownership_last_sale desde SOURCE-003
  3. medir la actividad reciente del vendedor asignado versus terceros
  4. derivar ownership_effective dentro de una ventana temporal validada
  5. derivar senales de ownership_recovery, ownership_growth, ownership_risk y ownership_abandonment
  6. usar SOURCE-002 para explicar que mix, marcas, proveedores o categorias sostienen el desarrollo real

Regla obligatoria:

  • ninguna de estas lecturas debe alterar la autoria transaccional de la venta

11. Relacion con otras capas analiticas

11.1 Relacion con reconciliacion de vendedor

CUSTOMER-OWNERSHIP-ANALYTICS se apoya en SELLER-RECONCILIATION-RULES.md.

Lectura:

  • seller_assigned es la base de ownership_assigned
  • seller_transactional es la base de ultima venta, actividad reciente, recuperacion y crecimiento real

11.2 Relacion con territorio comercial

CUSTOMER-OWNERSHIP-ANALYTICS ayuda a responder territorio comercial real del vendedor, pero no lo reemplaza.

Lectura:

  • ownership responde quien trabaja la cuenta
  • territorio responde donde esta distribuida esa actividad

12. Validacion real exploratoria 2026-06-09

Validacion ejecutada en modo de solo lectura, usando como base la misma ventana exploratoria de SELLER-RECONCILIATION-RULES.md:

  • ventana principal: 2026-03-11 a 2026-06-09 (90 dias)
  • cortes complementarios: 30 / 60 / 90 dias
  • ventas exploratorias: v.Estado <> 'ANULADO' y TipoComp IN ('FACTURA A','GUIA DE DESPACHO','FACTURA B')

Resultado agregado observado para ownership de ultima venta:

Medida Resultado observado
clientes con ultima venta del vendedor asignado 1851
clientes con ultima venta de otro vendedor 47
clientes con ultima venta ambigua en la misma fecha 0

Resultado agregado observado para clientes activos asignados sin venta reciente del vendedor asignado:

Ventana Clientes activos con ventas en 90d Sin venta reciente del asignado Con venta reciente de otro vendedor Sin venta reciente en absoluto
30 dias 1898 421 29 392
60 dias 1898 198 29 169
90 dias 1898 28 28 0

Lectura prudente respaldada:

  • ownership_last_sale ya es medible con datos reales y no quedo bloqueado por falta de join entre cliente y vendedor
  • la mayor parte de los clientes con actividad en 90 dias tuvo ultima venta del vendedor asignado, pero existe un conjunto real y no nulo trabajado por otro vendedor
  • la senal worked_by_other_seller tambien es medible sin cerrar todavia umbrales de abandono o ownership_effective
  • en esta ventana no aparecieron casos de manual_review por cliente no mapeado, vendedor faltante o ultima venta ambigua
  • la taxonomia parcial de canal ya permite distinguir unassigned de traditional_seller en una parte importante del volumen, pero no alcanza todavia para cerrar shared_channel o ecommerce como contexto estable
  • no corresponde cerrar todavia la ventana oficial de ownership_effective: los cortes 30 / 60 / 90 dias se dejan solo como medicion exploratoria

Veredicto exploratorio recomendado:

  • estado general de medibilidad: AMARILLO
  • motivo: ownership formal vs ultima venta real ya es medible, pero la lectura de canal compartido y la ventana oficial de trabajo efectivo siguen abiertas

13. Restricciones obligatorias

  • no usar WhatsApp como identificador
  • no excluir clientes de baja
  • no usar zona logistica como vendedor
  • no atribuir ventas al vendedor asignado si otro vendio
  • no reemplazar automaticamente seller_assigned por seller_effective
  • no cerrar ownership_effective sin ventana temporal y umbrales validados
  • no crear SQL todavia
  • no crear tablas todavia
  • no crear vistas fisicas todavia
  • no crear materialized views todavia
  • no tocar runtime

14. Pendientes preservados

Quedan explicitamente pendientes:

  • definir ventana temporal para ownership_effective
  • definir umbrales de abandono
  • definir umbrales de recuperacion
  • definir umbrales de crecimiento
  • disenar SQL real
  • disenar vista o materialized view
  • evaluar performance
  • definir permisos de consumo
  • contemplar ecommerce o canales compartidos a partir del cierre parcial ya documentado en SOURCE-003-CHANNEL-TAXONOMY.md
  • ampliar la validacion real a historico mas largo o cortes estacionales si la lectura comercial futura lo requiere

15. Confirmaciones de alcance

  • sin runtime
  • sin queries
  • sin tablas
  • sin vistas fisicas
  • sin migraciones
  • solo documentacion