Case Studies: Systems in Production

Problem

Bonnies Bakery's customers already ordered through WhatsApp, but the channel depended on fast human replies during rushes, after hours, and across Hindi, English, Marathi, and Hinglish. Routine questions about stock, price, delivery, and payment consumed owner time, while slow replies or wrong information risked lost orders.

System

• Node.js + TypeScript Express backend receiving Twilio WhatsApp webhooks
• 10-second message buffer so fragmented customer messages are interpreted together
• Claude agent with tool use for live Rista POS inventory, product photos, delivery validation, order status, and Razorpay payment links
• Supabase database, storage, and realtime message stream for conversation history, AI state, labels, contacts, and analytics
• Private owner dashboard with live chat, AI on/off takeover, manual replies, labels, contact notes, and analytics
• Monitoring and recovery layer with integration logs, pg_cron checks, stale Razorpay order polling, and paid-order fulfillment safeguards

Proof Points

• Backend is live on Render; the private owner dashboard is live on Netlify.
• All WhatsApp orders are designed around Razorpay advance payment before Rista POS fulfillment.
• Two-month production data shows 207 payment-link recipients, 41.1% phone-level link-to-paid conversion, and a 37 pickup / 50 delivery split.
• Customer behavior data shows 375 inbound media messages from 268 customers and 540 customers with custom or media-related intent.
• Peak demand concentrated around 11 AM-1 PM IST; the busiest day in the window was May 9, 2026 with 1,147 messages.

Problem

Outbound calling operations were dependent on manual list exports, spreadsheet cleanup, no-phone filtering, Ringg uploads, and remembering who had already been called. That made campaign execution slow, error-prone, and hard to audit after the fact.

System

• Three-layer architecture: markdown directives, Python orchestration, and deterministic execution scripts
• Apollo saved-list puller with extra filters, pagination, and exponential-backoff retries
• Supabase-backed dedup layer that checks `called_leads` before any lead is re-queued for calling
• CSV builder that drops no-phone leads and maps normalized Apollo fields into Ringg's upload schema
• Ringg integration that uploads the CSV, triggers `/campaign/start`, and only marks leads called after a successful start
• Per-run audit logging in Supabase `campaign_runs`, plus per-campaign YAML configs and a dry-run mode for safe staging

Proof Points

• The repo's approved design spec explicitly defines a cron-triggered Apollo -> dedup -> CSV -> Ringg -> Supabase flow.
• The sample campaign config `configs/campaigns/saas_demo_us.yaml` shows list-based Apollo sourcing, Ringg campaign mapping, and a dry-run mode.
• Tests cover Apollo pagination, dedup behavior, CSV generation, Ringg upload/start behavior, and end-to-end run orchestration.
• The initial migration creates `called_leads` and `campaign_runs`, which gives the pipeline durable audit state instead of spreadsheet memory.

Problem

Pre-sales processes relied heavily on manual handling of call transcripts and customer communication. This resulted in operational delays, inconsistent follow-ups, limited analytical insights, and scalability constraints as inquiry volumes grew.

System

• Workflow and system architecture design
• End-to-end n8n automation for pre-sales call transcripts with AI-based diarisation and analysis
• WhatsApp chatbot integration via WATI + n8n with backend logic and frontend conversational flows
• Prompt engineering and AI logic configuration
• End-to-end testing, troubleshooting, and optimization for scalability
• Structured handoff for future expansion

Proof Points

• n8n workflows automated pre-sales call transcript processing and AI analysis.
• WhatsApp chatbot flows connected customer communication to backend automation logic.
• Structured handoff made future expansion easier for the internal team.