Why "inbound operating system" and not "AI funnel"
Most agencies sell an AI funnel. We build an inbound operating system. The difference is not branding; it is what you can actually do with it.
An AI funnel is a sequence: capture, reply, route to a form, hope. An operating system owns the state of every conversation across channels and writes that state to a database your closers and reporting depend on. The funnel breaks the moment a prospect crosses a channel. The OS does not, because state crossing channels is the entire point.
| Aspect | AI funnel | Inbound operating system |
|---|
| Scope | One channel | Instagram + WhatsApp + CRM as one path |
| State | Lives in the chat tool | Lives in the CRM, mirrored to chat |
| Concurrency | Sequential | Designed for spikes |
| Failure mode | First-reply only | Full path: capture, qualify, route, close, sync |
| Maintenance | Tuned by a marketing agency | Maintained as engineering |
| Reporting | Vanity metrics | Real metrics on every stage |
If you are an event company doing under 5 enquiries a week, an AI funnel is fine. If your Saturday afternoon can bring 40 DMs in two hours, you have outgrown funnels.
The four modules
The OS is not one big AI. It is four modules with clean responsibilities.
Module 1: Instagram OS
Captures DMs, classifies comment intent, and runs the first-touch qualifier. The full architecture is in the Instagram OS post. The short version: it owns the inbound surface for Instagram and ends every conversation in one of three labels: closer-ready, needs-nurture, or disqualified.
Module 2: WhatsApp OS
Picks up the handoff from Instagram OS or receives a direct WhatsApp inbound, finishes the qualification if needed, and routes to a closer. Uses the WhatsApp Business Cloud API with templated messages for state-preserving handoffs. For teams without a SIM, the Twilio number verification path is the cleanest production setup.
Module 3: CRM orchestrator
Writes every conversational event to the CRM in real time: lead created, qualifying answer captured, label changed, handoff sent, closer assigned. Most teams use GoHighLevel; we have also built into HubSpot, Pipedrive, and Airtable. The orchestrator is the part that turns the CRM from a leaky spreadsheet into a system of record.
Module 4: Closer console
Not a separate UI; the closer keeps using WhatsApp Web or WhatsApp on their phone. The "console" is a structured first message in WhatsApp that summarises the qualified state: name, event date, headcount, venue type, budget band, source. The closer reads five fields and replies in context. That is the whole job of the console: hand a closer a thread that does not need warm-up.
The data layer
Underneath the four modules is a small, opinionated data model. It is the part most agencies skip and most engineers want to over-design. Keep it small. For an event company:
That is the whole schema. Everything else is derived. Reporting joins on labels, source.channel, and the time-series of updated_at. Closer assignment looks at labels and a small round-robin table. Nurture flows look at labels and qualification.
The schema lives in the CRM as custom fields. Whatever the CRM calls them, we map them to this shape so the rest of the OS can read and write consistently.
The qualification ruleset
The ruleset is the business-specific IP. For an event company it usually looks something like this. Treat it as a starting point; the exact thresholds come from a conversation with the founder.
The max_messages_in_qualifier is important. After six exchanges without enough fields, the system hands off to needs-nurture rather than badgering. Prospects feel that. So does your team when the closer queue is not full of half-baked threads.
The handoff template set
The handoff is two messages, not one.
Message 1 (auto-sent inside the IG thread when label flips to closer-ready):
Got it, Priya. I'm WhatsApping you the details so our team can confirm Dec 12 for 220 guests. Tap here to continue: wa.me/91XXXXXXXXXX?text=Continue%20event%20enquiry
Message 2 (auto-sent on WhatsApp the moment they tap, using an approved Meta template):
Hi Priya, this is the FusionSync team. Quick recap so we can move fast: Date: Dec 12 Guests: 220 Venue type: Outdoor Source: Reel "Winter mandap setups" One of our event leads will pick this up here in WhatsApp in the next 5 minutes. Reply STOP to opt out.
That structure does two things at once. It preserves the conversation state for the prospect (no asking the same thing twice) and gives the closer a complete summary at the top of the thread. The closer never has to scroll up.
The pilot, day by day
A typical 4 to 7 day pilot looks like this:
| Day | What we do | What you do |
|---|
| 1 | Meta Business Manager + WhatsApp Business audit, CRM access | Hand off accounts + ICP brief |
| 2 | Capture wiring, comment intent classifier, first-touch flow | Approve qualifying question wording |
| 3 | Qualification ruleset, handoff template submission to Meta | Confirm thresholds for closer-ready |
| 4 | CRM orchestrator, real-time writes, closer assignment | Pick the campaign to run pilot on |
| 5 | Live run on the chosen campaign, monitoring on | Run the campaign as usual |
| 6 | Tuning ruleset, template wording, edge case handling | Send us threads that did not feel right |
| 7 | Stage-by-stage metrics review, decision point | Decide: continue or stop |
We deliberately run the pilot on one campaign, not the whole business. It is enough volume to learn from, small enough to be safe.
What the monitoring actually shows
The metrics you watch on day 5 of a pilot are not vanity metrics. They are the operational health of the system.
| Metric | What it tells you |
|---|
| First reply latency, p50 and p95 | Whether capture and qualifier are healthy |
| Comment-to-DM conversion | Whether the intent classifier is well-tuned |
| Closer-ready rate per source | Whether the ruleset is calibrated to the channel |
| Handoff template open rate | Whether the prospect is finding the WhatsApp thread |
| Time from `closer-ready` to first closer message | Whether the closer queue is full |
| Lead leakage (unread threads at 24h) | Whether the system is leaking anywhere |
If first reply latency p95 is over 5 minutes, capture is broken or there is a webhook race condition. If closer-ready rate on a high-spend channel is 5%, the ruleset is too strict. If time to first closer message is over 30 minutes during business hours, you do not have enough closer coverage or routing is misconfigured. Every metric points at a specific component.
What this is not
- It is not a chatbot. Module 1 contains a chatbot-shaped thing for the first reply, but that is one component, not the system.
- It is not a CRM replacement. The OS depends on your CRM as a system of record.
- It is not a marketing service. We do not run your ads. We turn the inbound those ads create into bookings.
- It is not a SaaS product you can self-serve. The ruleset is specific to your business; setting it up well is the difference between a working system and an annoying one.
Where to read next
FAQ
Is this AI? Parts of it. The qualifier uses a small language model for in-thread conversation and a tiny classifier for comment intent. The routing, CRM writes, and monitoring are deterministic. The AI is the smallest part of the stack. The infrastructure around it is what makes it work.
Why a 7-day pilot and not a 30-day engagement? Because we want you to see real production traffic through the system before you commit. A 30-day discovery engagement is what agencies sell when they cannot prove value in a week. The pilot is the proof.
What if the pilot fails? You walk away. We do not pre-bill the next phase. If the operating system did not produce more closer-ready handoffs than your previous setup, there is no second invoice.
Can I run this in-house after the pilot? Most clients keep us on for maintenance and tuning because Meta changes the WhatsApp Cloud API and Instagram Graph API faster than most teams can keep up with. But the system is yours. If you want to run it in-house, we hand over the canvases, the ruleset, the templates, and the runbook.
Does this work for non-event businesses? The architecture works for any inbound-heavy, conversation-led business. The current focus is event companies because that is where the inbound-to-booking gap is most extreme and the win is most measurable. Clinics, mortgage brokers, and high-ticket service businesses are next.
The bottom line
An inbound operating system sits on top of Instagram, WhatsApp, and your CRM as one path. It captures every enquiry, qualifies it in-thread, hands off to a closer when the rules say so, and writes everything back to the CRM in real time. Installation runs 4 to 7 days on one campaign and covers the data layer, the qualification ruleset, the WhatsApp template set, and the monitoring you actually need.
- An inbound operating system is four modules: Instagram OS, WhatsApp OS, CRM orchestrator, and closer console.
- The data layer is small on purpose. Lead, contact, qualification fields, labels, transcript link.
- The ruleset is the IP. The engineering is the same across event companies; the thresholds are unique.
- The pilot runs in 4 to 7 days on one campaign. Either it ships or you walk away.
- Reporting is operational, not vanity: first reply latency, closer-ready rate, time to closer, lead leakage at 24h.
The next step is a 7-day production pilot on one campaign. We install the full system, you run real traffic through it, you decide.