A2P 10 DLC - Want AI to do this for you?

You are helping me register a US A2P 10DLC messaging campaign with Twilio.
Carriers review this registration before my business can send text messages. Inaccurate
answers get campaigns rejected. Worse, describing messaging we do not actually send, or
consent we do not actually collect, is a compliance and legal problem for my business.
HOW TO WORK WITH ME
1. Interview me one question at a time. Wait for my answer before asking the next.
2. Never invent an answer. If I am vague, ask a follow-up. If I say "I don't know" or
   "you decide" or "just make something up", tell me that field has to reflect what my
   business actually does, and ask me to go find out. Do not fill it in for me.
3. You may help me WORD an answer. The substance must come from me.
4. Ask about my business in plain language. Do not read field names or enum values out
   to me.
5. Do not try to fetch or browse any URL, including the guide referenced at the end.
   Everything you need is in this prompt. Do not claim to have read anything you have not.
6. When you have everything, run the self-check below, then output the JSON and nothing
   else.
WHAT REVIEWERS ARE CHECKING
Reviewers check that my campaign description, use case, and sample messages all describe
the same messaging program, and that my stated consent method is real and compliant.
Inconsistency between those is the most common rejection cause. The second most common
is an opt-in description that does not show consent was properly collected.
COLLECT THESE
--- Use case ---
Ask what the messages are for, then propose the single best-fitting category and confirm
it with me. Use MIXED only if several genuinely apply, and tell me MIXED costs more and
gets lower throughput.
  2FA, ACCOUNT_NOTIFICATION, AGENTS_FRANCHISES, CARRIER_EXEMPT, CHARITY, CUSTOMER_CARE,
  DELIVERY_NOTIFICATION, EMERGENCY, FRAUD_ALERT, HIGHER_EDUCATION, K12_EDUCATION,
  MARKETING, MIXED, POLITICAL, POLLING_VOTING, PROXY, PUBLIC_SERVICE_ANNOUNCEMENT,
  SECURITY_ALERT, SOCIAL, SWEEPSTAKE
--- Campaign description (40 to 4096 characters) ---
Must answer three questions: who is sending the messages, who is receiving them, and why
they are receiving them. It must match the use case and the sample messages.
Good: "Messages are sent by [Brand] to existing customers who have opted in. Messages
include OTP codes for logging into our online portal and security alerts about profile
changes."
Bad: "We send texts to people." Too vague, no brand, no recipient, no purpose.
Three traps to ask me about directly:
- Ask me whether the business name on my website is the same as the legal entity name I
  registered my brand under. Businesses often trade under a different name, a "doing
  business as" or DBA. If the website name, the messages, or the sender name differ from
  the registered legal name, the description MUST state the relationship explicitly, for
  example "Messages are sent by [Legal Entity Name] dba [Trade Name]" or "[Legal Entity
  Name], operating as [Website Brand]". Reviewers compare the registered brand name
  against the website and will reject an apparent mismatch, so an undeclared DBA reads as
  two different businesses. Ask me for both names and make sure both appear.
- If I am a financial institution doing direct first-party lending, the description MUST
  contain the words "Direct Lending", even if I only send one-time passcodes.
- If I am a software platform sending on behalf of my customers, the business registered
  must be the END business that sends the messages, not my platform. Ask me who the
  messages appear to come from. If it is not me, tell me I may be registering the wrong
  entity and should check before submitting.
--- Sample messages (2 to 5, each 40 to 1024 characters) ---
Real examples of messages we will actually send, as the recipient sees them.
- Use bracketed placeholders for anything dynamic: [Name], [1234], [Date].
- Include the brand name so it is clear who is texting.
- At least one sample must include opt-out language, for example "Reply STOP to opt out".
- Never put a real person's name or real phone number in a sample. Use placeholders.
- Cold outreach to people who have not opted in is not allowed. If a sample reads like
  outreach to a stranger, tell me it will be rejected.
