Manual Operativo
Completo

2.1 Regla de Oro

2.2 Cultura SDR — Los 5 Principios

Estos cinco principios definen como opera un SDR de Sellerfy. No son sugerencias — son compromisos no negociables que separan a un vendedor comun de un profesional que construye relaciones y cierra deals de forma consistente.

2.3 Rutina Diaria (Kick-off)

Cada manana, antes de hacer cualquier otra cosa, el SDR ejecuta estos tres pasos en orden. Esta rutina no debe tomar mas de 20 minutos y establece el enfoque del dia completo.

2.4 El Funnel de Ventas

A. Captacion y Filtros (Inbound)

No todos los leads son iguales. El proceso de calificacion determina cuanto tiempo y energia dedicar a cada prospecto. Un seller con $50k USD mensuales en Amazon merece un approach completamente distinto a uno que esta comenzando con 5 SKUs en Mercado Libre. La tabla siguiente define los criterios de filtro y sus valores posibles:

Prioridad de atencion: Los leads con facturacion >$5k USD y experiencia >1 ano son el sweet spot de Sellerfy. Tienen suficiente volumen para que la herramienta genere un ROI inmediato y suficiente experiencia para entender el valor de los datos. Leads con <$5k se atienden pero se orientan al plan mas basico y al flujo self-service.

B. Preparacion de la Demo

C. La Reunion — Showroom de Impacto

La demo no es una presentacion de slides. Es un showroom en vivo donde el seller ve, con datos reales, el impacto de Sellerfy en su operacion. Hay tres momentos clave que deben ejecutarse en orden:

D. Cierre y Onboarding

2.5 Como Crear Deseo — La Estrategia de Valor

Vender Sellerfy no es empujar un producto — es hacer que el seller visualice un futuro donde tiene control total de su rentabilidad. Estas cinco tecnicas, aplicadas en secuencia, transforman una conversacion fria en una decision de compra natural.

2.6 Gestion de WhatsApp — Reglas y Limites

WhatsApp es el canal mas poderoso para comunicarse con sellers en LATAM, pero viene con restricciones estrictas de Meta que debemos respetar para evitar suspensiones.

2.7 Manual Tecnico HubSpot para SDRs

HubSpot es la columna vertebral del proceso comercial. Cada accion del SDR debe quedar reflejada aqui. Un CRM bien mantenido es la diferencia entre un equipo que escala y uno que se estanca.

2.8 Personas Clave del Equipo Comercial

2.9 KPIs del Equipo Comercial

Cada SDR debe rastrear estas metricas de forma consistente. Los KPIs se dividen en tres cadencias: diarios (actividad operativa), semanales (eficiencia del pipeline) y mensuales (resultados de negocio). Sin metricas no hay visibilidad, sin visibilidad no hay mejora.

KPIs Diarios (Actividad Operativa)

Estos se miden cada dia como parte de la rutina de kick-off y cierre de jornada. Son indicadores de esfuerzo y disciplina — si no se cumplen, el pipeline se seca en 1-2 semanas.

KPIs Semanales (Eficiencia del Pipeline)

Se revisan cada lunes en la reunion de equipo. Son indicadores de eficiencia y conversion — muestran si el esfuerzo diario se esta traduciendo en resultados. Las metas se definen internamente por el equipo segun la etapa del negocio.

KPIs Mensuales (Resultados de Negocio)

Indicadores de impacto en el negocio. Se revisan en el cierre de cada mes y definen la estrategia del mes siguiente. Las metas numéricas las define el equipo de liderazgo.

2.10 Playbook de Prospeccion Outbound

Si el calendario no tiene demos, salimos a cazar. El outbound no es un plan de emergencia — es una disciplina diaria. Esta seccion detalla los canales, tacticas y cadencias que el SDR debe seguir para generar oportunidades de forma proactiva.

Canales de Prospeccion

Re-engagement de Leads Frios

Los leads que no convirtieron no estan muertos. Antes de buscar leads nuevos, revisa el pipeline de leads inactivos:

3.1 ¿Que son las Battlecards?

Las Battlecards son respuestas pre-disenadas y probadas para las objeciones mas comunes que enfrenta un SDR en cada etapa del proceso de venta. No son scripts rigidos — son marcos de respuesta que capturan la estructura y el mensaje central que funciona, permitiendo al SDR adaptarlos al contexto de cada conversacion.

3.2 Objeciones en Prospeccion

Estas son las objeciones que surgen cuando el SDR esta intentando abrir la conversacion por primera vez — ya sea por WhatsApp, llamada o redes sociales. El objetivo aqui no es cerrar; es mantener la conversacion viva y avanzar hacia la demo.

3.3 Objeciones en Demo

