OpenClaw Business Observer¶

Fecha: 2026-06-03

Estado: VISION FUNCIONAL

Scope: tenant

Tenant inicial de referencia: alpuntodeventa

Owner propuesto: Gabi / Carlos Canu

Resumen ejecutivo¶

OpenClaw Business Observer es la primera capacidad de negocio real propuesta para la plataforma.

Su objetivo es transformar datos comerciales dispersos en una lectura simple, confiable y accionable del negocio, sin reemplazar al ERP, sin operar como sistema transaccional y sin automatizar decisiones por ahora.

La capacidad apunta a responder una pregunta central:

que esta pasando en el negocio y donde conviene actuar primero

Para APV, esto significa poder observar en un mismo marco vendedores, clientes, stock, marcas, rentabilidad y rotacion para detectar desbalances, oportunidades y alertas tempranas.

Alcance de este documento¶

define vision funcional
define valor esperado
define necesidades de datos
define roadmap por etapas
referencia la capa tenant cuando existan reglas comerciales propias
no implementa runtime
no define arquitectura detallada
no define modelo fisico de base
no define dashboards concretos ni automatizaciones finales

Referencia tenant¶

La bajada especifica del tenant alpuntodeventa vive en:

docs/tenants/alpuntodeventa/business-observer/README.md

Ese espacio documenta reglas y decisiones comerciales propias de APV sin duplicar innecesariamente esta vision Core.

1. Que problema resuelve¶

Hoy la lectura comercial suele quedar fragmentada entre sistemas, planillas, consultas manuales y criterio humano.

Eso dificulta responder con velocidad y consistencia preguntas como:

que vendedores estan empujando crecimiento real y cuales estan perdiendo traccion
que clientes compran menos que antes aunque sigan activos
que marcas venden mucho pero dejan poca rentabilidad
que productos inmovilizan capital por baja rotacion
donde hay quiebres o sobrestock que afectan ventas y caja

OpenClaw Business Observer resuelve ese problema proponiendo una capa de observacion ejecutiva y operativa de negocio sobre datos gobernados.

No busca ejecutar pedidos, facturar ni modificar stock.

Busca observar, comparar, priorizar y explicar.

2. Que datos necesitara¶

La capacidad necesitara, como minimo, datos de seis dominios.

Vendedores¶

identificador de vendedor
nombre
canal o zona
cartera de clientes
ventas por periodo
margen o contribucion atribuible cuando aplique
cantidad de pedidos
ticket promedio

Clientes¶

identificador de cliente
nombre o razon social
segmento
localidad o zona
fecha de ultima compra
frecuencia de compra
facturacion acumulada
margen generado
deuda o condicion comercial si aplica

Stock¶

producto o SKU
stock actual
stock comprometido
stock disponible
costo
precio
dias de cobertura estimados
fecha de ultimo movimiento

Marcas¶

marca
ventas por periodo
unidades vendidas
margen bruto estimado
capital inmovilizado
participacion sobre ventas
participacion sobre utilidad

Rentabilidad¶

ventas netas
costo de mercaderia
margen bruto
descuentos
bonificaciones
gastos comerciales atribuibles si existen
contribucion por cliente, vendedor, marca y producto

Rotacion¶

unidades vendidas por periodo
stock promedio
dias sin movimiento
velocidad de salida
clasificacion de rotacion alta, media o baja

3. Que preguntas podria responder¶

La capacidad deberia poder responder preguntas ejecutivas y operativas como las siguientes.

Sobre vendedores¶

que vendedores de APV crecieron en ventas y cuales crecieron en margen
que vendedor vende mucho pero con baja rentabilidad
que cartera tiene mas clientes dormidos o en caida

Sobre clientes¶

que clientes compraban seguido y dejaron de comprar
cuales son los clientes mas rentables y no solo los que mas facturan
que clientes concentran demasiado riesgo comercial

Sobre stock¶

que productos tienen riesgo de quiebre por alta salida
que productos estan sobrestockeados y frenan caja
que stock inmovilizado existe por marca o categoria

Sobre marcas¶

que marcas sostienen mejor margen
que marcas rotan rapido pero aportan poca contribucion
que marcas inmovilizan capital y deberian revisarse

Sobre rentabilidad¶

donde se gana dinero de verdad: vendedor, cliente, marca o producto
que lineas facturan mucho pero destruyen margen
como cambia la rentabilidad entre periodos comparables

Sobre inteligencia temporal¶

