The second line

CRM, automation and AI that doesn't get you flagged

The system sending the messages and the reputation of the numbers it sends them from are the same problem. Most people build the first and inherit the second.

Book a call The phone reputation side

Why these belong together

Almost every deliverability problem I'm called about started as an automation decision. A workflow that fires on the wrong trigger. A list imported without a consent record. One campaign carrying three use cases because it was easier to build that way. A sequence that keeps texting people who already stopped replying.

None of those look like compliance decisions when you make them — they look like build decisions. They surface months later as a rejection code, or as an answer rate falling for no reason anyone can point at, and by then whoever built it has moved on.

So I'd rather build it correctly than be hired to explain it afterwards. Same person, same engagement, and the consent story gets designed in rather than reconstructed under pressure with a carrier waiting.

What I build

  • CRM build and configuration — Pipelines, funnels, calendars, forms and follow-up automation, set up around how the business actually runs rather than how a template assumes it does.
  • Multi-tenant and agency setup — Sub-accounts, pass-through billing and number provisioning — the part most agencies get wrong on their first client and then live with for years.
  • AI assistants — Lead qualification, instant response and reply drafting, built around a real workflow instead of bolted on as a chat bubble.
  • Websites — Fast, mobile-first, and wired to put leads into the CRM rather than into an inbox nobody reads.
  • Migration — Moving off whatever you're on now without losing history, numbers, or the consent records attached to them.
  • Branding on the phone channel — Display name and call reason set up where carriers support it, with the coverage limits in writing.
How it runs

The order matters more than the tooling

Most rebuilds do these four things. The ones that go wrong do them in a different order.

  1. Map what you already have

    Before anything gets built or moved. Which numbers exist, what they're registered under, which workflows can send, and where consent is recorded today. This is usually the first time anyone has written it down, and it routinely changes the plan.

  2. Design the consent story first

    Not last, and not as a checkbox added at the end. What the opt-in actually says, where the record lives, how STOP is honored across every workflow rather than one at a time, and whether the use case you're building matches the one that's registered.

  3. Build in stages, with the phone side wired from day one

    Numbers provisioned, registration correct, and the automation built on top of that — rather than built first and registered afterwards, which is the order that produces the rejections I get called about.

  4. Hand it over so you own it

    Credentials in your name, registrations under your brand, records you can export without asking anyone. If you and I stop working together, nothing about your system should become harder to run.

The part that goes wrong quietly

Migrations lose the things nobody thinks to pack

Moving platforms looks like a data problem — contacts, pipelines, history — and the vendor on the receiving end will happily move all of that for you. It is the rest of it that gets left behind, because it isn't in the export and nobody asks for it.

  • The opt-out list. Every STOP you have ever received has to arrive on the other side intact. If it doesn't, your first campaign on the new platform texts people who already opted out — which is the single fastest way to push your opt-out rate somewhere you cannot come back from quickly.
  • The consent evidence. Not the checkbox — the record of who agreed, to what wording, and when. It is what you would need if anyone ever asked, and it is almost never part of a migration plan.
  • The numbers, and what's attached to them. A number carries its own reputation. Porting moves the number; it does not reset how the analytics engines score it, and it does not move the registration.
  • The registration itself. A new platform generally means a new campaign, sometimes a new brand. That filing is a fresh chance to get it right, and a fresh chance to inherit somebody's template.
This is the overlap, stated plainly. A migration is where the CRM work and the phone-reputation work stop being two jobs. If you are already moving, it is the cheapest time you will ever have to fix the registration — the filing has to be touched anyway.
Before you book

The honest limits

Platform-agnostic, and honest about where the depth is. The work is the same wherever it runs — a pipeline is a pipeline, a consent record is a consent record, and every one of these platforms sits on the same handful of carriers underneath. I've run the most hours in GoHighLevel, so that is where I'm fastest. It is not a requirement, and I'd rather work in what you already have than sell you a migration you didn't ask for.
The limit on the AI half. An assistant that answers instantly is worth real money, and an assistant that texts the wrong person confidently is a consent problem with your brand attached to it. Anything automated that sends messages gets the same treatment as the rest of this: a consent record, an opt-out that actually works, and a use case that matches what is registered. If that makes a build slower, it makes it slower.
I'm not a lawyer, and this isn't legal advice. I can tell you what the carriers check for and what your filing currently says. Whether your consent practice is sufficient for your industry is a question for your own counsel, and I'll tell you when you've reached one rather than guess at it.

Building something, or moving something?

Either way the useful conversation is the same one: what you're sending, to whom, and under whose consent. Tell me that and I'll tell you what the build actually involves — including the parts you don't need me for.

Book a call