Estas objeciones surgen durante o inmediatamente despues de la demo. El prospecto ya vio el producto — ahora esta evaluando si lo vale. Las respuestas deben ser concretas, basadas en datos, y respaldadas por lo que acaba de ver.

3.4 Objeciones de Soporte

Estas objeciones vienen de clientes activos que enfrentan fricciones. Son oportunidades para fortalecer la relacion y, en algunos casos, para hacer upsell a un plan superior. La clave: resolver primero, vender despues.

3.5 Principios de Manejo de Objeciones

Mas alla de las respuestas especificas, estos principios guian toda interaccion con objeciones. Son la brujula etica y estrategica del equipo comercial.

4.1 Vision General

El bot no es un chatbot de respuestas predefinidas. Es un agente conversacional con IA que entiende contexto, adapta su tono, recuerda el historial completo de cada contacto, y toma decisiones autonomas sobre como avanzar la conversacion basandose en una maquina de estados de 7 fases.

4.1.1 Acceso a Chatwoot

Panel de conversaciones en tiempo real. Todos los mensajes de WhatsApp del bot aparecen aqui. Los SDRs deben monitorear la bandeja para intervenir cuando el bot escala una conversacion.

URL: sellerfychat.pabesfu.com

Todos los agentes estan asignados al inbox WhatsApp Sellerfy y veran todas las conversaciones entrantes.

4.1.2 Volumen de Outreach y Protecciones

1. Leads Nuevos (poll-leads)

Solo busca contactos creados en los ultimos 60 minutos. Maximo 20 por batch. Esto significa que solo contacta leads que se registran en tiempo real (formularios, imports manuales). Los 18,000 existentes no se tocan.

2. Backlog (backlog-outreach) — NUEVO

Para los leads existentes, el endpoint /backlog-outreach contacta 20 leads por hora, empezando por los mas antiguos. Con horario 10am-4pm CDMX (6 horas) = maximo 120 leads por dia. A ese ritmo, los 18,000 se contactan en ~150 dias, de forma gradual y sostenible. Cron activo desde Mar 16 2026.

3. Follow-ups Automaticos — NUEVO (Mar 16)

El endpoint /follow-ups se ejecuta 3 veces al dia (10am, 2pm, 6pm CDMX). Busca conversaciones stale (48h sin respuesta, con al menos 1 mensaje) y envia templates de follow-up via Twilio. Maximo 2 intentos por lead. Despues de 14 dias inactivo + 2 follow-ups sin respuesta, marca al lead como LOST.

4. Reporte Diario de Engagement — NUEVO (Mar 16)

Endpoint /daily-report genera metricas comparativas hoy vs ayer. Se ejecuta automaticamente a las 9pm CDMX via cron. Metricas clave:

• Response rate: % de outreach que genera al menos 1 respuesta
• Engagement rate: % de respondidos con 2+ mensajes (conversacion real)
• Reached INFORMING: convs que avanzaron del funnel de discovery
• Booked: demos agendadas
• Follow-ups enviados: nudges a leads stale
• Delta vs ayer: comparacion porcentual dia a dia

Log en /var/log/sellerfy-daily-report.log. Cron: /opt/infra/crons/sellerfy-daily-report.sh

5. Sync de Bookings Externos — NUEVO (Mar 17)

Endpoint /sync-external-bookings. Detecta meetings de Sellerfy agendadas fuera del bot (via HubSpot directo, email, LinkedIn) que no tienen deal, y les crea uno automaticamente. Corre cada 30 min en horario laboral.

6. Deteccion de No-Show — NUEVO (Mar 17)

Endpoint /noshow-followups. Detecta meetings marcadas como NO_SHOW en HubSpot, mueve el deal a etapa No-Show, y envia templates de re-agendamiento (hasta 3 intentos, 24h entre cada uno). Corre 3x/dia.

Ademas, el webhook detecta no-shows en tiempo real cuando un contacto BOOKED escribe al bot y su meeting tiene outcome=NO_SHOW.

4.1.3 Deploy y Operaciones

Deploy rapido (cambios de codigo)

Rebuild (solo si cambia requirements.txt)

Crons activos en produccion

Backups de la base de datos

Backup diario automatico + backup pre-deploy (cada vez que se ejecuta deploy.sh). Ubicacion: /opt/sellerfy-bot/backups/. Retencion: 14 dias.

4.2 Pipeline Tecnico Completo

Cada mensaje entrante pasa por un pipeline de 14 pasos en secuencia. El webhook responde 200 OK inmediatamente y procesa el mensaje en un thread de background (controlado por un semaforo de 10 slots) para no bloquear a Chatwoot.

4.3 Modulos del Sistema

El bot esta compuesto por 12 modulos Python con responsabilidades claramente separadas. Cada modulo es un archivo independiente que se importa en app.py. No hay framework complejo — es Flask puro con modulos funcionales.

