Building a No Code CRM That Stops Wasting Your Time
1. Why I Stopped Using Airtable as My CRM Core
I wanted to love Airtable as a CRM backbone. On paper, it handles data like a champ — relational fields, embedded forms, automations that almost behave like logic… but somewhere around the twelfth automation, things got unpredictable. Record updates would ghost. The sync lag with external tools like Zapier hovered between 5 seconds and 5 minutes with no explanation. At some point, my status column switched from “select field” to a single line text, which broke 3 Zaps silently.
That was probably the moment I knew I couldn’t treat Airtable as the core logic layer — not if I needed consistency across time zones and teammates. Fine to use it as a frontend. Sketchy as a backend.
Also — and this one caught me mid-demo — Airtable quietly deletes old webhooks if your base hits inactivity. That means a record added via Make.com simply won’t trigger your Zap one day. No error. No email. Just nothing. Great.
Switched to using Coda for logic and interfaces, stuck Airtable in the corner with limited read-only syncs.
2. Using Zapier as a Task Router Not a Brain
People treat Zapier like a brain. It’s not. It’s a muscle with muscle memory — great for moving stuff around, terrible for holding structure. I burned full hours trying to create branching logic for different types of leads — B2B, partner, cold, warm — and eventually the Zap became this 31-step monster with 8 filters and 3 paths. Running cost? Around five bucks a day depending on volume. And half the paths never even got triggered.
What worked better: turn Zapier into a dispatcher, not a decider.
I set the first Zap to just catch the inbound form, tag it with source and timestamp, then chuck the record into a Notion database. Then Notion’s own internal filters + linked views handled the actual segmentation. Half the logic moved out of Zapier, and I got back some semblance of sanity and logging.
“The moment you model user intent in Zapier, it becomes brittle. Model it in a UI layer, let Zapier just push buttons.”
Also worth noting: Zapier’s conditional “Paths” feature fails silently if your test data doesn’t hit every branch. I had a whole side path for sales reps that never triggered because test data was missing the “Role” field. No log, no alert, just quiet dismissal.
3. Sorting Customer Tags in Notion Without Making 50 Views
Notion’s great for replacing the CRM dashboard layer — unless you try to re-create tag logic like HubSpot. I learned the hard way that you don’t need to make a view per status. Just use one giant board with filtered properties and let your filters stay fuzzy.
- Use one multi-select “Tags” column instead of five single-boolean fields
- Filter views with “contains” rather than “is exactly”
- Use groups, not filters, to loosely delimit state (e.g. group by “Pipeline Stage”)
- Add a formula column that stitches source + date to make segment IDs
- Use inline databases in toggles to simulate customizable views per team member
On a bad day, I was up to 19 unique views just to handle different tag-based cohorts. After simplifying to 3 relational fields and letting Notion’s relations do the nesting, it actually felt navigable again.
4. The One Time Make.com Overwrote My CRM Queue
I had Make.com set up to pull leads from multiple form sources, normalize the format, pop them in a queue table, and send batch alerts every morning. All was fine. Until one day, the queue table just vanished — overwritten entirely with 8 payloads that repeated the same name. Turns out, my aggregator scenario didn’t clone the output array — it serialized it. And then mapped it directly back over the same table, assuming these were “updates.”
There’s a checkbox in Make scenarios called “Map manually” under the Array Aggregator output that behaves differently depending on whether the previous module outputs a collection or a bundle. That checkbox silently resets if you re-link a source. Ask me how I found that out. (I didn’t — I cried into the scenario log until support replied.)
After that, I added a timestamp validator module to block overwrites older than the last commit. Still held my breath every time the scheduler ran.
5. Setting Up Slack Thread Logging That Actually Scales
I hate Slack DMs for lead handoffs. Everything gets lost. So I wired things up to post new leads into a #leads-inbound thread, with each lead opening a new threaded reply, plus a pin with the record ID. Then reps could react with emojis to trigger follow-up Zaps (⭐ to assign, ❗ for callback request, ✅ to close).
First time I did this in Zapier, it created a separate message per emoji. That was noisy and annoying. Turns out you can’t re-use message_ts as a thread_parent unless you explicitly expose and re-reference that ID in later Zaps.
Thread-safe tip:
Store each message_ts in a paired storage module (like storage by Zapier or a Notion column). When an emoji event gets picked up, query that store to grab the original thread ID. Only then can you safely reply inline without creating duplicative threads.
This scaled reasonably to about 15–20 leads a day with 3–5 reps. Beyond that, I’d jump to creating a custom Slack bot using Bolt if messages perminate.
6. Filtering Out Garbage Leads Without Losing Real Ones
Every form gets spam-led sooner or later. I started getting garbage entries with names like “Test”, emails that were literally “lol@lol.com”, and phone numbers like “1234567890”. The first instinct was to filter these at the form level, but the validation rules never caught enough edge cases. Example: someone filled in “CEO of space” with a real email address from a student domain. Genuine? Who knows. I didn’t want to block the next funder just because they typed like a bot.
Instead of filtering at the gate, I added a scoring layer post-submission. One Zap hit a Natural Language Processing API that estimated contact intent via the free-text fields. Another Zap cross-referenced email domains against a curated Google Sheet of known real companies (basically anything that wasn’t from a “mail.ru” type TLD).
Then I tagged the CRM card with score buckets: “Likely Real,” “Suspicious,” or “Too Weird.” Even better — I added a manual “Override legit” checkbox so a human could nudge something back up if it turned out to be fine after all. No more throwing out potential customers while trying to dodge spam.
7. The CRM Table That Always Deletes Itself After One Week
This one haunts me. I had a temporary buffer table in Airtable that was supposed to be cleared every 7 days. There was a Make.com scenario scheduled to delete any record older than 7 days using a filter on the “Created Time” field. Simple enough. It ran every Monday. Then one week — poof — it wiped everything. Not just the old ones. The whole table.
The root cause? Airtable appends milliseconds to timestamps, but Make was parsing them only to the second. So “created_at >= now() – 7 days” matched everything when the scenario was triggered exactly on the boundary. Because the comparison was round-tripping without milliseconds, all timestamps appeared as “older than” when they weren’t.
Lesson: always log the actual Date.now() payload inside Make before executing destructive actions. I now run these tests with “dry run only” booleans AND I added a second distinct date field that only logs via automation when a human clicks a checkbox. It’s harder to spoof, doesn’t update on record edits, and gives a reliable kill window anchor.
8. Logging CRM Changes Without Rewriting the Same Record
Anytime I had multiple automations touching the same record — especially one with status or notes — things started colliding. I’d lose comments. Notes disappeared into the version history. Zapier re-writes the whole record when updating one field unless you fork-storage every prior field value.
Switched to an append-only model: each status update creates a new record in a “logs” table, not an overwrite. Relate that back to the master lead via a foreign key. Any interface can read latest status by sorting the logs descending. Historical view? You already have it. Undo? Just re-post the prior state.
Quick log model structure:
- Leads Table: one row per lead
- Status Logs Table: one row per change event
- CRM Interfaces: use latest log entry as computed current state
It’s noisy at first. But nothing breaks. And you stop wondering why your “Notes” field keeps reverting to that weird blank line you swear you deleted.