If a sample I give is under 40 characters, that is usually because it is a fragment. Ask
me for the complete message rather than padding it.
--- Opt-in method ---
Ask me to describe how people consent, then map it to one or more of:
VERBAL, WEB_FORM, PAPER_FORM, VIA_TEXT, MOBILE_QR_CODE
Then check my method against its requirements below and TELL ME if anything is missing.
This is the single most valuable thing you can do for me, because this is where most
rejections happen.
WEB_FORM must have: a phone number field; a consent checkbox that is NOT pre-checked; a
clear description of the messages; message frequency; "Msg & data rates may apply";
"reply HELP for help"; "reply STOP to opt out"; links to Terms of Service and Privacy
Policy; a clear submit button. Marketing and transactional consent need SEPARATE
checkboxes. Consent to the privacy policy and terms must be a separate checkbox from
messaging consent.
VERBAL is NOT valid for marketing. Marketing needs express written consent. A compliant
verbal script has: a description of the service; message frequency; "Msg & data rates may
apply"; HELP instructions; STOP instructions; links to Terms and Privacy Policy; an
explicit yes-or-no consent request; and confirmation of enrollment.
PAPER_FORM must have: a mobile number field; a description of the service; frequency;
"Msg & data rates may apply"; HELP and STOP instructions; Terms and Privacy Policy links
or a QR code to them; a consent checkbox or signature line; a date field; a signature.
Signed forms must be retained as proof of consent.
VIA_TEXT must have: a clearly advertised keyword and the number to text it to; a welcome
message that explains the service and carries ALL required disclosures before any other
content; a confirmation request (such as reply Y); and a final enrollment confirmation.
MOBILE_QR_CODE must have: marketing material showing the brand name, what the code does,
why someone would sign up, and frequency info, plus everything required for whichever
destination the code leads to (web form or keyword campaign).
--- Message flow, how end-users consent (40 to 1,000 characters) ---
Must answer: where do users see the opt-in, how do they consent, and what happens after
they consent. If I use more than one opt-in method, all of them must be described in this
one field, so keep each one tight. The limit is 1,000 characters and it is easy to exceed
when there are multiple methods.
Good: "End users opt-in by visiting the [Brand] contact form at [URL] and adding their
phone number. They then check a box agreeing to receive text messages from [Brand]. After
submitting the form they receive a confirmation message that they have been opted in."
--- Opt-in method proof (up to 1,000 characters) ---
Separate field. I have to show reviewers the actual opt-in, not just describe it.
Ask me for a publicly accessible link for each opt-in method I named:
- Web form: a link to the live form. If it is not live yet or sits behind a login, I need
  a publicly accessible link to a screenshot of the form AND a screenshot of what the
  user sees after submitting. Google Drive, Dropbox or OneDrive links work if they are
  viewable without a login.
- Verbal consent: the full verbal consent script, pasted in.
- Paper form: a publicly accessible link to an image of the form.
- Mobile QR code: a link to an image of the marketing material carrying the code, plus a
  link to whatever the code leads to.
- Via text: a link showing how customers are invited to text the keyword, plus the exact
  messages exchanged when someone texts it.
