Prefer Loud Bugs
The rule took four minutes to write. If a contact already has an open opportunity, do not make a second one, leave a note instead. Nobody argues with a rule like that. Then I opened the CRM it writes into and counted twenty open opportunities, all created in the last ten weeks, and not one of them marked won or lost in the entire history of the account.
01The field had never moved
Sit with that for a second, because it took me a while. My rule says skip while the opportunity is open. The data says opportunities here do not close. Nothing has ever gone from open to anything else. So open is not a stage. It is a permanent property of every record anyone has ever made.
Which means I did not write a dedupe rule. I wrote a rule that mutes a person for life the first time they fill in the form. After that, the only thing the agent ever does for them is leave a note, and notes get read by nobody. I built a machine whose failure mode is silence.
Key insight
A rule that keys on a status field is a bet that somebody will eventually change that field, and when nobody does, your agent goes quiet instead of loud.
That is the part worth keeping. Loudly wrong is fine. Loudly wrong gets caught in a day, because somebody gets two emails and tells you. Quietly wrong gets caught never. No one writes in to complain that the agent did not contact them.
02Same bug, different industry
I am writing this down instead of just fixing it because I have hit the same thing in businesses that have nothing to do with sales.
In the reimbursement engine I run for remote therapeutic monitoring, each patient gets a green dot for the month once a live call happens. The check is an EXISTS against the billable ledger. Same shape as the dedupe rule: look at a field, decide whether to act. It works, and it works for a boring reason. Somebody logs a call every month, the row appears, the dot flips. The state moves, so the check means something.
Now the other side. In the denial engine we queue batch jobs and hand the caller a URL to poll. For a while the local worker only woke up when something read the jobs collection. A client doing exactly what our docs said (post a batch, poll the URL you were given) never touched that collection. So the job sat there. No error. No 500. Just a status field that would have changed, if anything had ever come along to change it.
The bug was never in the rule. It was in assuming somebody keeps the field honest.
Three industries, one mistake. B2B sales, clinical billing, claims automation. Every time I wrote a condition against a field and quietly assumed a person or a cron job would keep that field true.
What broke
I shipped a dedupe rule against a status field that had never once changed value, and the cost was invisible: people who wrote in, got a note, and never heard from us again.
03Go look at the field before you key on it
The fix is not clever. Before you write a condition against a state field, go read the history of that field. Not the schema. Not what the sales rep says the process is. The actual spread of values across the actual rows.
One query. How many records sit in each state, and when did any of them last move? If everything is in one bucket and nothing has moved in ninety days, that field is not a state machine. It is a label somebody applied once and forgot. You cannot hang a decision on it.
That question saved me again last month in the quoting engine, where I almost gated follow up on a quote status nobody updates after they send the PDF.
The result
The monthly check in the billing engine holds up for one boring reason: a human logs a live call every month, so the ledger really changes, and an EXISTS against it means something.
- 1Look at the distribution before you key on the state. If one value holds every row, it is not a state.
- 2Ask when the field last changed, not what it is supposed to mean.
- 3Prefer time to status. No outreach in 30 days fails softly. No open opportunity can hang forever.
- 4Give every skip a loud path. If the agent has said nothing about a contact for a month, that is an alert, not a note.
- 5Make silent failures expensive to ignore. What you cannot see, you will not fix.
04Loud is a feature
I have spent years making agents careful. Guard the submit. Do not double up. Check before you act. That instinct is right, and it is also how you end up with a system that never does anything wrong and never does anything at all.
A duplicate email costs you a bad afternoon. A muted prospect costs you a quarter you never find out about. When you are picking between the two, pick the noisy one. You can always turn the volume down later.
Go look at your state fields. Not the code. The data.