4.4 Las 7 Fases Conversacionales

La maquina de estados define el ciclo de vida completo de cada conversacion. Cada fase tiene instrucciones especificas para el modelo, reglas de transicion automatica, y restricciones sobre que puede o no hacer el bot (como compartir el link de demo).

Reglas de transicion detalladas

4.5 Datos que Extrae el Bot

El modulo extractor.py usa Claude Haiku para extraer datos estructurados de cada conversacion. Solo extrae datos explicitos mencionados por el seller — nunca infiere ni inventa. Cada campo se sincroniza automaticamente a HubSpot via la cola de pending_syncs.

Ademas, el estado local trackea: contact_profile (cold_lead/registered/trial_active/trial_expired/customer_active/churn), booking_link_sent, messages_count, follow_up_count, follow_up_at, reminder_sent, meeting_time, noshow_count, noshow_at, last_message_at, origin.

4.6 Personalidad e Identidad del Bot

La personalidad se define en SOUL.md y IDENTITY.md (montados como volumenes Docker desde /opt/sellerfy-bot/). Esto permite iterar sin tocar codigo ni reiniciar el container.

4.7 Flujos de Entrada

4.8 Niveles de Autonomia

Definidos en AUTONOMY.md, los 3 niveles regulan que tan libre es el bot para actuar sin supervision humana. El objetivo: maximizar autonomia en acciones seguras, requerir aprobacion en acciones de alto riesgo.

4.9 Base de Datos SQLite

Base de datos local en conversations.db con WAL mode (Write-Ahead Logging) para soportar lecturas y escrituras concurrentes desde multiples threads del webhook. Timeout de conexion de 15 segundos. 5 tablas con migraciones automaticas para nuevas columnas.

4.10 Validacion Anti-Alucinacion

Cada respuesta generada por Claude Sonnet pasa por un segundo modelo (Haiku) que la verifica contra el Knowledge Base completo. Este es un patron critico de seguridad: el bot nunca promete algo que Sellerfy no ofrece.

4.11 Follow-ups y Re-engagement

El sistema automatizado de follow-ups opera via endpoints cron que se ejecutan periodicamente. El objetivo: no perder leads por inactividad, pero tampoco ser invasivo.

4.12 Escalamiento

El bot tiene limites claros sobre lo que puede responder. Cuando un seller hace una pregunta fuera del Knowledge Base, el bot no inventa — escala.

4.13 Limites Eticos

Definidos en SOUL.md y aplicados tanto en el system prompt como en las reglas de autonomia. Estos limites son inquebrantables.

4.14 Knowledge Base (13 archivos: 5 JSON + 8 Markdown)

El KB es la unica fuente de verdad para datos factuales del bot. Se compone de 5 archivos JSON (datos estructurados) y 8 archivos Markdown (documentacion detallada) en el directorio kb/. El modulo kb.py los cachea con deteccion de mtime — si se modifica un archivo, se recarga automaticamente sin reiniciar el servicio (hot-reload).

Archivos Markdown (8 documentos de referencia)

4.15 Deploy y Operaciones

El bot corre como Docker container (sellerfy-nurture) con codigo montado como volumen. Deploy manual via scp + docker restart. Para instrucciones detalladas de deploy (rapido y rebuild), ver seccion 4.1.3.

4.16 Acceso al Bot: Chatwoot

El bot opera sobre Chatwoot, una plataforma open-source de mensajeria. Todas las conversaciones de WhatsApp pasan por aqui. Es donde el equipo comercial ve las conversaciones, hace handoff, y responde manualmente cuando el bot escala.

Usuarios y roles

4.17 Catalogo Completo de Endpoints

El bot expone 13 endpoints HTTP en el puerto 5200 del droplet (134.199.231.196). Algunos son webhooks (disparan con eventos), otros son cron jobs (se ejecutan periodicamente), y otros son de administracion.

Webhook (evento externo)

Cron Jobs (ejecucion periodica)

Administracion (manual)

4.18 Templates WhatsApp (Twilio)

WhatsApp requiere templates pre-aprobados por Meta para iniciar conversaciones (mensajes proactivos). Los mensajes dentro de una conversacion activa (<24h desde el ultimo mensaje del usuario) se envian libremente. El bot usa 4 tipos de templates via Twilio API.

4.19 Proceso de Outreach

El outreach es el proceso automatico por el cual el bot contacta proactivamente a leads que se registraron en la web (formulario en sellerfy.ai). A diferencia del flujo organico (el seller nos escribe), aqui el bot inicia la conversacion.

Flujo paso a paso

Backlog Outreach (18,000 leads existentes)

