How do Apple Messages conversations route into an existing inbox?

Every team evaluating this channel asks the same operational question: do we answer these messages somewhere new, or do they arrive where our agents already work? The answer depends almost entirely on your provider, and Apple's documentation is what tells you which parts are fixed.

What does Apple hand you, and what do you route on?

Apple delivers the conversation to the messaging platform your Business ID is connected to, carrying the parameters the entry point set. Those are the intent and group values on the Messages URL or the native entry point the customer used, which means a conversation can arrive already labelled with where it came from and what it is about. How customers reach a business from Maps, Safari and Spotlight covers where those values are set.

Apple treats acting on them as a condition of connecting brands at all. Its required-features list, introduced with "Apple requires that you build and demonstrate support for the following features for approval to connect brands to Messages for Business", includes "Routing based on entrypoint parameters" as Required on both the bot and the agent-triggered path. Apple's platform requirements for a provider say the same thing from the other side, asking for a "Messaging platform that supports asynchronous conversations and intent-based routing".

So routing exists on every approved provider. What varies is the shape of the rules, and whether they end at a queue or at a system you already run.

Where does routing actually happen?

In the provider's platform, not in Apple's. This is the structural fact that decides your implementation: Apple has no rules engine, no queues, no agent records and no skill-based assignment. It has a channel and a set of parameters.

Practically, three layers sit between the customer's message and an agent, and all three belong to the provider or to you:

1. Classification. The intent and group from the entry point, plus anything an automation infers from the first message.
2. Assignment. Which team or queue the conversation lands in, and how an agent takes it.
3. Context. What the agent sees beside the thread, which is where your order system or CRM comes in.

Can conversations land in the helpdesk we already use?

Often, and it is a provider question rather than an Apple one. Apple's description of what an MSP does includes "custom integration with your back-end business systems, such as CRM, order management, authentication, etc.", and Apple's provider requirements ask for a "Customer success team to build custom integrations into brand back-end systems".

Two shapes exist in practice. Some providers are the console: your agents work in their interface, and integration means pushing conversation records and customer context between systems. Others connect the channel into a helpdesk you already own, so Apple conversations queue beside your email and chat. Providers describing the second shape on their own pages include Zendesk, whose help centre says "As a Messaging Service Provider, Zendesk is certified by Apple to provide services and solutions for your Apple Messages for Business needs" and routes the channel through Sunshine Conversations into its Agent Workspace, and Salesforce, whose 2023 newsroom announcement says "Agents can efficiently manage these conversations in Service Cloud and access customer data for fast resolution."

Ask a provider which of those two shapes you would be buying, because it decides where your agents spend their day and what your reporting joins on.

How does a bot hand off to a person?

Through the provider, and Apple requires the capability to exist. Apple's provider requirements include "Virtual assistant, or bot, flows to triage incoming conversations and hand off to live agents", and Apple's policies make the human end non-negotiable: "The business must provide access to a live agent in this channel during its regular business hours", and "A business must not provide a limited or bot-only solution."

Two details matter when you design the handoff. Apple's Experience Review checks for "automated agent disclosure", so a bot that answers without saying it is automated is a review failure rather than a style choice. And because the conversation is one continuous thread on the customer's device, a handoff is a change of who is answering rather than a transfer to a new channel: the customer sees no break, so anything your agent asks that the bot already asked reads as your systems not talking to each other.

What breaks if routing is an afterthought?

Three things, in the order teams hit them.

Everything lands in one queue. Entry points without distinct intents cannot be routed or measured, and retrofitting them means editing every published link, button and QR code.

Nobody can prove which entry point works. Apple's own reason for setting intents covers the case where you route nothing at all: "Even if you don't use routing immediately, Intent IDs let you understand where conversations are coming from and which entry points are most effective." Without them, the channel produces conversations and no attribution.

Out-of-hours arrivals sit unanswered. The channel is asynchronous and customers open threads at any hour, so the routing plan needs an answer for the hours your agents are not there, alongside the business-hours coverage Apple requires.

Every Apple requirement on this page comes from Apple's own documentation, read on 4 September 2026: Messages for Business REST API required features, MSP onboarding, Messages for Business accounts, Message with your customer, Appendix A: Policies and Pass the Experience Review. Each provider claim is sourced to that provider's own documentation, read the same day.