Summary: If your 10DLC campaign keeps bouncing, the problem is almost certainly the Message Flow field, and specifically that you described your consent process instead of proving it. Reviewers verify; they do not take your word. If you collect consent in two ways, you need evidence for both. Below is the verbatim rejection I received, what it means in plain English, and the single page that fixed it.
What actually happened
I registered an A2P 10DLC campaign for my own business so an AI phone assistant could text callers a booking link. It was rejected four times.
The first three rejections were generic. They told me the campaign did not meet requirements and pointed at documentation I had already read. That is the worst possible feedback, because it is indistinguishable from “try again and hope.” Most people at this point either give up on SMS entirely or start randomly rewording the form, which is what I did.
The fourth response was different. It came from a human reviewer, and it named the problem exactly:
“Consent is collected verbally and via web form. No proof submitted for both. Need to add or share link to verbals script used over call and web form link to verify the opt-in method.”
Read that twice, because it contains the whole lesson. I had described two consent paths. I had proven neither.
The mistake almost everyone makes
The Message Flow field looks like it is asking you to explain your process. It is not. It is asking you to let a stranger verify your process without contacting you.
Those are completely different tasks. “Users opt in via a checkbox on our contact form” is an explanation. A URL where the reviewer can load the page and see the unchecked box with the disclosure text next to it is verification. The first gets rejected. The second does not.
This is why so many rejections feel arbitrary. The applicant believes they answered the question. They did. They just answered the wrong question.
The part that catches people with a phone assistant
If a human or an AI agent ever asks a caller “can I text you that?”, you have a second opt-in path, and it needs its own proof.
A web form is easy to verify because it is already a public URL. A verbal opt-in is not verifiable at all unless you publish the script. There is nothing for a reviewer to look at. No amount of describing it in the form will work, because describing it is exactly what got rejected.
This is the trap for anyone adding an AI receptionist or answering service. You register the campaign thinking about your website form, and the reviewer correctly notices that your own submission mentions a phone conversation.
The fix, in one artifact
I built a single public page that documents both opt-in methods, and linked it in the Message Flow field. That is the whole fix.
What the page contains:
- The web form path. Which URL the form is on, that the consent checkbox is unchecked by default and never pre-selected, that the phone number is discarded if the box is not ticked, and the exact disclosure text shown next to the checkbox.
- The verbal path. What the caller is asked before anything is sent, covering all four required elements: that a text will be sent, that message and data rates may apply, that message frequency varies, and that they can reply STOP at any time.
- What messages are actually sent. Kept narrow and specific rather than a broad marketing description.
- How to opt out. STOP and HELP, stated plainly.
Two details mattered more than I expected.
The consent sentence on the proof page must be character-identical to the one on the form. The reviewer compares them. If your page paraphrases your own checkbox, you have handed them a discrepancy to reject.
Put the evidence inline, not one click away. The reviewer wants the script and the form link in the Message Flow field itself. A link to a page that then links to your proof adds a step, and steps get skipped.
A trap specific to AI voice agents
If your consent is collected by a voice agent, be careful what you claim on the proof page.
Unless the agent's prompt pins the wording exactly, it will paraphrase on every call. My own agent's instructions say to ask “in words close to” the script, which means the caller hears something slightly different each time. That is normal and fine.
What is not fine is publishing a compliance page that claims the agent recites an exact script. That statement would be false, on a page whose entire purpose is to be true. The fix is to claim the required elements, which are genuinely covered on every call, and to label the example wording as typical rather than verbatim.
A page describing behaviour your system does not have is worse than no page at all. It is a false representation to a carrier, and it is discoverable.
Before you resubmit, check these
- Do you have a privacy policy? A public one, that mentions SMS, and states that numbers collected for messaging are not sold or shared for marketing. Many small business sites have none. Registration fails without it, and that failure looks like a Message Flow problem when it is not.
- Does your sample message match your campaign use case? A sample that reads like marketing on a campaign registered for customer care will not survive.
- Is every opt-in path represented? Web form, phone, in person, at point of sale. Every one needs evidence.
- Is the business information consistent? Legal name, EIN and address should match across the brand registration, the campaign, and your website footer.
What I cannot tell you
I am deliberately not publishing approval timelines or rejection rates. Mine took several rounds over a period of weeks, but a single business's experience is not a benchmark, and carrier and registry requirements change often enough that a number written today may be wrong within a quarter. If you see a blog post confidently quoting an industry-wide 10DLC rejection rate, ask where it came from.
What I am confident about is the shape of the problem, because a human reviewer stated it directly: proof, for every path, at a URL they can open.
Why this is worth getting right
The reason A2P registration is worth the aggravation is that the alternative is not “text anyway.” Unregistered traffic on a 10-digit number gets filtered, and filtered means your customer never receives the message while your logs cheerfully report it as sent. Silent failure is the worst outcome available, because you will not go looking for a problem you have no evidence of.
If you want to see the finished artifact rather than rebuild it from a description, mine is public: stephenthorn.com/sms-consent. Copy the structure, not the content. The wording has to describe what your system actually does.