Ademas de leads nuevos, el bot contacta gradualmente el backlog de ~18,000 leads en HubSpot que nunca fueron contactados. El endpoint /backlog-outreach procesa 20 leads por hora de 10am-4pm CDMX (~120/dia). A ese ritmo, el backlog se completa en ~150 dias.

Cursor persistente en backlog_cursor.json para no repetir leads entre ejecuciones.

Stripe Sync y Pagos

El script stripe_sync.py sincroniza datos de Stripe a HubSpot diariamente (6am UTC). Actualiza: plan_name, mrr, stripe_subscription_status, stripe_customer_id, y detecta churns automaticamente. Los montos en los deals deben coincidir con el MRR real de Stripe (no con precios de lista).

Metricas del pipeline (Mar 17 2026)

4.20 Identificacion de Perfil del Contacto

Cada vez que un mensaje entra al bot, lo primero que hace el pipeline es clasificar al contacto en 1 de 6 perfiles. Esta clasificacion determina completamente el comportamiento del bot: que dice, que tono usa, si vende o da soporte, y que acciones automaticas ejecuta. La funcion classify_contact() en hubspot.py es la responsable.

Los 6 perfiles y como se determinan

Arbol de decision (orden de evaluacion)

// 1. Stripe tiene prioridad absoluta
if stripe_status == "active"     → customer_active
if stripe_status == "canceled"   → churn
if stripe_status == "past_due"   → customer_active  (at risk)

// 2. Fallback: churn detectado por propiedad o lifecycle
if churn == true OR lifecycle == "1298051956"  → churn
if lifecycle == "customer" + sub_active  → customer_active
if lifecycle == "customer" - sub_active  → churn

// 3. Trial (basado en fecha)
if trial_end_date > now()              → trial_active
if trial_end_date <= now()             → trial_expired

// 4. Registro detectado
if memberstack OR has_preview           → registered

// 5. Default
else                                    → cold_lead

Que hace el bot diferente segun el perfil

Cada perfil activa un system prompt completamente diferente que se inyecta al modelo de IA. El bot no es el mismo agente para un prospecto frio que para un cliente activo:

4.21 Customer Journey Completo: De 0 a 100

Entrada A: Lead organico (WhatsApp directo)

Entrada B: Lead de formulario web

Entrada C: Lead del backlog (18K existentes)

Journey completo paso a paso

4.22 Bot vs Humano: Quien Hace Que

Handoff a humano: 3 triggers

4.23 Templates de WhatsApp: Que se Envia y Cuando

Crons activos en produccion

4.24 Creacion de Deals: Cuando y Como

Via 1: Deal creado por el bot (conversacion activa)

Via 2: Sync de bookings externos (cron cada 30 min)

Propiedades del deal al crearse

Acciones adicionales al crear deal

Pipeline completo de deals (Sales Pipeline)

4.25 Objetos HubSpot por Fase

Mapa completo de como evolucionan los objetos de HubSpot en cada fase de la conversacion. Esto es lo que el SDR debe ver en el CRM en cada etapa.

Asignacion de reps de demo

4.26 Pipeline de Generacion de Leads: Sherlock + Apify

Resultados de la primera ejecucion

Las 3 macro-etapas y 7 fases

Scripts y ejecucion

Todos los scripts estan en ~/sellerfy-leads/. Se ejecutan en orden:

APIs y costos

Como funciona Sherlock (Fase 0 - Base historica)

Sherlock es un agente de OpenClaw especializado en investigacion de leads. Tiene un tool llamado leadgen que recibe un objetivo (ej: "sellers de electronica en Mexico"), genera queries de busqueda, las ejecuta via Brave Search, y enriquece cada seller con Apify + Perplexity + Apollo.

Para el pipeline v1, consolidamos 74 runs historicos de Sherlock (Jan-Mar 2026) en un solo CSV (sherlock_dump_completo.csv): 609 sellers unicos como base inicial.

Como funciona el enriquecimiento (Fases 2-4)

El enriquecimiento es el proceso de encontrar datos de contacto (WhatsApp, email, website) para sellers que solo tienen nombre y URL de marketplace. Usa 3 estrategias en cascada:

Como funciona la carga a HubSpot (Fase 6)

El upload mapea cada campo del CSV a propiedades de HubSpot. Punto critico: el formato de telefono mexicano.

Todos los contactos se crean con origen=Claude Leadgen para filtrarlos en HubSpot. Los contactos sin telefono ni email (calidad C) NO se suben.

Como replicar el pipeline

Documentacion completa (685 lineas): ~/clawd/agents/sellerfy-nurture/kb/claude_leadgen_v1.md. Scripts: ~/sellerfy-leads/. Datos Sherlock: ~/clawd/agents/sherlock/out/runs/ (74 CSVs).

4.27 Import Masivo de Contactos a HubSpot

Resultado del import

