> ## Documentation Index
> Fetch the complete documentation index at: https://docs.switchbord.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Like-for-Like Functionality

> Detailed parity map for replacing Charles with an internal WhatsApp control plane.

# Like-for-like Functionality

This page is the docs-app view of the fuller parity matrix in [Feature Matrix](/platform/feature-matrix). The question it answers is simple:

What must exist before this platform can replace Charles in real operator workflows?

## Replacement standard

The platform is operationally like-for-like when:

* inbound customer traffic lands on our webhook and appears in our inbox
* outbound messages, templates, and status updates are owned by our platform
* contacts, subscriber state, and opt-out handling no longer depend on Charles
* operators can service conversations without switching back to the incumbent tool
* internal systems can keep calling compatibility endpoints during migration
* operations can inspect, replay, and audit failures without vendor intervention

## Module map

### Inbox and operator workspace

Required parity includes:

* conversation list, search, queue filters, assignment state, unread counts
* thread detail with inbound and outbound chronology
* delivery state and read-state visibility
* service-window awareness and template-only warnings
* contact side panel, notes, tags, and quick actions
* template send entrypoints and shared-reply behavior
* auditability for assignment, send, replay, and intervention actions

### Contacts and subscriber state

Required parity includes:

* external CRM reference IDs
* phone normalization and identity matching
* opt-in and opt-out state
* tags, notes, and custom properties
* source attribution and commercial context
* explicit suppression behavior for unsafe recipients

### Templates and shared replies

Required parity includes:

* local mirror of provider templates
* locale, category, variable, and approval visibility
* send gating when the conversation is outside the service window
* preview and validation before send
* team-owned shared replies distinct from provider templates

### Campaigns

Required parity includes:

* campaign draft and launch review
* audience or snapshot selection
* scheduling state
* recipient-level delivery and failure visibility
* pause, resume, cancel, and audit trails

### Journeys and automations

Required parity includes:

* webhook and compatibility triggers
* versioned definitions
* waits, branches, and property/tag updates
* publish state
* run history, failures, and replay-safe execution boundaries

### Integrations and compatibility

Required parity includes:

* contact mutation compatibility endpoints
* journey-trigger compatibility endpoints
* webhook-first integration model for Twenty CRM
* explicit audit metadata for inbound partner actions
* replay and failure inspection for integration traffic

### Operations and governance

Required parity includes:

* runtime diagnostics
* webhook forensics and replay controls
* queue and outbox visibility
* audit log access
* feature flags and kill switches
* credential and channel administration

## Priority bands

### P0 continuity layer

* inbox core
* contacts and subscriber state
* template registry and send gating
* inbound webhook ingest
* outbound intent queueing
* delivery and status reconciliation
* compatibility endpoints
* runtime diagnostics and audit

### P1 operational parity

* campaigns
* journeys runtime
* segments and audience management
* deeper Twenty CRM synchronization
* reporting essentials
* collaboration ergonomics

### P2 expansion

* AI assist layers
* richer experimentation
* broader channel support
* advanced analytics and recommendation features

## What drop-in means here

The replacement does not need to copy Charles implementation details. It does need to preserve the operating contract:

* upstream systems can still trigger contacts and flows
* operators can continue handling inbound customer traffic
* approved templates and send rules remain enforceable
* operational failure handling is at least as strong as the incumbent state
