Building a Private SMS Hub for Corporate Use

A corporate SMS hub exists because departments send messages independently and nobody can answer for the result. The hub is not primarily a piece of hardware; it is a single place where sending is governed, attributed and recorded.

This article sets out what a hub has to support, how to consolidate departmental senders without breaking their workflows, how access control and attribution work, and who owns the thing once it is running.

What does a private SMS hub for corporate use have to support?

Several senders, one record, and clear boundaries.

A hub has to let different departments send under their own identity while producing a single accountable record and enforcing rules the organisation has agreed.

Those three requirements conflict unless they are designed together. Departments want their own sender identity and their own schedule; the organisation wants a record that answers who sent what; and compliance wants rules that cannot be bypassed by a team in a hurry. A hub that prioritises any one of the three produces the failure the others were meant to prevent: an uncontrolled shared account, or a governance layer so slow that departments route around it.

The message framework that all senders ultimately use is defined in ETSI TS 123 040, and the reasoning behind a hub is the same one that applies to any shared infrastructure: the cost of coordination is lower than the cost of independent failures. What makes messaging different is that the record is often the only evidence of what an organisation said to a customer.

Requirement	What it means in practice	What breaks without it
Multiple senders	Per-department identity and permission	Departments keep separate accounts
Single record	One log keyed on the sender and the message	No answerable record
Enforceable rules	Checks in the sending path	Policy exists on paper only
Attribution	Every message linked to a department	Disputes become internal arguments

Consolidating departmental senders

Consolidate the infrastructure, not the identity.

Departments should keep the identity their recipients recognise while sharing the estate that carries the traffic.

The practical arrangement separates three layers. The estate — the gateways and subscriptions — is shared, which is where the cost and operational benefit sit. The sending identity is per department, so that a recipient sees a name they know. And the routing and pacing policy is central, so that a busy department cannot consume capacity that another one needs.

Migration is the part that usually fails. A department with a working arrangement will not move voluntarily if the shared platform does not yet do what its own setup does, so the hub has to cover the common cases before migration is proposed. Starting with the departments whose workflows are simplest is the usual approach: proof of the platform in production is more persuasive than a specification, and it produces the operational knowledge the later migrations need.

Access control and per-department attribution

Credentials should identify a department and a person.

Access control works when it answers both questions: which team is sending, and which individual acted.

That requires credentials at two levels rather than one. A department-level credential defines what the team may do, including which identities it may present and which lists it may use. A per-person credential defines who is acting within that department, so that the record can name someone when a message is questioned. Where the platform supports only a single credential type, the practical compromise is per-person credentials with department attributes recorded against each, which preserves attribution at the cost of more credentials to manage.

The controls that make this sustainable are unremarkable. Credentials should be revocable without a site visit, so that a departure is handled in minutes. The list of identities a department may use should be enforced by the platform rather than documented in a policy. And the consent categories a department may send to should be enforced in the same way, because that is the control that prevents a marketing send from a service account. Record-keeping practice for the log that makes attribution meaningful is covered in NIST SP 800-92.

Data residency and retention policy

A hub concentrates data, and that concentration is the point of the policy.

Bringing sending together also brings the recipient data together, so the retention decision applies to a larger store than any department held before.

Two decisions belong at the hub level. The retention window per record type, which should differ between message content and delivery status, because the two have different useful lifetimes. And the residency position, which determines where the store may sit and which parties may process it. Where the processing falls within the European framework, the reference points are the regulation on EUR-Lex and the guidance collected by the European Data Protection Board; other markets have their own framework and their own supervisory expectations.

The engineering contribution is to make the window enforceable. That means an export that runs on a schedule into storage the organisation controls, and a deletion process that reaches backups and export files as well as the live database. A retention policy that exists only as a statement is one that a review will find was never applied, and a hub is the point at which that becomes visible across the whole organisation.

Integration with existing systems

The hub is a service, and services need an interface.

Departments will integrate from CRM platforms, ticketing systems, HR tools and scripts, and the hub has to offer a small number of supported ways to do that.

Three integration patterns cover most needs. A direct API for systems that can call one, with credentials per department. A file or queue-based path for systems that cannot, where the hub accepts a batch and returns outcomes. And a manual interface for the sends that genuinely are manual, such as an office sending a one-off notice. Each pattern should be documented with an example, because an undocumented interface produces a bespoke integration per department, which is the situation the hub was built to end.