cuantos dias trabajados reales tuvo el periodo analizado
como cambia la lectura si se compara por dias efectivos y no solo por calendario
que proyeccion de cierre surge cuando se consideran dias operativos

Sobre rotacion¶

que productos tienen alta salida y bajo stock disponible
que productos no rotan y hace cuanto estan inmovilizados
donde conviene liquidar, recomprar o renegociar

4. Que fuentes de datos consumiria¶

Siguiendo la Data Foundation, las fuentes deberian declararse por source_system y nunca mezclarse sin trazabilidad.

Fuentes iniciales candidatas para APV:

SGC / ERP fuente principal esperada para clientes, productos, stock, ventas y costos
WooCommerce fuente candidata para pedidos, comportamiento de canal digital y catalogo
archivos importados planillas historicas, listas comerciales o ajustes manuales auditados
OpenClaw contexto operativo, consultas asistidas y futura capa de explicacion
PostgreSQL futuro capa gobernada donde consolidar datos una vez aprobada la implementacion
APIs externas futuras fuentes complementarias de mercado, catalogo o logistica si se aprueban

Regla funcional clave:

Prometheus, Thanos y la observabilidad tecnica no deben ser la fuente de verdad de indicadores de negocio.

5. Que valor aporta al negocio¶

El valor de OpenClaw Business Observer para APV seria concreto.

acorta el tiempo entre dato y decision
ordena una lectura comun entre dueno, administracion y equipo comercial
ayuda a priorizar accion sobre clientes, vendedores, marcas y stock
mejora el uso del capital al hacer visible inmovilizacion y rotacion
ayuda a defender margen, no solo facturacion
reduce dependencia de lectura manual dispersa
prepara la base para dashboards, alertas y agentes futuros

Ejemplos reales esperables para APV:

detectar que un vendedor mantiene facturacion estable pero cae su margen por mezcla de marcas menos rentables
detectar que una marca vende bien pero deja demasiado stock lento
detectar clientes activos con caida sostenida de compra antes de perderlos
detectar productos con alta rotacion y cobertura insuficiente antes del quiebre

6. Core reutilizable y contextos separados¶

OpenClaw Business Observer no debe nacer como una solucion exclusiva para APV.

Debe nacer como una capacidad base reutilizable de la plataforma, con separacion clara entre el core comun y cada contexto de negocio.

Reglas de esta vision:

APV es el primer caso de uso documentado y priorizado
La Directa podra tener en el futuro su propio observer separado
otros negocios o tenants podran usar el mismo patron
la logica comun debe vivir como capacidad base reutilizable
los datos, reglas, fuentes y permisos deben separarse por contexto
nunca se deben mezclar datos de APV y La Directa

Esto significa que el observer debe pensarse como:

un core comun para observar, comparar, priorizar y explicar
un contexto por tenant o negocio para definir que datos usa, que preguntas puede hacer y que reglas comerciales aplican

Cada contexto futuro debe declarar como minimo:

owner
fuentes de datos
permisos
preguntas habilitadas
reglas comerciales
evidencia de origen de datos

Ejemplos simples por contexto:

APV pregunta: que clientes dejaron de comprar
La Directa pregunta: que clientes del ecommerce dejaron de comprar snacks o cafe
futuro cliente SaaS pregunta: que clientes requieren atencion comercial

La pregunta cambia segun el negocio, pero el patron base es el mismo:

observar datos confiables
detectar desvio o riesgo
explicar por que aparece la alerta
priorizar donde conviene actuar primero

La separacion por contexto debe respetar la Multi-Tenant Foundation y la Data Foundation.

Eso implica:

mismo patron reutilizable
aislamiento estricto por tenant_id o contexto aprobado
trazabilidad de source_system
permisos propios por negocio
evidencia clara del origen de cada lectura

Mini-roadmap de evolucion:

Etapa 1 - APV Business Observer documental¶

cerrar la vision documental para APV
dejar explicito que el core debe ser reutilizable

Etapa 2 - Primer caso de uso APV¶

priorizar clientes que dejaron de comprar

Etapa 3 - Separacion formal por contexto o tenant¶

formalizar owner, fuentes, permisos, preguntas y reglas por contexto

Etapa 4 - La Directa Business Observer¶

abrir un observer propio para La Directa sin mezclar datos con APV

Etapa 5 - Reusable Business Observer para futuros clientes¶

consolidar el patron para futuros tenants o negocios

7. Riesgos¶

