← All notes
2026-07-13

Getting lead data into the CRM the unglamorous way

I run outreach for my web design practice on a CRM I built myself, and the CRM needed lead data: local service businesses, pulled from Google Maps. The obvious path was an API integration: automated, scalable, the thing a job posting would call "the right way."

I didn't take it, for three reasons that stacked.

Cost was the first and least interesting one. API pricing is designed for products with revenue, not for an outreach list that might be pointed at the wrong market entirely. Terms of service was the second: what you're allowed to do with places data programmatically is narrower than what a person browsing Maps can do, and building a pipeline on a foundation you'd have to argue about is a bad trade for a young practice.

The third reason was the real one. The workflow itself wasn't proven yet. I didn't know what a good lead looked like, which fields mattered, what volume I could actually follow up on, or whether the outreach angle worked at all. Automating an unproven workflow doesn't save time. It manufactures unproven output faster, and buries the signal you needed under volume you can't act on.

So the first version was manual. Find the businesses by hand, get them into the schema, work the list, feel where it hurts. What the manual pass taught me changed the tool: which fields I actually consulted before a call (fewer than I'd built), what state a lead moves through in practice (not what I'd diagrammed), and where in the loop a dropped thread actually costs money.

Automation is still the plan, but now it would be automating a workflow that's earned it, with a schema shaped by use instead of by guessing. Prove the thing by hand; automate it once it's real. The order matters more than the tooling.