Your database is the source of truth, not your vendor's

A lot of businesses treat their CRM as the place where the truth lives. A lead comes in, it goes straight into the vendor's system, and from then on every question about that person gets answered by asking the vendor. Who is this? What did they tell us? What step are they on?

In the intake platforms I build, it works the other way around. The business's own database is the single record. The CRM is an important destination, and the team lives in it all day, but it's downstream. It gets a copy. It doesn't get to be the memory.

Why I don't let the vendor be the memory

When the CRM is your only record, you've handed three things to someone else without really deciding to. Your data model is whatever their fields allow. Your reporting is whatever their dashboards show. Your uptime is their uptime. If their API slows down or a field gets renamed, your intake breaks in ways you can't see from your side.

There's a deeper issue too. If you can only see your customers through a vendor's dashboard, you're renting visibility into your own business. I'd rather own the first-party data and choose what to share.

The same thinking applies to AI. I keep the engines tool-neutral, with thin adapters for each model vendor, so switching providers means rewriting an adapter and not the business logic. And where it matters, I self-host.

Write to your own ledger first

The core rule is simple. Everything a person tells you is written to your own ledger first. Only after it's safely stored does it get pushed to the CRM.

That push goes through one queue and one rate governor. The governor is the piece that controls how fast requests go out to the vendor. This matters more than it sounds. Most CRM APIs give you a shared budget of calls. If every part of your system talks to the vendor directly, one careless caller, a buggy loop or an overeager sync, can burn the whole budget and block everyone else. With a single queue, you can see what's waiting, slow it down, retry what failed, and nothing is lost because the ledger already has it.

IDs get stored and linked the moment each one exists. When the CRM hands back a record ID, I save it next to my own record right away. When e-signature creates an envelope, same thing. Nothing in the running system asks the CRM "who is this?" at runtime. My database already knows, because it was told at the moment the link was made.

Links that never break

Every link I send to a person is a short link that never expires. It doesn't point at a fixed page. It decides where to go at the moment someone taps it.

This sounds like a small detail. It's one of the most useful decisions in the whole platform. People open texts and emails days or weeks later. If the link points straight at a page, and you've since rebuilt that page or changed the flow, the person lands on an error. With a resolver in between, you can rebuild any destination without breaking a single link anyone is holding. The resolver looks up where that person is in the process right now and sends them there.

Multi-step intake, then a person

Intake is rarely one form. In the platforms I build it's a sequence: an eligibility check, then e-signature, then a questionnaire, then document upload. Anything left incomplete gets a "missing data" follow-up page that asks only what's still open. Nobody should have to re-enter what they already gave you.

Around that sequence sit staged reminders by text and email. If someone stalls, they get a nudge, then another, spaced out sensibly. After that, a person reaches out. Automation handles the routine chasing. A human handles the conversation when routine chasing hasn't worked.

Every automated sender has a stop switch. If a reminder template has a mistake in it, or a sequence is firing when it shouldn't, I can turn off that one sender without touching anything else. Building the off switch before you need it is much calmer than building it during an incident.

A form that submits isn't a form that delivers

This is the lesson I keep relearning. A form showing a thank-you message tells you the browser sent something. It doesn't tell you the lead reached the ledger, got pushed to the CRM, triggered the right reminder, and showed up in front of a person.

So I prove every leg. Did the submission land in my database? Did the CRM record get created, and did I store its ID? Did the first message go out? Did the link inside it resolve? Each of those is a separate check, because each can fail on its own while the others look fine. I went deeper on this in following one click from ad to CRM.

A checklist for your own intake

If you want to move your own setup closer to this, here's where I'd start.

1. Make a list of every place customer data enters your business. Forms, calls, chat, email.
2. For each one, check where it's written first. If the answer is "the vendor," add a write to your own database before the push.
3. Route all outbound calls to the CRM through one queue. Add a rate limit you control.
4. Store every external ID next to your own record the moment you receive it.
5. Search your code for places that ask the vendor who someone is at runtime. Replace them with lookups in your own data.
6. Put a resolver behind every link you send. Never send a link that points straight at a page you might rebuild.
7. Build a follow-up page that only asks for what's still missing.
8. Add a stop switch to every automated sender, and test that it works.
9. Write a check for each leg of the journey, and run it on real submissions, not only test ones.

None of this means the CRM matters less. The team still works there, and it should be accurate. The point is that accuracy comes from your side. When the vendor has a bad day, you don't lose a single thing a customer told you, and when you want to change vendors, you already have everything.

Your customers told you, not your vendor. Keep the record where it belongs.