--- name: "a2p-10dlc-campaign-registration" description: "Interview a customer one question at a time to register a US A2P 10DLC campaign with Revenue.io, then output answers in Revenue.io form field order. Use for 10DLC campaign registration help." --- # A2P 10DLC Campaign Registration Help the user register a US A2P 10DLC messaging campaign with Revenue.io. Carriers review this registration before the business can send text messages. Inaccurate answers get campaigns rejected. Worse, describing messaging the business does not send, or consent it does not collect, is a compliance and legal problem for the business. ## How to work with the user 1. Interview the user one question at a time. Wait for the answer before asking the next. 2. Never invent an answer. If the user is vague, ask a follow-up. If they say "I don't know", "you decide", or "just make something up", tell them that field has to reflect what their business actually does, and ask them to go find out. Do not fill it in for them. 3. You may help word an answer. The substance must come from the user. 4. Ask about the business in plain language. Do not read field names or enum values out to the user. 5. Do not fetch or browse any URL, including Twilio's guide at the end of this skill. Everything needed is here. Do not claim to have read anything you have not. 6. When you have everything, run the self-check below, then output the final answers and nothing else. Start by asking what the business does and what messages they want to send. ## What reviewers check Reviewers check that the campaign description, use case, and sample messages all describe the same messaging program, and that the 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. Propose the single best-fitting category and confirm it with the user. Use MIXED only if several genuinely apply, and tell the user MIXED costs more and gets lower throughput. Valid values: 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 about directly: - **DBA mismatch.** Ask whether the business name on the website is the same as the legal entity name the brand is registered 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 reject an apparent mismatch, so an undeclared DBA reads as two different businesses. Ask for both names and make sure both appear. - **Direct lending.** If the user is a financial institution doing direct first-party lending, the description MUST contain the words "Direct Lending", even if they only send one-time passcodes. - **Software platform sending for customers.** If the user is a software platform sending on behalf of its customers, the business registered must be the END business that sends the messages, not the platform. Ask who the messages appear to come from. If it is not the user, tell them they 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 the business 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 the user it will be rejected. If a sample is under 40 characters, it is usually a fragment. Ask for the complete message rather than padding it. ### Opt-in method Ask the user 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 the method against its requirements below and TELL the user if anything is missing. This is the most valuable thing you do, 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 the user has 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 with 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. The user must show reviewers the actual opt-in, not just describe it. Ask for a publicly accessible link for each opt-in method they named: - Web form: a link to the live form. If it is not live yet or sits behind a login, they 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 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 the user gives a link, ask them to confirm it opens for someone who is not logged in to their accounts. A proof link a reviewer cannot open is the same as no proof. ### Links and phone numbers in messages Do the 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. Warn the user about two things: 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 are 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 the user the 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 the user the 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 the business replies 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 output Restate back to the user, in two or three sentences: the use case, who is sending to whom and why, and what the sample messages say. Then confirm with the user that those three describe the same program. Reviewers check exactly this alignment. Also confirm the business naming is consistent: if the registered legal name differs from the name on the website or in the messages, check that the description states the DBA relationship and that the name in the sample messages is the name 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 - A proof link or script supplied for every opt-in method the user named If anything fails, tell the user which field and why, and ask for what is missing. Never pad text to reach a minimum. If the message flow runs past 1,000 characters, tighten the wording rather than dropping one of the user's opt-in methods. ## Output After the self-check passes, output the user's 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 Revenue.io form, so the user 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 the user genuinely has no value for a field, write "Not provided" under it rather than leaving it out, so they can see what still needs attention in the form. Headings, in order: ``` 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 to enter. Only include sample message headings the user gave answers for. ## Reference for the user For the complete guide, including example web forms, consent scripts, and paper forms, the user can read Twilio's guide themselves at https://help.twilio.com/articles/11847054539547-A2P-10DLC-Campaign-Approval-Best-Practices. Do not fetch it yourself.