If you already use an AI assistant you can use it to prepare your A2P 10DLC campaign registration before you fill out the form.
The prompt below turns your assistant into an interviewer. It asks about your business and your messaging in plain language, checks your answers against carrier requirements as you go, and then gives you your answers labeled with the same field names you'll see in the Twilio form. You copy each answer into the matching field.
It's most useful for catching problems before you submit. Carriers reject campaigns for things that are easy to fix in advance: a campaign description that doesn't say who is sending to whom and why, sample messages missing your brand name, or a web form that's missing a required disclosure. Your assistant will flag those while you're still drafting, instead of after a rejection.
How to use it
- Copy the whole prompt below.
- Paste it into a new conversation with your AI assistant.
- Answer its questions. It asks one at a time and will push back if an answer is too vague or too short.
- When it's finished, it gives you a list of your answers under each form field name.
- Open the campaign registration form and copy each answer into the field with the matching name, working down the list.
Keep the conversation open while you fill out the form. If a field needs changing, you can ask your assistant to revise that answer and keep it compliant.
Before you submit
Read every answer as you enter it. Your assistant helps you word things, but the substance has to be what your business actually does. Your campaign description, your sample messages, and your stated opt-in method all need to describe the same real messaging program, and reviewers check that they match. If an answer describes messaging you don't send or consent you don't collect, the registration is inaccurate even if it gets approved.
Your assistant also can't see your Twilio account, your brand registration, or your website. It won't know which use cases your brand qualifies for, and it can't confirm that your opt-in proof link is publicly viewable. Those are yours to check.
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.