Operating model
A support request needs five visible states
| State | Required evidence | Failure if absent |
|---|---|---|
| received | the correct channel sees the full request | silent loss |
| accepted | one owner becomes visible | duplicate or no reply |
| in progress | specialists can collaborate without confusing the visitor | fragmented context |
| resolved | answer and outcome remain traceable | unclear completion |
| follow-up | a person, time and system own the next action | promise is forgotten |
Choose enough control
Channel chat, collaboration app or contact centre
- WebChat first when departments already work in Teams channels and the thread is the desired surface.
- Chat365 first when documented acceptance, service hours, offline responses, files or meetings are mandatory.
- Social Intents when Teams, Slack or Google Chat must share a collaboration-platform model.
- CentrePal or CoreInteract when voice, queues, supervision, analytics and business-system integration are core requirements.
Operational runbook
Test the normal path and three failure paths
- 01
Normal enquiry
Accept, answer, transfer and resolve a website request from desktop and mobile.
- 02
No owner
Trigger a timed reminder and escalation without exposing internal noise to the visitor.
- 03
Wrong route
Move the request to another team while preserving context and ownership.
- 04
Service unavailable
Capture an offline request, state the response promise and verify follow-up.
Governance boundary
Know when Teams is not enough
A channel provides collaboration, not automatically SLA timers, quality assurance, workforce management or complete cross-channel reporting. Do not infer these controls from a Teams logo.
Document retention, deletion, export, guest access, mobile notifications and any vendor backend. When failure has contractual or safety consequences, assess a governed contact-centre or helpdesk category.