Support over iMessage works. The thread persists, so context is never lost. Photos arrive at full quality, which matters enormously when the customer is showing you a broken part. Read receipts remove the "did you get my message" exchange. And nobody has to install anything.
It also sets an expectation. A message in the same app as their family gets an implicit SLA of minutes, and a channel that does not meet it is worse than not offering the channel.
Two routes
| Apple Messages for Business | Third-party API | |
|---|---|---|
| Apple sanctioned | Yes | No |
| Who starts the conversation | Customer, always | Either |
| Entry points | Maps, Safari, Search, your app | A phone number you share |
| Rich features | Pickers, forms, Apple Pay | Text, media, reactions |
| Setup | Weeks, via an approved CSP | An hour |
| Cost | Through a CSP contract | From ~$20–$200/month |
If support is inbound-only and you are large enough to work through an approved provider, Apple's programme is the better product — richer, sanctioned, and discoverable from Maps and Search, which is a genuine acquisition channel. The full guide.
If you need to message a customer first — an outage, a delayed order, a follow-up on a case — Apple's programme cannot do it and a third-party provider is the only route. Compared here.
Staffing is the hard part
Everything else is configuration. Decide these before you publish the number anywhere:
- Hours. Publish them, and honour them. "We reply 8am–6pm weekdays" is fine; silence at 9pm after a same-day reply at noon is not.
- Target first response. Under fifteen minutes in hours, or the channel underdelivers on its own promise.
- Who is on it. A named rota, not "whoever sees it". The staffing question.
- Escalation. What moves to a phone call, and how fast.
- Out of hours. An auto-reply with a real time commitment, and something that catches genuine emergencies.
The auto-reply that works
"Thanks — we've got this. Someone will reply by 9am. If it's urgent, call 555-0142." Specific time, real alternative. Not "we value your message", which reads as a machine and reduces trust in every subsequent message from the number.
What to automate, and what not to
- Automate acknowledgement. Instant, honest, once.
- Automate status lookups. "Where's my order" answered from your own data is the highest-value automation on this channel.
- Automate triage. Route by keyword before a human opens it.
- Never automate an apology. A machine saying sorry reads worse than nothing.
- Never automate a resolution to a complaint. What to do instead.
- Cap the bot. Two exchanges, then a person, and say so. Agent guidelines.
The features that matter here
| Feature | Why support specifically |
|---|---|
| Inbound webhooks | A reply must create a ticket within seconds |
| Rich media | Full-quality photos of the actual problem |
| Typing indicators | The customer knows someone is there |
| Read receipts | Removes the "did you see this" exchange |
| Shared inbox | Support staff should not need an API client — Miss Blue is built around one |
| Reactions | A tapback closes a thread without another message |
Threads persist, and that cuts both ways
Everything you have ever sent this customer is visible above your latest message, forever. A marketing blast three weeks ago sits directly above today's apology about a botched delivery, and the customer reads them together.
That is a strong argument for separating support and marketing numbers, and an even stronger one for not sending anything on this channel you would not want read back in a bad moment. The one-number-or-many decision.
Measure it as support, not as marketing
- Median first response, in hours and out.
- Resolution rate without escalating to phone or email.
- Messages per resolution. Rising means your answers are unclear.
- Share of contacts choosing this channel over phone and email — the honest measure of whether customers want it.
- Reopen rate. A thread that never really closed is a resolution that never really happened.