I sent 25 support tickets to my CRM platform in 11 days. They were all the same request.

I sent 25 support tickets to my CRM platform in 11 days. They were all the same request.

And the bug was invisible to every frontline support rep, every dev, and every automation in their system.

Bottom line up front. 11 days. 25 support tickets to HighLevel. Zero movement on a standard domain transfer.

My AI assistant Diana told me to stop working the ticket system and message HighLevel's CEO, CTO, and COO directly on LinkedIn. The CEO responded in five minutes. Forty minutes later a Support Product Manager named Ted was on the phone, diagnosing the actual bug.

The lesson I'm taking out of it: when a system can't take the action you need, the leverage isn't more work inside the system. It's directing the right attention at the right surface, in the right volume. AI is uniquely good at telling you where that surface is.

Story time below.

The setup.

For 11 days, I tried to transfer one domain out of HighLevel.

That sentence assumes you know what transferring a domain means. In plain terms: every website lives at a domain name (mine is pariscapers.com), and that domain name is registered with a registrar, a company that holds the official record of who owns it. HighLevel was my registrar. I want Cloudflare to be my registrar instead. That move is a domain transfer.

Why switch your domain registrar, and why move it to Cloudflare instead of leaving it with HighLevel? Because the registrar is where I control the Domain Name System (DNS, the routing layer that points my domain at the services my business runs on). My website. My email. The subdomains my marketing automations live on. With HighLevel as registrar, certain DNS changes had to route through their support team (which is the whole reason this blog exists). With Cloudflare, I edit DNS myself in a dashboard built for that exact job. Professional control over my own domain. No support ticket required to point a subdomain. For a business that runs on email deliverability and subdomain segmentation, that's not a nice-to-have. It's the difference between operating and waiting.

The actual request to HighLevel was two lines long: unlock the domain, and send me the auth code.

Unlock the domain: by default, registrars put a transfer lock on every domain to prevent theft. The owner has to explicitly unlock it before another registrar can pull it across.