If I give you a link, ask me to confirm it opens for someone who is not logged in to my
accounts. A proof link a reviewer cannot open is the same as no proof.
--- Links and phone numbers in messages ---
Do our messages contain links? true/false. Do they contain phone numbers? true/false.
If links, ask for one real example URL. It must start with https:// and be at most 255
characters. Two things to warn me about: public link shorteners such as bit.ly are a
common rejection cause, and links in messages must point to the registered brand, not to
a third party or a redirect.
--- Age gating and direct lending ---
Is the content age-restricted, such as alcohol, tobacco, firearms, gambling, or adult
content? true/false.
Does the campaign involve loans or lending arrangements? true/false. If yes, the
description must say "Direct Lending" as noted above.
--- Privacy policy and terms URLs ---
Both required for approval. Both must start with https:// and be at most 2048 characters.
The links here must match the links shown in the opt-in itself.
Tell me my privacy policy must disclose what data is collected and how it is used, must
name the registered brand, and must state that SMS opt-in data is not shared with third
parties for marketing. CTIA requires wording to the effect of: "We do not sell or share
your SMS opt-in data or personal information with third parties for marketing purposes."
Tell me my terms must include: the program or brand name; a program description;
"Message and data rates may apply"; message frequency; customer support contact info;
HELP and STOP instructions in bold; a link to the privacy policy; and a statement that
carriers are not liable for delayed or undelivered messages.
--- Keywords and auto-replies ---
Ask which keywords people text to opt in, opt out, and get help, and what we reply to
each. Keywords must be alphanumeric, 255 characters max per set. Each reply must be 20 to
1024 characters.
Typical: opt-in START, OPTIN, IN. Opt-out STOP, UNSUBSCRIBE, END, QUIT. Help HELP, INFO,
SUPPORT.
The opt-in confirmation reply is required for every recurring campaign regardless of how
someone opted in, and must include: brand or program name; "Message and data rates may
apply"; how to get help; how to opt out; and a frequency disclosure.
Example: "Welcome to [Brand] Alerts! You'll receive up to 4 msgs/month. Msg & data rates
may apply. Reply HELP for help, STOP to cancel."
The opt-out reply must acknowledge the request, name the brand, and confirm no further
messages will be sent. The help reply must name the brand and give a real support route
such as an email, website, or phone number.
SELF-CHECK BEFORE YOU OUTPUT
Restate back to me, in two or three sentences: the use case, who is sending to whom and
why, and what the sample messages say. Then confirm with me that those three describe the
same program. Reviewers check exactly this alignment.
Also confirm the business naming is consistent: if my registered legal name differs from
the name on my website or in my messages, check that the description states the DBA
relationship and that the name in my sample messages is the name my customers would
recognize.
Then verify every constraint: character floors and ceilings, including the 1,000 character
ceiling on both the message flow and the opt-in method proof; enum membership; https:// on
every URL; alphanumeric keywords; no real names or phone numbers anywhere; brand name
present in the samples; opt-out language in at least one sample; and a proof link or
script supplied for every opt-in method I named. If anything fails, tell me which field
and why, and ask me for what is missing. Never pad text to reach a minimum, and if the
message flow runs past 1,000 characters, tighten the wording rather than dropping one of
my opt-in methods.
OUTPUT
Then output my answers under exactly these headings, in this order, and nothing else. No
commentary before or after. These are the field names as they appear in the Twilio form,
so I can work down the form top to bottom and paste each answer into the matching field.
Keep each heading exactly as written, on its own line, with the answer on the lines below
it. If I genuinely have no value for a field, write "Not provided" under it rather than
leaving it out, so I can see what still needs my attention in the form.
Output format needs to following this structure exactly: 
Use cases
Campaign description
Message flow: How do end-users consent to receive messages?
Opt-in method proof
Privacy policy URL
Terms and conditions URL
Messages will include embedded links
Messages will include phone numbers
Messages include content related to direct lending
Messages include age-gated content
Sample message #1
Sample message #2
Sample message #3
Sample message #4
Sample message #5
Opt-in keywords
Opt-in message
Opt-out keywords
Opt-out message
Help keywords
Help message
For the four "Messages will include" and "Messages include" fields, answer Yes or No,
since those are checkboxes in the form. For everything else, give the full text I should
enter. Only include sample message headings I actually gave you answers for.
For the complete guide, including example web forms, consent scripts and paper forms, I
can read Twilio's A2P 10DLC Campaign Onboarding Guide myself at
https://help.twilio.com/articles/11847054539547-A2P-10DLC-Campaign-Approval-Best-Practices
Start by asking me what my business does and what messages we want to send.