Omnikom Suite
HomeProduct overviewPricingCompare hubAboutBook a demoBlog/resources indexHelp center / docs index

Version b1beecb9 - first version

SMS and A2P Disclosure

This document describes how text messaging works on the platform: what consent we require you to

have, how opt-out is handled, what registration with the carriers involves, and what happens when a

carrier filters a message. It is part of the Terms of Service. It is a draft prepared by the build

and is subject to review and acceptance by the owner and their counsel; the version hash on the page

identifies exactly which text you are reading.

1. Consent

Before a text message is sent to a person from your workspace, you must hold that person's consent

to receive it, of the kind the message requires:

  • Conversational or transactional - a reply to something they initiated, an appointment

reminder, a delivery notice. Consent is established by the relationship and the record of it.

  • Marketing or promotional - express written consent, captured before the message is sent, with

a clear description of what they were agreeing to receive and from whom.

The platform stores a consent record against the contact: what was agreed, when, through what

channel, and the text of the disclosure shown at the time. That record is what the outbound gate

reads. A contact with no consent record does not receive a marketing message, and the send is

refused rather than queued.

2. What your opt-in language must say

Whatever form, keyword or checkbox you use to collect consent must state, in language the person

actually sees before they agree:

  • The name of the business that will be sending.
  • What kind of messages will be sent, and roughly how often.
  • That message and data rates may apply.
  • How to stop, and how to get help.
  • Where your privacy policy and terms can be read.

Consent to receive messages may not be a condition of buying something, unless the messages are

what was bought.

3. Opt-out and help

The platform honours the standard stop keywords on every inbound message, in every workspace,

without configuration. When a stop keyword arrives, the contact is marked opted out immediately, a

single confirmation is sent, and subsequent marketing sends to that contact are refused by the gate.

Help keywords return your business name and a contact route.

An opt-out cannot be reversed by you. It is reversed only by the contact opting in again, and the

new consent record is what the gate reads from then on.

4. Registration with the carriers

Application-to-person text traffic in several countries must be registered before carriers will

deliver it reliably. Registration associates a brand and a campaign - a description of what you send

and to whom - with the numbers you send from. The platform supports filing that registration and

tracks its state.

Until a registration is approved, sending is limited. The platform makes the state of your

registration visible rather than letting you discover it from missing replies.

What you file must describe what you actually send. A registration that understates volume, or

describes a use case other than the real one, is a misstatement to the carrier and puts every sender

behind the same registration at risk of filtering.

5. Carrier filtering, and why a send that succeeded is not a message that arrived

This is the disclosure that matters most, because it is the one whose absence causes the worst

outcome.

When you send a message, the carrier's API returns a result that says only that the carrier

accepted the request. It does not say the message was delivered. A carrier may accept a message

and then silently drop it - most commonly when the traffic is unregistered, when the content matches

a filtering rule, or when the sending number's reputation is poor. In that case there is no error

anywhere: the send returned success, your automation advances, the logs look healthy, and the

message never reaches a human.

The platform treats accepted and delivered as different states, and only an inbound delivery

receipt from the carrier moves a message to delivered. Any automation step that depends on a message

having arrived reads the delivery state, never the send response. Where the ratio of accepted to

delivered departs from what it should be, the platform raises that as a condition to be looked at

rather than leaving it to be noticed.

We do not control carrier filtering decisions and cannot promise delivery of any particular message.

6. Quiet hours and frequency

You are responsible for the time-of-day rules that apply where your recipient is, not where you are.

The platform records a contact's time zone where it can determine one and can hold a send until a

permitted window. Frequency is your decision; a recipient's tolerance for it is not.

7. Recording what happened

For every outbound message the platform retains the consent record it was sent under, the send

result, and every delivery receipt received. That record is what lets you answer a complaint with

evidence rather than recollection.

8. Changes

When this disclosure changes, the previous text stays available at its own address and the version

hash on the page changes.

Omnikom Suite

  • Home
  • Pricing
  • About
  • Contact
  • Book a demo
  • Status page
  • Changelog
  • Affiliate/partner program
  • Security and tenant isolation

Product

  • Product overview
  • Contacts and pipelines
  • Unified inbox
  • Automation builder
  • Booking and calendars
  • Campaigns
  • Reporting and analytics
  • Compliance and A2P
  • White-label

Industries

  • Real estate niche landing
  • Dental niche landing
  • Legal niche landing
  • Med spa niche landing
  • Solar niche landing
  • Home services niche landing
  • Chiropractic niche landing
  • Fitness niche landing
  • Cleaning/lawn niche landing
  • Coaching niche landing
  • B2B services niche landing
  • Agency niche landing
  • Other industries landing

Compare

  • Compare hub
  • Compare vs Orion AI
  • Compare vs GoHighLevel-based agencies
  • Compare vs generic CRM/marketing tools

Blog

  • Blog/resources index

Help

  • Help center / docs index

Legal

  • Terms of Service
  • Privacy Policy
  • Data Processing Agreement
  • Acceptable Use Policy
  • SMS/A2P disclosure

We use strictly necessary cookies to run this site. With your agreement we also load analytics, which tells us which pages are worth writing more of. Nothing beyond the necessary ones loads until you choose.

Either choice is remembered for this browser. What we collect and why is in the Privacy Policy.