Support channels
Omnichannel ecommerce support: one customer history instead of separate inboxes
How to connect email, chat, Messenger, SMS, and phone into one support process without losing history, ownership, or order context.
Faboxi product team · 7 min read ·
Short answer
Omnichannel is not merely being present in many channels. It means preserving one customer case, ownership, decision history, and order context when the customer moves from email to phone, SMS, or chat.
Multichannel and omnichannel are not the same
Multichannel means receiving messages in several places. Omnichannel begins when those channels share one customer and case model. A phone operator should see the earlier email, and an SMS reply should stay in the same history.
What must remain shared
- Customer identity and verification.
- Active case, status, and owner.
- Messages, calls, SMS, and internal notes.
- Bound order and current commerce context.
- SLA, priority, and next safe action.
Common mistake: a separate operational world per channel
Separate queues can split one customer intent into several tickets, causing duplicate replies and conflicting promises. Channel should describe the case, not replace its shared ownership.
A gradual implementation plan
- Start with the highest-volume channel and one process.
- Define identity matching and manual correction.
- Add phone and SMS as timeline events.
- Then expand routing, automation, and cross-team SLA.
Decision tools
Identity rules without false certainty
Cross-channel matching needs confidence levels and reversibility. A verified email can be strong evidence; a similar name is only a hint.
| Signal | Decision | Control |
|---|---|---|
| Verified email or authenticated widget | Eligible for automatic matching | Keep verification source and time. |
| Phone matching an order | Match after number normalisation | Check whether the number is shared. |
| Order number plus matching customer fact | Bind to the specific case | The order number alone is not identity proof. |
| Name or textual similarity only | Operator suggestion | No automatic history merge. |
Collision and duplicate control
A shared inbox is safe only when it prevents two parallel customer replies.
| Event | Expected behaviour | Why |
|---|---|---|
| A second operator opens the case | Show presence and who is typing | Reduces duplicate work. |
| A new message arrives while drafting | Pause send and review changes | The draft may be stale. |
| Two tickets represent one intent | Controlled merge with audit | History and ownership stay clear. |
| Incorrect merge | Reversible without losing events | Identity can be a hypothesis. |
Common questions
Must every channel launch at once?
No. Start with the most important channel and process, then add others after identity, routing, and history work reliably.
Can a phone call be part of a ticket?
Yes. The call, outcome, recording, or transcript can be events in the same case when the integration and data policy allow it.
Sources and methodology
- Help Scout collision detection
A documented pattern for presence, paused sends, and reply review.