Inbound evidence
Normalize supported message events and preserve conversation context.
Channel / WhatsApp
Keep the BSP. Add the governed support loop.
OpenOS normalizes provider events, runs the published support workflow, preserves delivery evidence, and moves exceptions into Workspace without becoming the WhatsApp delivery provider.
- Built for
- Support operations and channel owners
- Answers
- What does OpenOS own—and what remains with the WhatsApp provider?
01 Provider connection Provider boundary
The customer conversation needs intelligence around it—not another BSP in the path.
OpenOS owns workflow intent, evidence, escalation, quality, and decisions. The customer-selected provider continues to own live message delivery and provider-specific retry behavior.
Governed reply
A published workflow decides whether to answer, use an authorized tool, or escalate.
Delivery state
Provider attempts and receipts are recorded where the active adapter supports them.
Mechanism
The WhatsApp support path
Receive
Validate the configured webhook path and normalize the supported inbound event.
Resolve
Run the published L0 workflow using approved knowledge and authorized tools.
Escalate
Project exceptions into Workspace with conversation and customer context.
Learn
Move configured eligible closes into Quality and repeated patterns into Trinetra.
Operational control
Activation and responsibility
Availability depends on the selected provider path, credentials, app approval, templates, and production acceptance.
Amcos path
The repository contains the strongest production-accepted WhatsApp support loop, including handoff and quality projection.
Direct Meta path
Implemented foundations require customer credentials and Meta app activation; capabilities vary by message and template scope.
Customer ownership
The WhatsApp business account, provider contract, templates, and required approvals remain customer-controlled.
Evidence
OpenOS retains normalized conversation and operational evidence within the tenant boundary.
Channel scenario
A customer asks for return status on WhatsApp.
Illustrative workflow using demonstration dataThe configured BSP receives and delivers the customer message.
The workflow understands the intent and attempts the permitted status path.
When the result is inconsistent, Workspace receives the complete handoff state.
The configured eligible close can enter the versioned audit workflow.
Measures
Define success before the workflow changes.
Inbound processing
Supported provider events accepted and projected into the tenant support state.
Delivery evidence
Outbound attempts and provider receipts recorded by the active adapter.
Contextual handoff
Escalations carrying the required transcript, reason, and customer context.
Direct answers
What buyers ask next.
Does OpenOS replace our WhatsApp provider?
No. The provider remains responsible for channel delivery. OpenOS adds the governed support and evidence loop around it.
Can OpenOS send WhatsApp replies?
Implemented provider paths can send governed replies when the customer credentials, templates, provider permissions, and activation requirements are satisfied.
Tailored walkthrough
Bring one support workflow. Leave with a clear first loop.
A tailored walkthrough for Support/CX, operations, and technology leaders—using your channels, responsibilities, and success measures.
- 01Your current loopChannels, systems, volume, and the operational gap.
- 02The product proofResolve, escalate, audit, and decide in one scenario.
- 03A scoped first deploymentOne workflow with explicit evidence and success measures.
Prefer email? sales@openost.com