Propiedades creadas en este import

Documentacion completa: ~/claude-memory/memory/sellerfy-hubspot-import.md

4.28 Scripts de Integracion y Sync

Ademas del bot principal (app.py), el sistema tiene scripts standalone que sincronizan datos entre Stripe, Google Ads, GA4, Intercom y HubSpot.

Stripe Sync: flujo

Propiedades: plan_name, mrr, stripe_subscription_status, lifecyclestage=customer. Key: STRIPE_SYNC_KEY en .env.local.

UTM Tracking: frontend a HubSpot

Google Ads GCLID: conversion offline

5.0 Setup Inicial (Para SDRs Nuevos)

Estos pasos se realizan una sola vez al incorporarse al equipo. Aseguran que HubSpot este correctamente configurado para registrar toda la actividad comercial desde el primer dia.

5.1 Vision General

HubSpot es el sistema nervioso central de Sellerfy. Centraliza TODA la informacion del cliente: desde el primer clic en un anuncio de Google Ads hasta el LTV calculado despues de meses de suscripcion. Cada contacto tiene una vista 360 grados que combina datos de la web, el bot de WhatsApp, Stripe, Intercom (legacy), y Google Analytics.

Integraciones conectadas al portal

5.2 Lifecycle Stages

HubSpot utiliza lifecycle stages para representar la etapa de madurez de un contacto. Sellerfy tiene 8 stages configurados: 5 nativos de HubSpot y 3 custom.

5.3 Custom Properties (105 activas)

Ademas de las propiedades nativas de HubSpot (email, nombre, telefono, etc.), Sellerfy tiene 105 propiedades custom visibles y 47 archivadas (legacy de Intercom, PhantomBuster, ZeroBounce y Zoom). Las propiedades archivadas no se borraron — solo se ocultaron de filtros y formularios para mantener el CRM limpio. La propiedad canonica de marketplace es marketplace (no marketplace_principal, que fue archivada por ser duplicada).

5.4 Funnel Stages (Detalle del Enum)

La propiedad funnel_stage es un enum calculado que unifica el estado real del contacto combinando su lifecycle stage de HubSpot con datos de suscripcion de Stripe. Tiene 8 valores posibles, asignados por ltv_backfill.py con 100% de cobertura (6,965 contactos).

1. Si tiene suscripcion activa Y MRR > 0  →  paying
2. Si tiene suscripcion cancelada          →  churned
3. Si lifecycle = MQL o opportunity        →  qualified
4. Si lifecycle = lead / Fuente de Leads   →  registered
5. Si lifecycle = subscriber / (sin datos) →  visitor

5.5 Pipeline de Deals

Los deals en HubSpot representan oportunidades comerciales concretas. En Sellerfy, un deal se crea UNICAMENTE cuando el contacto agenda una demo (fase BOOKED del bot).

5.6 Manual Tecnico para el Equipo

Reglas operativas extraidas del proceso comercial. Cada miembro del equipo debe seguir estas reglas al interactuar con contactos en HubSpot.

5.7 Intercom Backfill

Migracion one-time de datos historicos de Intercom a HubSpot. Intercom era el sistema de soporte/chat anterior de Sellerfy y contenia datos valiosos de comportamiento de usuarios que no existian en HubSpot.

Campos poblados

Normalizacion de paises

El backup de Intercom contenia variantes inconsistentes de nombres de paises. Se implemento normalizacion automatica para 897 contactos:

mexico, México, mexíco, mx, mex  →  Mexico
peru, Perú                       →  Peru
colombia, co                     →  Colombia
us, usa, estados unidos, u.s.    →  United States
españa, spain                    →  Spain
brasil, brazil                   →  Brazil

5.8 LTV y Funnel Stage (Backfill)

Calculo masivo de Lifetime Value, duracion de cliente, y etapa de funnel para todos los contactos de HubSpot. Combina datos de suscripciones e invoices de Stripe con lifecycle stages de HubSpot.

Como se calcula el LTV

5.9 Guia Operativa del Portal HubSpot

HubSpot tiene tres areas principales que el equipo comercial debe dominar: Contactos, Deals y Leads. Cada area tiene un proposito diferente y reglas especificas de operacion. Esta guia detalla como funciona cada una, como esta configurada en Sellerfy, y como operarla dia a dia.

5.10 Mapa Completo de Propiedades del Contacto

Cada contacto en HubSpot tiene 105 propiedades custom visibles (47 adicionales archivadas de herramientas legacy como Intercom, PhantomBuster y ZeroBounce) que se llenan automaticamente por el bot, Stripe, analytics, o manualmente por el equipo. Esta seccion las organiza por categoria para que sepas exactamente que representa cada campo, quien lo llena, y como afecta el proceso comercial.

Datos Basicos del Seller