The reconciliation interface matters as much as the sending interface. Every consumer should be able to ask what happened to the messages it submitted, keyed on its own identifiers, so that a department can answer its own questions without a request to the platform team. Where the hub supports that, the operational load stays distributed; where it does not, the platform team becomes a help desk.

Who owns and operates the hub?

One owner, and a service description.

A hub with several stakeholders and no owner becomes a shared resource that nobody maintains, which is how most internal platforms fail.

The ownership question has three parts. Who operates the platform day to day, which is usually an IT or infrastructure function. Who sets the policy that the platform enforces, which is a combination of compliance and the departments themselves. And who is accountable for the record, which should be a single named function rather than a committee. Writing those three down takes an hour and prevents the most common failure of internal platforms, which is an outage with no one to escalate to.

The service description is the other artefact worth producing. It should state what the hub does, what it does not do, the integration options, the response expectations and the escalation path. A department that knows the boundaries is a department that does not build a shadow system the first time a request falls outside them.

Two governance details are worth settling at the same time. The first is who may add a new sending identity, since every identity is a thing recipients can recognise or distrust, and the decision has more in common with brand governance than with infrastructure. The second is how a complaint is handled: which function receives it, what they are permitted to do with the record, and in what timeframe. Access-control objectives that structure both are organised in NIST SP 800-53 Rev. 5.

A third detail is the review cycle. Consent categories, retention windows and permitted identities all change as the organisation changes, and a hub with no review date accumulates settings whose reasons have been forgotten. Assigning an owner to the review is the cheapest governance control available, and it is the one that prevents the hub from becoming a legacy platform within three years.

An architecture outline

The outline describes the shared layers a hub has to provide and the decisions that belong to each department. It is written so that the parts which must be central and the parts which may stay local are separated from the start, because retrofitting that boundary later is what makes a consolidation project expensive.

1. Define the shared estate and the per-department identities it may present.
2. Set credentials at department and person level, with revocation that does not need a site visit.
3. Enforce permitted identities and consent categories in the platform rather than in a policy document.
4. Choose the two or three supported integration patterns and document each with an example.
5. Expose a reconciliation interface keyed on the consumer’s identifiers.
6. Decide the retention window per record type and the residency position at hub level.
7. Name the operator, the policy owner and the accountable function for the record.
8. Publish a service description that states the boundaries and the escalation path.

The outline produces a platform with boundaries rather than a shared account with conventions. The difference shows up the first time a department wants to do something the hub does not support, which is when a platform with clear boundaries keeps the work inside it and a platform without them loses it.

{
“@context”: “https://schema.org”,
“@type”: “FAQPage”,
“mainEntity”: [
{
“@type”: “Question”,
“name”: “What is replacing SMS for corporate communication?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Nothing has replaced it; the channel mix has broadened. Application messaging covers conversations and rich content, while short messages remain the reliable channel for verification and time-critical notification because it needs no application and no data session. Most organisations run several channels rather than replacing one. Record which channel carries which message type, because the classification is what determines the record and the consent basis.”
}
},
{
“@type”: “Question”,
“name”: “Is there a free way for a company to send messages?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Free paths exist and are unsuitable for corporate use, because they offer no delivery commitment, no per-message record and no commercial relationship behind the route. A hub exists precisely to produce the record, and a free service cannot supply it. Where a free path is used for internal testing only, say so explicitly, because the distinction between test and production is what a review will check.”
}
},
{
“@type”: “Question”,
“name”: “How can a company send a thousand messages at once?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Through a platform that paces the send and returns per-message outcomes, rather than by submitting a thousand requests at once. The rate the network accepts is the constraint, and the hub’s job is to pace to it and to record what happened, which a burst submission cannot do. Record the pacing policy with the platform configuration, and review it when a subscription or an operator changes.”
}
},
{
“@type”: “Question”,
“name”: “Should each department keep its own sender identity?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Yes, where recipients recognise it. Consolidation applies to the estate and the record rather than to the identity, so a department keeps the name its recipients know while sharing the infrastructure that carries the traffic. The platform should enforce which identities each department may use. Keep the identity list under the platform control rather than in department documentation, because the platform is what enforces it.”
}
}
]
}