Where Off-the-Shelf Chatbots End: Five Integration Boundaries, With Example Payloads

#ai #webdev #chatbot #automation

I co-founded NxFlowAI, an AI automation agency. These boundaries apply whatever you build with.

When a small business asks a developer to "just add a chatbot", the first version is easy. The trouble starts when the bot needs to do something other than talk. This post maps five boundaries I see repeatedly, the line where off-the-shelf chatbots end and custom AI begins. For each one: what the hosted bot usually gives you, what the business actually needs, and a payload sketch.

1. Write-back with idempotency

Hosted bots often "sync to CRM" with a fire-and-forget webhook. The business needs exactly one lead record per person per enquiry, even when webhooks retry.

{
  "event": "lead.upsert",
  "idempotency_key": "wa:+00000000000:2026-10-05T09:14",
  "match_on": ["phone_e164"],
  "fields": {
    "source": "whatsapp",
    "intent": "booking",
    "next_action_at": "2026-10-05T12:00:00Z",
    "owner": null
  }
}

If your integration cannot express idempotency_key and match_on, retries create duplicates, and duplicates create two staff members calling the same customer.

2. Identity across channels

The same customer writes on Instagram, then emails, then calls. A hosted bot sees three strangers. The business needs one person.

{
  "person_id": "p_123",
  "identities": [
    {"channel": "instagram", "handle": "@example"},
    {"channel": "email", "address": "someone@example.com"},
    {"channel": "phone", "e164": "+00000000000"}
  ],
  "merge_policy": "manual_review_if_conflict"
}

Note manual_review_if_conflict. Automatic merges on fuzzy matches are a quiet source of data loss.

3. Approval state

Hosted bots are built to finish conversations. Businesses need some messages to pause for a person.

{
  "draft_id": "d_456",
  "channel": "whatsapp",
  "text": "Yes, we can do 10 units at the standard price.",
  "policy_flags": ["mentions_price"],
  "state": "awaiting_approval",
  "approver_role": "owner",
  "expires_at": "2026-10-05T18:00:00Z",
  "on_expiry": "notify_backup_approver"
}

expires_at and on_expiry matter more than the model. An approval queue nobody watches is worse than no queue.

4. Long-running state and timers

"Follow up tomorrow if they have not replied" is a timer that outlives the conversation. Hosted bots typically reset when the chat ends.

{
  "workflow": "quote_followup",
  "lead_id": "l_789",
  "steps": [
    {"at": "+24h", "if": "no_reply", "do": "draft_followup", "approval": false},
    {"at": "+72h", "if": "no_reply", "do": "assign_to_owner", "approval": false}
  ],
  "cancel_on": ["reply_received", "deal_closed"]
}

On WhatsApp, also remember that messages outside the 24-hour customer service window require approved templates, so the follow-up step must know which mode it is in.

5. Business-outcome observability

Hosted bot dashboards report conversations, deflection and satisfaction. The owner wants to know: did leads get an owner, did quotes get chased, did anything silently stop?

{
  "metric": "leads_without_owner_older_than",
  "threshold_minutes": 60,
  "alert": {"channel": "email", "to": "ops@example.com"}
}

If you cannot alert on the business outcome, you will find out about failures from customers.

So, buy or build?

If a business only hits boundary 1 at a basic level, a hosted bot with a decent integration is fine. Once it needs 3 and 4 together (approvals plus timers across its own systems), you are building a workflow with a chat front end, and it is usually cleaner to design it that way from the start. Either way, do the mapping first; our owner-friendly workflow audit guide covers the non-technical half. Our own first audits take 72 hours.

DEV Community