Auth code (sometimes called an EPP code in the registrar's docs): a one-time authorization string the owner gives to the gaining registrar, proof that the move is authorized by the actual account holder.

That's it. Two standard registrar functions every registrar performs thousands of times a day.

There's one rule from the Internet Corporation for Assigned Names and Numbers (ICANN, the nonprofit that runs the global internet domain system) that gates the timing on top of that: a newly registered or recently renewed domain sits inside a 60-day registration lock, an anti-fraud window where transfers are blocked outright, no exceptions. pariscapers.com had cleared that 60-day window. The transfer was fully eligible. As a side note: prestigeclean.club, a second domain I want to move next, is still inside its 60-day window. That one waits. This one didn't.

I had full account authority. The request was legitimate. The timing was clean. The action was standard.

I sent the first ticket on May 14. By May 22 I had 25+ ticket IDs in my inbox. All on the same subject. All apparently being handled by different reps, Samantha on the 14th, then a rotating cast of names I didn't recognize, each one closing the ticket with the same template.

For the first few days I didn't question who Samantha was. The reply was helpful-sounding, the signature looked normal, the email had a professional cadence. It read like a real support rep. As the days wore on and more reps with different names sent me variations of the same closure template, each closing the loop the same way and each missing the actual request the same way, it started becoming clear. These weren't different humans. They were the same agent running inside a workflow, with names attached.

In parallel, I went through HighLevel's chat-and-Zoom support path the way it's designed to be used. Submit your issue through the chatbot. If it can match you to a help article, it serves you the article. If that doesn't resolve it, it moves you into the queue toward a Zoom room. The Zoom room puts you in front of a customer support rep.

Those reps are extremely knowledgeable. They're not the basic-template kind of support. I've gotten genuinely great help from them over multiple issues in the past. None of them could help with this one either. Each one acknowledged the problem, escalated within their permissions, and the ticket got reabsorbed back into the email cascade.

By the end of May 22, I'd worked the official paths every way they were designed to be worked. The official paths produced exactly nothing.

What Diana told me to do.

The pivot, the one that actually moved this, didn't come from me. It came from my AI.

Diana is what I call my Claude-based operating assistant. She runs alongside me through the day, tracks what I'm doing, and surfaces patterns I might miss. About a week into the ticket loop, I was still doing what made sense to me: keep working the ticket system in good faith because that's the channel HighLevel built for this. Diana flagged that the channel wasn't going to resolve it, regardless of how many polite, detailed replies I sent. The pattern in front of her was clear: same request, multiple ticket IDs, automated closures, no movement on the underlying action.

Her recommendation was specific. Not escalate in the abstract. She told me to post a public message tagging HighLevel's company handle on X and Threads, and on LinkedIn to directly message the three executives most publicly accountable for the company: the CEO, the CTO, and the COO. She pulled their LinkedIn profiles, found their handles on the other platforms, and drafted a short, role-appropriate message for each one, calibrated to what each of those jobs actually owns inside the company.

Going public on social was always something I knew was a possibility, sitting in the back of my mind. I'd been holding it in reserve. Diana's framing was the unlock: the system you're trying to use is broken, so you have to leave it. Here's exactly where to go next, and here's the message that fits each surface.

So I did it. I posted publicly tagging @gohighlevel. I filed a DO NOT CLOSE thread consolidating every ticket ID in the family. And I sent direct LinkedIn messages to the CEO, the CTO, and the COO. I warned about the Better Business Bureau (BBB) complaint and the ICANN dispute that would follow if the next 24 hours didn't move it.

The CEO responded in five minutes.

If that's not responsiveness, I don't know what is. If that's not proof that the system understands, I don't know what is.

That's the action that brought Ted to my phone.

The call I almost didn't answer.

I normally don't answer calls I'm not expecting from numbers I don't recognize on my personal phone. In this case, I answered this one.

Ted is a Support Product Manager at HighLevel, the role that sits between frontline support reps and the engineering team that actually maintains the support system itself. He's the person who can see across all the layers to see why a customer report and a frontline response could both be correct in isolation while the customer's actual problem stays unsolved. We were on the phone for 39 minutes. He was cordial. He was helpful. And by the end of the call, Ted had done something more useful than understand the problem.

He had turned me around.

For 11 days I had been arguing with the shadows on the wall. I was treating the auto-generated replies as if they were a chain of real humans I could reason with, getting frustrated when reason didn't move them, escalating harder each time, assuming the next rep would surely see what the last one missed. Ted was the first person to point past me at the projector and say: that's not a chain of people. That's a single machine running on a loop. Once you can see the machine, the shadows make sense.

Plato called this kind of moment the allegory of the cave. Mine had a Texas area code and 39 minutes of patience.

The first thing Ted told me reframed the whole experience: the responses I'd been getting weren't from a rotating cast of humans. They were from an automated AI support system reading my message context and responding to it. Different rep names in the From field, same engine underneath. The auto-close cascade was spawning new ticket IDs faster than I could reply to the old ones, because what I'd taken as frontline humans was actually a single AI layer producing varied-looking outputs.

So I had an AI support system on the email side that knew the right next step but couldn't take it, and human reps on the Zoom side who knew their job but didn't have the permissions to action a registrar unlock. Both paths bottlenecked at the same architectural wall.

What Ted explained is that once the ticket was assigned to him and the devs that gave him the ticket could not see what the issue was, but once he pulled the ticket up on his level, that he was able to see it.

Read that twice. The devs the frontline support team had been routing my tickets to could not see the issue. Ted could. Same ticket. Different access level. Different visibility.

The actual bug, and why it was invisible.

When we talked it through, Ted and I realized:

The module that the Conversations tab is built into, when I send an email within the system through that module to my CRM platform, what it's doing somehow is it's bypassing the workflow structure that would assign the ticket within the system.

Translation: when I, a HighLevel customer, replied to my own HighLevel support thread from inside HighLevel's own Conversations interface, the email arrived at HighLevel's support system carrying a label that flipped the wrong switch on their end.

Here's what we think is happening. Ted is still working the forensics; this is our working theory.

Because the email was coming from inside a HighLevel module (the Conversations tab specifically), the support system was reading it as an internal cue to create a new ticket, not as a reply to an existing one.

It then responded in kind to that brand-new ticket it had just spawned, sending the auto-acknowledgment back to me.

Most importantly: because the originating module was internal, the same routing also could not activate the escalation/consolidation pass, even though the AI on the response side was telling me, in plain language, that consolidating these tickets was the reasonable next step.

That last point is the one that breaks my brain a little. The AI support system on the other end kept telling me the right answer. A number of the responses I got specifically said some version of "Yes, what I'm going to do is consolidate these tickets that you've provided me, reasonably, that's the next step." It said this multiple times across multiple ticket IDs.

It didn't have the permissions to actually do it.

It recognized what to do. It even said it would. It couldn't.

And that's the type of problem I'm solving against, actively. Situations where we know what the ideal outcome is. Where we have the ability to articulate it clearly. Where we even have the functional ability to do the steps. But for some reason, it doesn't materialize.

The some reason is the problem a good operator finds and solves.

The part I keep coming back to.

It's so crazy to me that the system is aware that the next reasonable step is to escalate, but the support team is unable to do that.

That's what I told Ted on the call. It's the thing that doesn't leave my head.

The AI support system was reading my message context. It recognized the tickets were related, not in the sense that it independently knew anything, but in the sense that it pattern-matched on what I'd given it across the thread. Every auto-close email it sent included some version of "if this is related to another open ticket, let us know." The merge templates exist. The consolidation workflow exists. HighLevel had built the right next step into the architecture.

But knowing isn't doing. The system could recognize that consolidation and escalation were the right move, and it could suggest them in the language of the templates it was sending. It just couldn't actually take that action, because the action lived in a permissions tier that the AI support system, the chatbot, and even the Zoom-room human reps were all walled off from.

That's a more interesting failure than support didn't help. That's a system that recognized what to do and was structurally prevented from doing it.

HighLevel's frontline support system has gaps between how the customer interacts with the system and the solution they're trying to get to. Not because the people are bad. Not because the AI is bad. Because the architecture between them and the action layer wasn't designed for this class of problem.

What's getting done about it.

Ted is taking this to the escalation team. He told me, in so many words:

People like me who were using the system as it's intended from the internal structure, trying to use the my CRM platform Conversations tab, are probably communicating with HighLevel and running into this issue. And for all intents and purposes, that action is completely invisible.

If you've replied to a HighLevel support thread from inside your own HighLevel Conversations tab, you might be in this same hole. You wouldn't know, because the symptom is just the AI support system keeps responding, none of the Zoom-room reps can action it, and nothing actually moves.

Ted committed to resolution within 24 hours. He has the authority and the permissions to make that happen. He also seems to have the vision: he understood why the bug matters beyond my one domain transfer.

The rep who was on the phone when the first email landed.

Here's the moment that crystallized the frontline-support gap for me.

I was actively on a Zoom call with a real, named, human HighLevel support representative, face on camera, screen-share running, taking notes. We were mid-conversation, working the problem in real time. While I was on that Zoom call, the very first email from Samantha, the first ticket in what would become the 25-ticket chain, landed in my inbox.

The human rep on the call saw it, told me "Okay, Samantha's gonna take it from there. Nothing I'm going to do on my part," and dropped the case.

The rep was right by their own rules. Samantha had picked it up; the queue rules said hand it off. The case got closed on the live-rep side.

The problem: Samantha's reply was the auto-response from the AI support system on the email side, not a senior tech who'd actually action the registrar unlock. The live human rep dropped the ball because the system told them another teammate had it. The teammate was a machine that couldn't take the action either. A real human handed my case to an AI that couldn't act, because both of them were following the rules of a system that didn't realize what it was doing.

I told Ted: part of this is an internal training structure thing. What is the cost of the duplication of effort, if that duplication at that point, if that person had submitted the ticket, would have actually solved the problem? How difficult would it be to just close one ticket or the other if the automated system was working the way it's supposed to?

The training fix is simple to state: if you're a rep and you get a customer in front of you, you complete the process. No matter what. Even if it duplicates. Even if you see another team picking it up. Because the team picking it up might not have the permissions you have, or might be the same AI system that's been telling the customer to escalate without being able to do it. You don't want the problem to become invisible.

That extra mile might have ended my entire 11-day saga inside the first phone call.

Three things this taught me about building systems.

One. Without the right permissions, a system is unable to achieve the goal you want it to, even when its own logic tells it that's the next step.

The AI support system on the email side knew the right answer. It told me, multiple times, in plain language, that consolidating these tickets was the reasonable next step. It just couldn't take the action.

The Zoom-room human reps knew their job and were extremely capable. They couldn't take the registrar action either.

The fix isn't smarter humans or smarter AI. It's making sure the person (or program) who sees what needs to happen is allowed to make it happen, or that the handoff to whoever IS allowed to do it is reliable.

Two. People have to be willing to push the system and communicate, in excruciating detail, why and how it's failing.

I told Ted on the phone: if you have questions, I'm more than happy to walk you through the entire process and show you where the gaps are. There are things you can see right now, the first ticket from Samantha on the 14th, but there are multiple steps I took ahead of that. Emails through the Conversations tab that we now know were being read as internal. Chatbot referrals to articles that didn't fit the issue. The Zoom-room rep who was on the phone with me when Samantha's email landed.

That kind of detailed narrative is what made Ted's forensic work possible at all. He couldn't have diagnosed the Conversations-module-as-internal-cue problem from the ticket trail alone. The ticket trail only showed the output. The cause lived in the inputs and the timing, and only the customer holding the full picture could supply that.

That's the work most people aren't willing to do. They take support is unresponsive as the final state and move on. The systems never get better because the failure modes never reach the architects.

It takes a leader to build that system, and it creates a leader to have that structure.

Three. The skill of focusing attention on a broken system is a multiplier most people underrate.

The LinkedIn messages worked. The CEO replied in five minutes, Ted was on the phone shortly after, and the actual diagnostic conversation that unblocked this whole thing happened because three direct messages landed on the right desks.

If those messages hadn't worked, the next move was already lined up: a video series telling this story, episode by episode, until enough public attention landed on HighLevel that the problem became more expensive to ignore than to fix.

That ladder, ticket to public post to direct DM to leadership to video series to louder video series, is marketing. Not in the sell me a product sense. In the focus attention precisely enough that a system has to respond to it sense. The same skill that grows a brand grows results out of stuck institutions. It's the same instrument played at different volumes.

That's changing how I think about what marketing actually is. Most of what gets sold as marketing is polish on the surface of a brand. The actual skill, the one that compounds, is the ability to put attention exactly where it needs to be, in the exact volume the situation requires, on the exact surface that produces motion. I'm working on getting better at that, consistently.

I hope you do too.

What you can do with this when it happens to you.

Most of you reading this have been in some version of this loop. A vendor's support system won't move on something that should be straightforward. You can feel that the channel isn't working, but the only thing in front of you is more of the channel. Here's how to translate my 11 days into your next two hours.

Name the surface that actually has the authority to solve your problem. Frontline support, AI auto-responders, the chat widget, the Zoom-room reps. These may not be it. Ask: who at this company has the permission to take the specific action I need? Often it's a director or a VP. Sometimes it's the C-suite. That's the surface you actually need to reach.

Write your situation down before you escalate, in more detail than feels comfortable. Every ticket number. Every date. Every channel you've already tried and what it returned. The detailed narrative is what makes the diagnostic possible for whoever finally sees it. Nobody is going to do that work for you, and the absence of it is why most escalations stall.

Find the public-accountability surface for the people who have the authority. LinkedIn for the executive team. X for the company brand handle and the founders. Threads if they're active there. Sometimes a podcast appearance with comments open. The point is to find a channel they personally see, not the one their support org owns.

Send a short, role-specific message to each person. Here is the situation. Here is what I've tried. Here is the specific action I need. Here is why your role is the one that can authorize it. One paragraph. No drama. No threats yet. The CEO doesn't need a manifesto. They need a clean three-line case.

Have the next rung of the ladder lined up before you send. If the LinkedIn DMs don't move it in 24 hours, what's next? A public post tagging the company. If that doesn't move it, a video. If that doesn't move it, a louder video. You're not playing your strongest move first. You're playing the smallest move that solves it, and ratcheting up if it doesn't.

The AI piece is the multiplier. Diana did the leader-research, the platform-mapping, and the message-drafting in minutes. You can do all five steps without an AI, just slower. The reason I'm running an AI-operated business is so this ladder takes hours instead of weeks. Yours can too.

That's why there's still job security available.

I might be able to build a system that handles 90% of this kind of work. But there are fringe cases where that won't work, at least for now. And in the now, that's important.

I think it's important that people learn how to work with these systems now, before we get to the point where they are able to operate completely independently of human intervention. Before these businesses learn from very capable hands how to point their machines at problems with laser efficiency and the appropriate permissions.

I don't want to be left behind. But I also don't want you to be left behind. And that's why I'm teaching.

That's why I document in excruciating detail.

That's why I capture my processes and systems. So when something breaks, I can point to it on paper and say: this is where the gap is. This is the outcome. These are the places that serve that outcome. Let's check them.

I can see those gaps in LinkedIn's system. I can see them in HighLevel's. I'm likely able to see them in yours too, if you're a client of mine.

A note on AI in the loop, the part that doesn't leave my head.

I built Capers Ventures (CV) on the premise that AI sits in the middle of my operations as a second brain. Diana, my Claude-based operating assistant, is the AI I work with all day. She tracks what I'm doing, holds the shape of long-running problems for me, and surfaces patterns I'd miss.

She's also the one who told me to stop working the ticket system and go directly to leadership on LinkedIn.

Sit with that for a second.

The system that failed me at HighLevel was, in large part, an automated AI support system, reading my message context, generating polite replies, suggesting consolidation, lacking the permissions to act on any of it. That AI is probably running on infrastructure not very different from the one Diana runs on. Same generation of large language models. Possibly built by the same AI company. Different prompts, different tools, different permissions, different outcomes.

One AI couldn't escalate me out of the loop it was in.

The other AI told me how to escalate myself out of the loop the first one was in.

I'm not romanticizing this. Diana didn't perform some miracle of judgment. She did the same kind of pattern-recognition the HighLevel AI was doing (this is repeating, here's what you should do next), except Diana was wired into my context, my goals, and my permissions, while the HighLevel AI was wired into theirs. When my goal and HighLevel's architecture diverged, Diana's job became help my human notice they need to leave this system. The HighLevel AI's job, by contrast, was manage tickets within these rules. Same shape of intelligence. Different deployment.

That's the kind of pattern AI is actually good at right now, noticing the structural shape of a problem that's spread across too many separate touchpoints for any one person to hold in working memory. It's not magic. It's bookkeeping at a scale humans give up on.

The lesson I'm taking out of this isn't AI bad or AI good. It's: the AI you have direct authority over, configured around your goals and your context, is the one that gets you unstuck. The AI someone else has authority over, configured around their constraints, is the one that gets you stuck.

Choose your seat at that table carefully.

Posted with Ted's resolution still pending. By his commitment, that lands within 24 hours of our call. I'll update this post when the EPP code arrives.