A GHL Implementation Case Study
1. Introduction
Business automation is not just about connecting tools or creating workflows. Sometimes, the more challenging part is understanding how existing systems work together, identifying where a process is failing, and making the changes that are necessary to keep the flow going.
I recently worked on an A2P 10DLC registration within a GoHighLevel (GHL) environment. The initial campaign submission was rejected, which meant I had to investigate the existing configuration, review the requirements essential for registration, and make changes before submitting it again.
Eventually, both the Brand and Campaign received approval.
What made this experience valuable was that it required more than navigating the GHL interface. It involved understanding at a deeper level layers like CRM messaging, website configuration, customer opt-in, business information, and compliance requirements as interconnected parts of a business process.
In this article I am now explaining the problem-solving and workflow improvement process.
2. System Overview: GoHighLevel and A2P 10DLC
GoHighLevel is a CRM and business automation platform that brings together several business functions, including:
• Contact and customer management
• Sales pipelines
• Workflow automation
• Website and funnel creation
• Communication and messaging tools
One of its messaging capabilities involves SMS communication.
For businesses sending application-to-person (A2P) messages through US 10-digit long-code numbers, A2P 10DLC registration is part of the messaging compliance process.
The registration involves two important components:
Brand Registration
This establishes the identity of the business sending messages.
Campaign Registration
This describes why the business sends messages and how customers agree to receive them.
GHL provides the interface for submitting A2P registration. However, the registration is also processed through external messaging providers and is subject to mobile carrier requirements.
This means that completing the registration inside GHL is not enough. The business information, messaging use case, website, and customer opt-in process must also meet the applicable requirements.
3. The Initial Problem: Campaign Rejection
The initial A2P campaign submission was rejected.
Rather than treating the rejection as an isolated registration issue, I approached it as a problem that could involve several parts of the existing setup.
I needed to understand:
• Whether the selected messaging use case was permitted.
• Whether the submitted business information accurately represented the business.
• How the website presented its messaging opt-in mechanism.
• Whether the existing website widgets could create confusion around the consent process.
• Whether the required Privacy Policy and Terms of Service pages were available.
• Whether the registration details accurately described the intended messaging activity.
The important part was not simply submitting the campaign again. It was understanding what needed to be reviewed before another submission.
4. Investigation and Process Analysis
I began reviewing the existing business setup and the different components involved in the registration.
This included the GHL configuration, the website, the domain, and the available opt-in mechanisms.
To understand the requirements, I completed GoHighLevel’s A2P 10DLC course in the Learning Center. Because parts of that course were out of date, I cross-checked it against GHL’s current A2P 10DLC help articles and used those as my reference. Here are a few Key articles:
Understanding A2P Campaign Rejection Reasons & Required Fixes : HighLevel Support Portal
When an A2P 10DLC Campaign is rejected, HighLevel displays the rejection reason and the corrections required before you can resubmit. This guide explains how to view required fixes, understand A2P rejection and vetting error codes, determine...
google.com
A2P 10DLC Campaign Approval Best Practices : HighLevel Support Portal
A2P 10DLC Campaign approval depends on whether your Campaign information clearly and consistently explains who is sending messages, what is being sent, why recipients receive the messages, and how they consented. Use this guide before submit...
google.com
How to Register a Pre-Built A2P Campaign in HighLevel : HighLevel Support Portal
SMS Compliance Pre-Built A2P Campaign (Widget-First) Registration Complete Campaign Registration with Chat Widget Setup using HighLevel's guided flow, auto-generated consent widget, and support for Marketing, Informational, and Mixed messagi...
google.com
I then compared what the campaign had submitted against those requirements, covering the use case, business information, website opt-in, and legal pages, before changing anything.
One of the challenges was that these components were connected. For example, the website’s opt-in mechanism was relevant to the messaging consent process. The business’s legal pages were also important because they provided information about how customer data and messaging consent were handled.
I therefore approached the problem as a complete workflow rather than focusing only on the rejected campaign.
5. Workflow Modifications
After reviewing the setup, I made several changes before submitting the registration again.
5.1. Registration Setup
I used GHL's Quick Setup process for the registration.
This gave me a more structured way to work through the setup rather than continuing with the previous configuration.
5.2. Website Widget Configuration
I removed the other chat widgets from the website and retained GHL's generated chat widget during the registration process.
The objective was to simplify the website's opt-in configuration and avoid having multiple widgets involved in the same customer interaction.
5.3. Opt-in Configuration
I reviewed the opt-in arrangements across the website.
No additional opt-in form was used on the pages during this registration process. I kept the GHL-generated widget as the opt-in mechanism.
5.4. Privacy Policy and Terms of Service
I ensured that the website had clear Privacy Policy and Terms of Service pages.
These pages are important parts of a business's customer-facing information and messaging consent arrangements.
5.5. Messaging Use Case and Registration Details
I reviewed the campaign details and ensured that the selected use case reflected a permitted messaging activity.
The registration information needed to describe the actual intended messaging purpose rather than a prohibited service.
The goal was to make sure the registration represented a legitimate and permitted use case, not simply to change wording to get past the review process.
6. Validation and Outcome
After making the changes, I submitted the registration again.
The final result:
• Brand Registration: APPROVED
• Campaign Registration: APPROVED
Both statuses were approved in GHL.
This was the outcome of the investigation and revised setup.
I would not treat any individual configuration change as a universal guarantee of approval. A2P registration depends on the business, its messaging use case, the information submitted, and the applicable requirements.
However, this experience demonstrated the value of reviewing the entire process rather than repeatedly submitting the same configuration.
7. Operational Lessons: From Troubleshooting to Workflow Optimization
One of the biggest lessons from this experience was that operational problems are not always isolated to the place where they appear.
A rejected registration may require investigating several connected components:
• The CRM configuration
• The website
• The domain and business identity
• The customer opt-in journey
• The messaging use case
• The compliance documentation
This is where process analysis becomes important.
Instead of approaching every issue as an individual technical error, I began looking at how the different components interacted.
The process can be represented as:
Observe > Investigate > Identify Constraints > Modify > Validate > Improve
This approach is useful beyond A2P registration.
It applies to CRM configuration, workflow automation, customer onboarding, data handling, and many other business operations.
Automation is only useful when the underlying process makes sense. Automating a poorly configured process can simply make the original problem happen faster.
Understanding the process first is therefore just as important as knowing how to use the automation platform.
8. A Lesson from Mental Toughness
Around the same time, I was reading HBR’s 10 Must Reads in Mental Toughness.
One lesson from the book stayed with me: setbacks do not always have to be treated as reasons to stop. They can also be information that helps us understand what needs to change.
I found myself applying that idea to this technical problem. The initial rejection was frustrating, but it also gave me a reason to investigate the existing setup more carefully. I had to stay with the problem long enough to understand it, identify the constraints, and improve the process. Not every problem has an immediate answer. Sometimes the first configuration does not work. Sometimes the issue is not where we initially expect it to be.
9. Conclusion
This project was a valuable experience in working across CRM configuration, business messaging, compliance requirements, and workflow improvement.
The final approval was satisfying, but the bigger achievement was understanding how the different parts of the business setup connected and how changes to the process could address the original problem. It also reinforced how I want to approach my work in automation and business operations.
I am interested not only in building automations, but also in understanding existing business processes, identifying inefficiencies, resolving operational issues, and improving the systems that businesses already use. Because successful automation does not begin with a workflow builder. It begins with understanding the process.
Top comments (0)