Abandoned Cart Recovery CRM integrated with AI

Context

The Precious Hearts Club sells subscriptions for Christian children's books to families. The business does not scale with spreadsheets and manual WhatsApp: each checkout abandonment requires precise timing (audio, conversation, link, human follow-up), each annual subscriber needs to be contacted before expiration, and each recurring Pix payment needs a reminder without mixing it with the sales pipeline.

The challenge was to build an integrated business operation — not a generic CRM — that orchestrates people, automation, and AI across three distinct fronts, ensuring that a prospect lead does not receive a renewal message, that Bia does not sell to existing customers, and that confirmed payments do not get lost among resent webhooks.

The solution is an event-driven platform: each external action (abandonment, response on WhatsApp, link sent, AppMax payment, cycle expiration, upcoming Pix) enters as an event, is processed with idempotency, and moves the lead in the correct state machine. The team operates in queues and kanbans; Bia handles the automated phase; closers take over when automation runs out of time.

---

The Three Modules

Commercial Module — Funnel 1 (abandoned cart with Bia)

Problem: leads abandon checkout and cool off within minutes. Without cadence and a clear handoff, the team loses recoverable conversions.

What it does: recovers abandoned carts in eight steps (F1-01 Captured → F1-08 Converted). The journey combines automation (Reportana, Bia) and human work (closers in the Daily Queue).

General flow:

1. The checkout platform notifies of abandonment → lead created in F1-01.
2. Reportana triggers the initial audio → F1-02.
3. The lead responds → conversation with Bia (AI assistant via WhatsApp) → F1-03.
4. Bia qualifies, addresses objections, and sends the link → F1-04.
5. No payment within 24 hours → handoff to the closer → F1-05 (Bia stops selling).
6. The closer executes the D+1…D+7 sequence in the Daily Queue → F1-06.
7. No closure within 14 days → migration to community/webinar → F1-07.
8. AppMax confirms payment → atomic write-off, sale recorded → F1-08.

Screens: Executive dashboard, Daily Queue, Funnel 1 Kanban, Leads, Sales performance, Conversation intelligence (objections detected by AI), Cadence, Templates, Integrations.

Differential: Bia checks the CRM before each shift (can_sell: false for active customers). The cadence has four tracks (silent, inactivity in conversation, post-link, human handoff), each anchored in the stage where the lead is.

---

Renewal Module — Funnel 3 (annual subscription)

Problem: annual subscribers need to renew before expiration. Without a dedicated pipeline, renewal competes with prospecting, commercial numbers get polluted, and the closer does not know whom to prioritize.

What it does: an isolated pipeline for active customers with cycles in subscription_cycles (expiration date, renewal number, plan). Leads from F3 do not appear in global search or in the commercial dashboard of F1; renewal sales use is_renovacao = true.

Stages: F3-01 Upcoming expiration → F3-02 Offer 1 (full price) → F3-03 Offer 2 (coupon RENOVA10) → F3-04 Offer 3 (smart payment) → F3-05 Renewed, F3-06 Lost or F3-07 Blocked.

Operational sequence (related to expiration):

• Prevention (before D0): D-30 full price, D-15 RENOVA10, D-7 smart payment.
• Rescue (after D0): D+1, D+7, and D+15 with rescue arguments; on D+15 without renewing → F3-06 Lost.

Entry into the pipeline: daily scan at D-30, CSV import from the renewal base, or manual entry. The CRM advances the stage according to the calendar; touches are manual in the Renewal Queue (priority for expired and pending touches).

Screens: Renewal Queue, Funnel 3 Kanban, Renewal Dashboard, Import base.

---

Billing Module (recurring Pix)

Problem: subscribers on recurring Pix need reminders before and after expiration, without mixing with leads in prospecting or annual renewal.

What it does: a completely separate pipeline in the crm.cobrancas table, without a sales funnel — its own kanban C-01 / C-02 / C-03.

Flow:

1. C-01 — subscription system notifies of upcoming Pix; n8n sends reminder "due tomorrow"; CRM records the charge.
2. C-02 — on D+2 (commercial window 8am–10pm), CRM triggers follow-up "still open" via n8n → WhatsApp.
3. C-03 — payment webhook confirms the write-off.

Phone records still in the sales funnel are removed from the pipeline; old paid ones exit the operational kanban.

Screen: Billing (kanban + realtime).

---

Event-Driven Architecture

The CRM is not a “form that stores status.” It is an event engine where the lead's stage is a consequence of what happened — never manually updated by external integrations.

Principles

Integration Map

Renderizando diagrama Mermaid...

Canonical Event Flow

1. External source triggers (abandoned checkout, WhatsApp message, AppMax payment, etc.).
2. n8n normalizes the payload and calls the corresponding Edge Function.
3. The Edge Function validates the token, logs webhook_events (idempotent), and calls the RPC (ingest_*).
4. The RPC applies the state machine, schedules or cancels cadence, and in payments executes atomic write-off.
5. A new record in eventos_lead documents what occurred.
6. The React frontend reflects the change via Supabase Realtime and RLS by profile (admin, manager, closer, viewer).

Bia in the Ecosystem

The Bia agent (n8n workflow) is the conversational interface of the commercial module — not the brain of the CRM:

• Before responding, it checks human-takeover (can_bia_send).
• Notifies the CRM on each received and sent message (webhook-bia).
• Can schedule future payment (tool → Edge Function schedule-payment).
• Can escalate to human (n8n sub-workflow).
• Uses Grok (OpenAI fallback), Postgres memory, and Redis buffer for message debounce.

The critical domain (stages, cadence, sales, multi-funnel conflicts) remains in PostgreSQL — AI converses; the database governs.

---

How the Three Modules Relate

Renderizando diagrama Mermaid...

• A lead in prospecting (F1) does not enter renewal or billing.
• An annual customer enters F3 in the D-30 scan; renewal sales do not inflate the commercial dashboard.
• Recurring Pix operates in a separate pipeline; prospecting phone numbers are excluded from the billing kanban.
• Conflicts (e.g., lead in F1-05 and attempt to enter F3) are recorded in funnel_conflicts with defined precedence.

---

Stack and Technical Decisions

---

Business Outcome

The sales team now operates with real-time visibility: prioritized queue, kanban by stage, performance by closer, objections detected in conversations with Bia. Annual renewal has its own pipeline with a clear prevention and rescue sequence. Pix billing does not pollute the sales funnel. And the event-driven architecture ensures that, even with duplicated webhooks or unstable integrations, the lead's state reflects what actually happened — with an auditable trail in each transition.