mala calidad de datos de origen
diferencias entre stock teorico y stock real
costos incompletos o atrasados que distorsionen rentabilidad
exceso de confianza en indicadores sin contexto comercial
mezclar datos de distintos cortes temporales
dependencia de carga manual no auditada
confusion entre vision ejecutiva y fuente transaccional oficial
riesgo futuro de acceso cruzado entre tenants si no se respeta tenant_id

8. Limites¶

Esta capacidad no deberia prometer, en su primera version documental:

prediccion avanzada
optimizacion automatica de compras
cierre contable
reemplazo del ERP
explicaciones causales perfectas
accion automatica sobre stock, precios o clientes
cobertura multi-tenant operativa antes de que exista runtime gobernado

Su foco inicial debe ser observacion confiable, comparacion simple y priorizacion comercial.

9. Roadmap por etapas¶

Etapa 1 - Marco funcional y definiciones¶

cerrar definiciones de negocio
acordar metricas minimas
acordar glosario comun para ventas, margen, stock y rotacion
definir owner y criterio de prioridad para APV
dejar explicito que el observer nace como core reutilizable y no como solucion cerrada para un solo negocio

Salida esperada:

vision aprobada
preguntas priorizadas
metricas base definidas

Etapa 2 - Catalogo de datos de negocio¶

mapear fuentes reales por dominio
identificar campos minimos obligatorios
clasificar calidad, frecuencia y owner de cada fuente
explicitar que dato es oficial y cual es derivado
separar fuentes y ownership por contexto

Salida esperada:

inventario de datos para vendedores, clientes, stock, marcas, rentabilidad y rotacion

Etapa 3 - Modelo de observacion de negocio¶

definir indicadores minimos por dominio
definir comparaciones entre periodos
contemplar comparaciones temporales por dias efectivos cuando aplique
definir semaforos o alertas interpretables
definir ejemplos reales de lectura para APV
definir preguntas habilitadas y reglas comerciales por contexto

Salida esperada:

contrato funcional de indicadores
primeras vistas objetivo de negocio

Etapa 4 - Integracion gobernada con Data Foundation¶

alinear el observer con tenant_id, scope, ownership y source_system
preparar la futura persistencia sobre la Data Foundation
asegurar trazabilidad entre origen, indicador y consumidor
asegurar separacion estricta entre contextos como APV y La Directa

Salida esperada:

capacidad lista para abrir implementacion cuando se apruebe runtime

Etapa 5 - Dashboards y alertas de negocio¶

construir dashboards de negocio por tenant
separar lectura ejecutiva de lectura operativa
abrir alertas de negocio solo sobre datos confiables

Salida esperada:

primera observacion visual accionable para APV

Etapa 6 - Explicacion asistida y agentes futuros¶

habilitar explicaciones guiadas por OpenClaw
sugerir focos de accion, no decisiones automaticas
conectar luego con agentes comerciales, de stock o financieros
reutilizar el mismo patron base en multiples negocios o tenants

Salida esperada:

observer explicativo y asistido, siempre sobre datos gobernados

Ejemplos APV de uso futuro¶

Ejemplo 1 - Vendedores¶

APV podria observar que dos vendedores facturan parecido, pero uno sostiene mejor margen y mejor recuperacion de clientes dormidos.

Ejemplo 2 - Clientes¶

APV podria detectar clientes historicos con caida de frecuencia antes de que se conviertan en perdida comercial.

Ejemplo 3 - Stock¶

APV podria separar productos con riesgo de quiebre de productos con stock inmovilizado hace meses.

Ejemplo 4 - Marcas¶

APV podria identificar una marca con buena salida pero baja contribucion y otra con menor volumen pero mejor rentabilidad.

Ejemplo 5 - Rentabilidad¶

APV podria dejar de mirar solo facturacion y empezar a leer que cliente, vendedor o marca genera margen real.

Ejemplo 6 - Rotacion¶

APV podria priorizar recompra en productos de alta salida y revisar liquidacion o renegociacion en productos de baja rotacion.

Decision recomendada¶

OpenClaw Business Observer deberia ser la primera capacidad real de negocio de la plataforma porque conecta directamente la foundation multi-tenant y de datos con una necesidad concreta de APV: entender mejor el negocio antes de automatizarlo.

La recomendacion es abrir primero observacion de negocio, luego dashboards y solo despues alertas o agentes.

La recomendacion adicional es que esa primera capacidad nazca como core reutilizable con contextos separados, para que APV sea el primer caso de uso sin bloquear futuros observers propios para La Directa u otros tenants.