Receiving Messages

Receiving and Routing Messages

Inbound messaging receives replies and unprompted messages and processes them with configurable actions — the same shape e-mail inboxes already use, so if you have configured one you know this.

Where to find it

Architect Panel → Communication:

• Inbound Messaging — the console — rules and actions applied to what arrives
• Received Messages — what has come in, and what happened to it

You need a real number

An alphanumeric sender ID cannot receive. If replies matter, provision a number that can.

Rules and actions

Rules decide which messages get which treatment, matching on the sender, the content, or the number it arrived at. Actions decide what happens: file against a record, create one, notify somebody, run a workflow.

Match on the number it arrived at wherever you can. Using a distinct number per service is the most reliable routing available and far more robust than parsing message text — people do not write what you expect.

Matching to a record

Inbound messages are matched to records by phone number, which is why a number index exists. Numbers arrive in inconsistent formats — with and without country codes, with spaces, brackets and leading zeros — so normalisation matters.

The Phone Number Index Rebuild task keeps that index current. It ships disabled and runs daily. If inbound messages stop matching records after a bulk import, this is the first thing to check.

The three tasks

• Inbound Message Drain — processes what has arrived. Every minute.
• Inbound Message Poll (GOV.UK Notify) — fetches from providers that do not push to you. Every five minutes.
• Phone Number Index Rebuild — keeps number matching working. Daily.

All ship disabled under Automation → Tasks.

Unmatched messages

Decide what happens to a message from a number you do not recognise, and decide it before you go live.

Discarding silently is the worst option: somebody replied to you and nobody read it. Route unmatched messages to a queue a person actually looks at, and check that queue is genuinely owned rather than nominally owned.

Worked example

A council uses one number for bin collection alerts and another for council tax. Rules route by receiving number, so a reply to a bin alert never lands in a council tax queue. Unmatched messages — someone texting from a number not on the record — go to a customer services queue, where they are matched by hand and the number added.

Recommendations

• One number per service where you can afford it. It is the cheapest routing you will ever configure.
• Own the unmatched queue explicitly. Name a team, not "customer services generally".
• Rebuild the number index after bulk imports.
• Test with a real handset, including a reply, before going live.

Two-Way Conversations

Once inbound is configured, messaging becomes a conversation rather than a broadcast — which changes what you need to think about.

Where to find it

Architect Panel → Communication:

• Received Messages — the inbound half of the thread
• Message Log — the outbound half

Architect Panel → Activity:

• Correspondence — where the thread appears alongside email and letters

Keep the thread on the record

Both directions should file against the same record so the exchange reads as a conversation. A case where outbound messages are on the file and replies are in a separate list is a case nobody can follow, and it will be followed by somebody who was not part of the exchange.

Somebody must be listening

The commonest failure of two-way messaging is organisational rather than technical: replies arrive and nobody is responsible for reading them.

Decide who owns the queue and how quickly they respond before you invite anyone to reply. A channel you opened and do not monitor is worse than one you never opened, because people reasonably assume they have been heard.

The WhatsApp session window

WhatsApp allows free-form replies only within a window following the user's last message. Outside it, you must use an approved template.

A conversation that stalls because the window closed looks to the user like being ignored. Design flows that keep exchanges inside the window where possible, and fall back to a template gracefully rather than silently failing to reply.

Set expectations in the message

Tell people what the number is for and when it is monitored. "This number is not monitored — call 0300 123 4567" is honest and useful. Silence is neither, and somebody in difficulty will message it anyway.

Safeguarding and crisis messages

Where the people you message may be vulnerable, an inbound channel will eventually receive a disclosure or a crisis message. Not might — will.

Have the route decided in advance. A rule that flags certain content for immediate human attention is worth configuring before you need it, and the team that would receive that flag should know it is coming. This is the single most important thing to plan when opening a messaging channel in social care, housing or health.

Worked example

A youth service opens a text channel for appointment changes. Rules flag messages containing a small set of risk indicators to a supervisor queue with an alert, regardless of what else the rule set would have done with them. The team agreed the indicator list with their safeguarding lead before the channel opened, and reviews it quarterly.

Recommendations

• Agree the safeguarding route before opening the channel.
• State the monitoring hours in outbound messages.
• Keep both directions on one record.
• Review unanswered inbound messages weekly — that number should be zero.