Every channel → one client graph → portal + AI

This page shows the intended wiring: marketing site intake, verified channel binding in the client portal, and the conversation loop your engineers will attach to WhatsApp Cloud API, mail ingress, voice, and Meta/LinkedIn connectors.

Surfaces we unify

Each connector lands in the same orchestration graph. Today you see UI and copy; tomorrow the same fields map to webhooks, OAuth tokens, and message templates per tenant.

WhatsApp Business
Voice / PSTN
Email threads
Instagram DM
Messenger
LinkedIn
Portal chat

New lead path

1Message arrives from WhatsApp, a phone call transcript, email, or a social DM — the connector captures text, media handles, and routing hints (stub until APIs are on).
2If the sender is unknown, we open a guest thread and ask them to verify email or phone inside the client portal before linking PII-heavy data.
3A single Party + application record is created so every later touch reuses the same case identifiers.
4Automation and AI advance checklist and document steps on policy rails; legal or high-risk gates pause for a human specialist.

Existing client path

1Client signs in to the portal → Settings → Connect channels and completes verification for each surface they want (email code, WhatsApp pairing, social OAuth).
2Inbound and outbound traffic on those channels is tagged with the verified identities and attached to open matters.
3Preferred channel + quiet hours from Communication preferences decide where proactive AI messages may be delivered.

How the AI assistant participates

Same mental model on web-public and portal: the model never “owns” the case — it proposes actions under tool and policy allowlists; humans can always override.

Step 1

Normalize inbound payloads to a canonical message with channel, language, attachments, and suggested intent.

Step 2

Retrieve context: active applications, checklist gaps, and allowed knowledge snippets (RAG) scoped to that client.

Step 3

Draft a reply or internal summary; run policy checks (PII, tone, module rules, escalation triggers).

Step 4

Send via the verified channel the client chose, log to the audit trail, and mirror the state in the portal timeline.

Where real APIs plug in

The UI you ship today should not change when backends go live — only the data fetchers and webhook handlers gain implementations.

Marketing site: optional lead capture endpoints + signed deep links into portal signup with channel hints.
Portal: channel binding service issues verification challenges and stores encrypted tokens for Meta/WhatsApp, Microsoft/Google mail, and social OAuth.
Worker tier: inbound parsers classify threads, attach `application_id`, enqueue AI jobs, and respect per-tenant automation toggles.

Talk to us about connectors Open client portal

New lead path

1Message arrives from WhatsApp, a phone call transcript, email, or a social DM — the connector captures text, media handles, and routing hints (stub until APIs are on).

2If the sender is unknown, we open a guest thread and ask them to verify email or phone inside the client portal before linking PII-heavy data.

3A single Party + application record is created so every later touch reuses the same case identifiers.

4Automation and AI advance checklist and document steps on policy rails; legal or high-risk gates pause for a human specialist.

Existing client path

1Client signs in to the portal → Settings → Connect channels and completes verification for each surface they want (email code, WhatsApp pairing, social OAuth).

2Inbound and outbound traffic on those channels is tagged with the verified identities and attached to open matters.

3Preferred channel + quiet hours from Communication preferences decide where proactive AI messages may be delivered.