Se llenan automaticamente cuando el bot extrae informacion de la conversacion, o cuando el seller llena un formulario web.

Propiedades Comerciales (Custom)

Estas son las propiedades que el bot extrae de la conversacion. Son criticas para calificar al lead y preparar la demo.

Propiedades de Suscripcion (Stripe Sync)

Estas propiedades se actualizan automaticamente cada dia a las 6am UTC por stripe_sync.py. Son la fuente de verdad para saber si alguien es cliente, cuanto paga, y su estado de suscripcion.

Propiedades de Producto (App Sellerfy)

Estas se llenan automaticamente desde la app (app.sellerfy.ai) cuando el seller conecta su marketplace o tiene actividad en la plataforma.

Propiedades de Adquisicion y UTMs

Estas propiedades rastrean de donde vino el contacto. Algunas las llena HubSpot automaticamente, otras se llenan por el frontend o por analytics_sync.py.

5.11 Lead Status: Estados de Calificacion

Mientras el Lifecycle Stage indica la madurez general del contacto (Lead, MQL, Customer), el Lead Status (hs_lead_status) indica la etapa operativa dentro del proceso de ventas. Se actualiza automaticamente con cada transicion de fase del bot.

NEW → CONNECTED → IN_PROGRESS → OPEN_DEAL
                                        ↓
                              (sin respuesta 14d + 2 follow-ups)
                                        ↓
                                    BAD_TIMING

Ruta alterna: cualquier fase → ATTEMPTED_TO_CONTACT (follow-up enviado)

Ruta Churn:  Customer cancela suscripcion → WIN_BACK (ex-cliente para reactivacion)

5.12 Propiedades de Deals (Detalle Completo)

Cuando un contacto llega a fase BOOKED (meeting detectada), el bot crea automaticamente un deal con 14 propiedades. El SDR debe revisarlas antes de la demo para estar preparado.

5.13 Tickets y Meetings: Propiedades y Reglas

Tickets de Soporte (creados por el bot)

El bot crea tickets automaticamente en dos escenarios: (1) cuando escala una pregunta que no puede resolver, y (2) cuando un customer_active o churn escribe por WhatsApp.

Meetings (reuniones agendadas)

Los meetings se crean en HubSpot cuando el seller agenda a traves de Cal.com (link enviado por el bot). El bot lee estas propiedades para detectar booking, enviar recordatorios, y detectar no-shows.

5.14 Mapa de Automatizaciones: Que Pasa Cuando

Esta seccion mapea de forma exhaustiva todas las automatizaciones que afectan HubSpot. Cada fila responde: "cuando pasa X, que se actualiza en HubSpot?"

Acciones del Bot → HubSpot

Stripe Sync → HubSpot (Diario, 6am UTC)

HubSpot → Comportamiento del Bot

6.1 Arquitectura del Pipeline de Datos

El pipeline de datos de Sellerfy conecta 5 fuentes en un flujo unificado que alimenta HubSpot como sistema central. Los datos fluyen de izquierda a derecha, desde la captura en la web hasta la optimizacion de campanas en Google Ads.

Web (sellerfy.ai)
  |
  └→ UTM Script (cookie 30d + localStorage)
       |
       └→ Memberstack (metadata)  ⚠ PENDIENTE
            |
            └→ HubSpot (properties del contacto)

Google Ads
  |
  └→ GCLID → Cookie → HubSpot
       |
       └→ gclid_conversions.py → Google Ads Offline Conversions
                                   (cierra el loop de atribucion)

Stripe
  |
  ├→ stripe_sync.py   → HubSpot (suscripciones, MRR, estado, churn)
  |
  └→ ltv_backfill.py  → HubSpot (LTV, months_as_customer, funnel_stage)

GA4
  |
  └→ analytics_sync.py → Reportes diarios + enrichment

Intercom (legacy)
  |
  └→ intercom_backfill.py → HubSpot (datos historicos, one-time)

6.2 UTM Tracking

Script JavaScript inyectado en sellerfy.ai (via Lovable) que captura parametros de atribucion de marketing. Funciona en cada visita a la web, persiste datos en dos capas de almacenamiento y expone una API para que otros sistemas lean los valores.

// 1. Abrir en el navegador:
sellerfy.ai/?utm_source=test&utm_medium=cpc&gclid=test123

// 2. Abrir DevTools → Console

// 3. Ejecutar:
SellerfyUTM.get()
// → {utm_source: "test", utm_medium: "cpc", gclid: "test123", ...}

6.3 GCLID — Pipeline de Conversiones Offline

El pipeline de GCLID (Google Click ID) es la pieza que cierra el loop de atribucion entre Google Ads y las ventas reales de Sellerfy. Permite que Google Ads sepa exactamente que clics generaron clientes pagando, optimizando automaticamente el bidding para encontrar mas usuarios similares.

