Skip to main content

​
Like-for-like Functionality

This page is the docs-app view of the fuller parity matrix in 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