Let UK customers text you back

An alphanumeric sender ID like "ACME LTD" is a label, not a destination. The recipient can read it, cannot address a reply to it, and the network has nowhere to route the answer. For one-way traffic that is fine: a one-time code does not need a response. The moment you want the recipient to confirm, ask or react, you need a number they can text.

That number is the UK two-way pattern: a reply-capable virtual or dedicated UK number that appears to the recipient as a normal mobile number. It is provisioned for inbound and two-way messaging, which means the network knows to route replies back to us, and we route them back to you. WorldText offers UK and international long numbers in this category, documented on the virtual numbers service page. The honest trade-off is that a number is less recognisable than a brand name, which is why many UK organisations run both: alphanumeric for broadcast-style service messages, a number for anything conversational. Our UK SMS compliance page covers the sender-ID rules that make that pairing legal.

Receiving a reply is only half the job; the other half is getting it somewhere useful. WorldText delivers inbound messages over HTTP webhook, SMPP or email, which means the reply can land in your CRM, ticketing system, dispatch queue or monitoring console rather than an inbox nobody checks. The webhook route supports the same callback discipline as delivery receipts, including handling duplicate callbacks by message ID, because real mobile networks do not guarantee once-only delivery.

For the replies that do not need a person, the auto-responder can answer on your behalf: confirming a delivery slot, offering a menu of options or telling the customer where their case is. The two-way SMS service page covers the service end to end, and the inbound SMS page covers receiving-only options, including SIM hosting and short codes.

Delivery of inbound messages follows the same discipline as outbound: idempotent handling by message ID, with states and error codes documented on the message state reference. Treat the reply as data entering a workflow, not as a notification about a person.

Two-way traffic is justified by the workflow, not by novelty. Appointment confirmations are the classic UK example: send the reminder, the customer replies to confirm or reschedule, and the calendar updates without a phone call. Support conversations benefit too, because a text thread is asynchronous and does not require the customer to sit on hold while a case number is read out. Delivery communications let a customer redirect a parcel or choose a safe place from the message itself, which is a genuine drop in failed deliveries, and staff comms use the same mechanics internally: confirm, respond and acknowledge without emailing everyone.

Message design matters more than infrastructure here. Short, single-question replies work; open-ended questions produce answers nobody can parse. Keep the interactive portion to one clear ask, and route anything unpredictable to a person rather than an automated happy path.

It also helps to decide what happens when no reply comes: a reminder after a sensible interval, a fallback to email or a call, and a record of the attempt. Two-way means the conversation can start, not that it always will, and the fallback is part of the design rather than an afterthought.

The number type should follow the traffic volume and the recognition you need. A UK virtual or dedicated long number suits day-to-day two-way conversations: it looks like a normal mobile number and can carry both inbound and outbound messaging. A short code is a different tool entirely: Ofcom-allocated, typically 5-6 digits in the 7000 series, with several ranges such as 80xxx, 84xxx, 86xxx and 87xxx still in use (check with us for current allocations). Short codes are harder to misread and are associated with high-volume campaigns, but they are a more expensive and more formal commitment than a long number. The short codes service page explains the options.

If the point of the number is receiving rather than conversational traffic, SIM hosting is an alternative route: messages to an ordinary SIM are forwarded over API, webhook or email. The inbound SMS page compares the approaches honestly.

Whatever you choose, provision it before you need it. A number becomes part of your public contact details, and recipients do not appreciate discovering that the number on yesterday's message was never available to be answered.

A two-way UK deployment is an API integration with a number attached, not a separate product. Your application submits the outbound message through the HTTP API guide with the reply-capable number as sender, and receives the reply on the same connection or a configured callback. Delivery states and error codes are documented on the message state and error reference, so retries and conversation matching are implemented against documented behaviour rather than guesswork. The UK SMS API page covers the developer-facing contract in one place.

Session state matters here. The reply has to be associated with the conversation that produced it, so store the number alongside the message ID rather than relying on content matching. UK receipts and the message states reference give you the mapping to do that properly, and the two-way service page covers the operational side, including number lifecycle and what happens when a number is retired. Conversations are a workflow problem, not a developer trick, and treating them as one is what keeps the experience coherent for the customer.