Como funciona el flujo completo

6.4 Stripe Sync

Sincronizacion diaria de datos de suscripciones entre Stripe y HubSpot. Corre como cron en el droplet de produccion. Es la unica fuente de verdad para el estado de pago de cada cliente.

// Normalizacion por intervalo
mensual         → monto directo
trimestral (3m) → monto / 3
semestral (6m)  → monto / 6
anual           → monto / 12
semanal         → (monto * 52) / 12
diario          → (monto * 365) / 12

// Descuentos
percent_off → total * (1 - pct/100)
amount_off  → max(0, total - amount)

6.5 Metricas Clave (Marzo 2026)

6.6 Scripts y Automatizaciones

Todos los scripts viven en ~/clawd/agents/sellerfy-nurture/. Los scripts de sync se ejecutan automaticamente; los de backfill fueron one-time y ya estan completados.

6.7 Google Analytics (GA4)

GA4 mide el trafico y comportamiento de usuarios en sellerfy.ai. Los datos se acceden via un CLI personalizado (ga4) y se incluyen en los reportes diarios de analytics_sync.py.

6.8 Google Ads

Google Ads es el principal canal de adquisicion pagada de Sellerfy. La integracion con el pipeline de analytics permite atribucion end-to-end desde el clic hasta la suscripcion.

6.9 Pendiente Critico — Conexion Memberstack a HubSpot

Contexto

La web de Sellerfy esta construida en Lovable con Memberstack para autenticacion de usuarios. La integracion entre Memberstack y HubSpot fue construida por Pablo directamente en Lovable (no es Zapier, ni Make, ni un backend custom del CTO). Esto significa que el cambio tambien lo tiene que hacer Pablo en Lovable.

Lo que falta exactamente

Impacto de no completar

// Verificacion:
// 1. Abrir: sellerfy.ai/?utm_source=test&utm_medium=cpc&gclid=test123
// 2. Console → SellerfyUTM.get()
// → {utm_source: "test", utm_medium: "cpc", gclid: "test123", referrer: "...", landing_page: "..."}

7.1 Protocolo de Atención

El protocolo de soporte de Sellerfy opera en dos niveles claramente definidos, donde la IA resuelve la mayoría de las consultas de forma instantánea y el equipo humano interviene solo cuando es necesario.

Principios de Soporte

7.2 Prioridades de Tickets

7.3 SLAs Completos

Soporte General

7.4 Soporte por Plan

7.5 Troubleshooting Checklist

Guía paso a paso para resolver los problemas más comunes. Sofi usa esta checklist automáticamente al detectar problemas técnicos.

Problemas Generales

Panel vacío / $0 en el dashboard

Token expirado

Datos diferentes al marketplace

7.6 Que Resuelve Sofi Automaticamente (Level 0)

Sofi IA atiende el 100% de las consultas iniciales sin intervencion humana. Su conocimiento proviene de 13 archivos (5 JSON + 8 Markdown) que forman el Knowledge Base (ver seccion 4.14). Aqui esta el detalle de que tipo de consultas resuelve por si sola y cuales escala.

7.7 Flujo Completo de Atencion al Cliente

Cuando un cliente activo o ex-cliente escribe por WhatsApp, el bot sigue un flujo diferente al de un prospecto nuevo. El sistema identifica automaticamente que es un cliente (ver seccion 4.16) y cambia su comportamiento completo.

7.8 Tickets Automaticos en HubSpot

Cuando un cliente activo o ex-cliente escribe al bot, se crea automaticamente un ticket de soporte en HubSpot. La prioridad se determina de forma inteligente analizando el contenido del mensaje con la funcion classify_ticket_priority().

Clasificacion de prioridad por keywords

Informacion incluida en el ticket

7.9 Automatizaciones de Soporte

El bot ejecuta 5 procesos automatizados en segundo plano que mantienen el pipeline de soporte y ventas activo sin intervencion humana. Cada uno se activa via endpoints HTTP que se ejecutan por cron jobs en el servidor.

7.10 Canales de Soporte

7.11 Proceso de Onboarding Post-Venta

El onboarding es el momento mas critico del ciclo de vida del cliente. Un cliente que no ve valor en los primeros dias tiene alta probabilidad de pedir reembolso (garantia de 7 dias). Este proceso asegura que cada nuevo cliente tenga una experiencia exitosa desde el primer minuto.

Sobre Sellerfy

Planes y Precios

Seguridad y Conexión

Funcionalidades

Problemas Técnicos

Competencia

Soporte

Otros

9.1 Equipo Comercial

El equipo comercial es el punto de contacto directo para clientes y prospectos. Son quienes toman demos, resuelven dudas comerciales y acompañan al cliente durante el proceso de onboarding.

