How a message flows

Everything in Tied is one path repeated. Understanding it once explains routing, handoff, analytics and your invoice all at the same time.

​

1. The message arrives on a channel

A customer sends something — an iMessage to your Apple Messages business account, a text to your 10DLC number, a WhatsApp message, a web chat. The channel determines what the message can contain, what it costs to deliver, and what rich surfaces are available in reply. What Tied does here is normalise. By the time the message reaches the next step, an Apple List Picker response and a WhatsApp button tap look structurally the same to everything downstream.

​

2. It lands in an inbox

The channel is the transport; the inbox is the configured surface with a team, business hours, an assignment policy and possibly an AI agent attached. The same channel type can back several inboxes — support and sales on separate numbers — and they can behave completely differently. The contact is resolved here too. If this person has messaged you before on any channel, this conversation joins their history rather than starting a new identity. A customer’s closing courtesy on a resolved or snoozed conversation is not a new request. A message counts as a goodbye only when all of these hold:

• The whole message, ignoring case, spacing and one trailing period or exclamation mark, is on a short English list: thanks, thank you, thx, ty, ok thanks, ok, okay, got it, great, perfect, sounds good or will do, or it is one of four emoji (thumbs up, folded hands, or a smiling face). Anything else, including yes, no, sure, another language or one extra word, is not a goodbye.
• It has no question mark, digit, link, attachment, button tap or structured input.
• The last public message we sent (outgoing or template) was plain text and did not ask a question, request information or make an offer. Wording that asks, requests or offers (for example please, let us know, whether, what, which, if you, or an instruction to select, upload or confirm something) is treated as one of those, deliberately broadly. On a resolved conversation a promise of pending work (I'll check, give me a moment) also counts against a goodbye; on a snoozed conversation it is ignored, because the conversation stays snoozed and the work carries on. The plain text All done is always a safe thing to answer.
• If the customer replied to one particular message, that message must be the last one we sent. Replying to an older message reopens.
• For email, the mail must carry only the customer’s new text and a saved reply target that resolves to the last message we sent. The mailbox saves that target only when the mail names exactly one message, so a mail naming several, or none, reopens.

When unsure, the conversation reopens. A goodbye leaves a resolved conversation resolved and a snoozed conversation snoozed, does not start a wait for a reply, and is logged as a suppressed reopen with its category (never the text). It is not a resolution confirmation, and it does not start or advance a bot flow (the message event is still published to every other consumer). Private messages and messages in other conversations do not affect the context. In an inbox with an active bot, any message that does reopen the conversation returns it to pending.

​

3. Routing decides who gets it

Assignment policies run: round-robin, load-balanced, team-based, or straight to an AI agent. Business hours matter here — out-of-hours behaviour is an inbox setting, not a global one. See Assignment policies.

​

4. An agent picks it up

If an AI agent is attached, it reads the conversation and decides what to do. Three broad outcomes: What the agent is allowed to do is set by your plan’s tool scope, applied at the point of action. If a system isn’t connected, or is connected read-only, the attempt never happens. See Plans.

​

5. Or it hands off to a human

When the agent can’t finish, it escalates — leaving a summary so the human starts informed rather than cold.

​

6. Every action is recorded

Each read and write goes into a signed, immutable action audit trail — which system, what operation, and whether it succeeded. This is the part that makes everything downstream trustworthy. The resolution class on your invoice is derived from this trail by mechanical predicate, not asserted by a model or a human. If the trail shows no successful monetary write, you cannot be billed write_financial regardless of what anyone thinks happened.

​

7. The outcome is classified — or isn’t

Most conversations end without producing a billable resolution, and that is the normal case. A resolution is recorded only when a positive signal says the problem is gone: the customer confirmed it, one of your systems proved it, or they went quiet with a corroborator. Ambiguity resolves to unbilled.

​

8. And it can be un-classified later

A billed resolution is not final. If the same issue reopens within 30 days, or the customer ever leaves negative feedback on it, the resolution is voided and credited — automatically, with no claim required.

​

Where to go next