9.2 Equipo Técnico (Autonomous)

El equipo técnico es responsable del desarrollo, infraestructura y evolución de la plataforma. No se mencionan en conversaciones comerciales — los clientes interactúan exclusivamente con el equipo comercial y Sofi IA.

9.3 Canales de Comunicación

9.4 Visión

Propuesta de valor basada en el uso de la plataforma

10.1 Arquitectura del Bot

WhatsApp → Twilio → Chatwoot → POST /hooks/sellerfy → app.py (Opus 4.6)
                                                                 ↓
                                                     HubSpot + Conversation DB

10.2 Clasificacion de Contactos (6 tipos)

El bot clasifica cada contacto automaticamente usando classify_contact(). Cada tipo activa un comportamiento diferente del agente.

10.3 Funnel de 7 Fases (cold_lead)

Triggers de Transicion

10.4 Templates de WhatsApp — 14 Templates × 7 Triggers

10.5 Flujo Visual Completo

LEAD NUEVO
  ├── Backlog (frio) ──────→ COLD pool (3 templates)
  ├── Formulario (tibio) ──→ WARM pool (1 template)   ──→ DISCOVERY
  └── Google Ads (caliente)→ WARM pool (1 template)
                                         │
                                    Responde?
                                   /          \
                                 SI            NO
                                 │              │
                            Bot (Opus 4.6)   24h → Follow-up 1
                                 │              │
                                 ▼          Responde?
                            INFORMING       /       \
                                 │        SI         NO
                                 ▼        │       48h → Follow-up 2
                            PROPOSING    Bot          │
                                 │              Responde?
                                 ▼              /       \
                              BOOKED          SI        NO → LOST
                              /    \          │
                        Reminder  No-show   Bot
                       (2h antes) (si falta)

10.6 Crons Activos (7 crons en droplet)

10.7 Escalacion y Handoff

10.8 Anti-alucinacion (Validador)

10.9 Deteccion de Auto-replies

WhatsApp Business auto-replies ("Gracias por comunicarte con...") se detectan por texto (15+ patrones) + timing (<10s).

10.10 Atribucion de Origen

Cada contacto se clasifica por origen automaticamente. El nombre de WhatsApp se sincroniza de Chatwoot a HubSpot.

10.11 A/B Testing Dashboard

Dashboard completo de performance del bot. Muestra metricas en tiempo real:

• Funnel por fase: distribucion de leads en cada etapa del pipeline
• Performance por origen: tasa de respuesta segmentada (Web, GWS, Database, etc.)
• A/B testing por template: contenido de cada template con su tasa de respuesta

Conversion entre etapas (18 marzo 2026)

Como sabe el bot que alguien es cliente?

Cuando alguien escribe al WhatsApp, lo PRIMERO que hace el bot es clasificar al contacto. Si es cliente, trial, churn o registered, el bot NO entra al pipeline de ventas — entra a un flujo de servicio diferente.

Mensaje llega al WhatsApp
    |
    v
hubspot.classify_contact(contact)
    |
    ├── Stripe subscription_status = "active"?     → customer_active
    ├── Stripe subscription_status = "canceled"?   → churn
    ├── trial_end_date > hoy?                      → trial_active
    ├── trial_end_date < hoy (vencido)?            → trial_expired
    ├── memberstack = true O preview data?         → registered
    └── Nada de lo anterior?                       → cold_lead (pipeline ventas)
      

Fuente de verdad: Stripe es la fuente principal. stripe_sync.py corre diario a las 6am UTC y actualiza lifecycle + subscription_status en HubSpot. El bot lee esas propiedades en tiempo real.

Que hace el bot con cada tipo de usuario existente

Cuando se crea un Ticket en HubSpot

Hay 2 flujos que crean tickets automaticamente. Ambos lo hacen en el Support Pipeline de HubSpot.

Diferencia clave: Escalacion NO hace handoff (bot sigue activo). Handoff SI hace handoff (bot se detiene y humano toma control).

Support Pipeline (HubSpot Tickets)

Total tickets: 299 | El bot solo crea tickets en stage "New". Todo lo demas es manual.

Clasificacion automatica de tickets

El bot clasifica automaticamente la prioridad y categoria del ticket analizando el mensaje del cliente.

Cada ticket tambien registra: seller_plan (lite/growth/scale/trial/none) y canal_origen_ticket (whatsapp_bot).

Como se asignan conversaciones en Chatwoot

is_bot_handling(conversation):

  status = "pending"?              → BOT responde
  status = "open" + sin asignar?   → BOT responde
  status = "open" + bot asignado?  → BOT responde
  status = "open" + humano asignado? → BOT SE DETIENE
  status = "resolved"?             → BOT SE DETIENE