Automating a Broken Process Just Breaks It Faster

A systems admin posted on r/CRM recently about leadership wanting the CRM turned into a tracking machine. Instant dashboards, zero-click pipeline visibility, automation on everything. The person who has to build it was pointing out, with some feeling, that the data underneath will not carry any of it, and that the Enterprise AEs have been working around the process for months.

We recognised the situation. This is not the AI pilot that stalls before launch, which we have written about separately. This one gets built, switched on, and then runs a process nobody agreed on, reading data nobody checked, at a speed that puts the output in front of leadership before anyone has looked at it.

The frictionless capture problem

The promise behind automatic email and calendar sync is that the CRM will know everything without anyone typing. HubSpot and Salesforce both sell it that way, and on a team with settled habits it mostly delivers.

On a team without them, what lands in the activity timeline is every out-of-office reply, every internal calendar invite, every scheduling back-and-forth that has nothing to do with whether a deal is moving. The signal is in there somewhere. Finding it costs more than writing the note would have.

Reps work this out quickly, and they do the reasonable thing, which is to keep the notes they actually rely on somewhere the sync cannot reach. A local doc. A notebook. A spreadsheet that will survive the next admin change. So the company ends up holding two records of the same pipeline, and the one leadership reads is the one nobody maintains.

What required fields actually produce

The standard response to bad data is to make the fields mandatory. A required Next Steps box before a deal can change stage, validation that blocks the save, an alert when the field goes stale.

What comes back is "asdasd", because a rep with eleven deals to update and a forecast call in twenty minutes will type whatever clears the gate. The close date gets pushed out a week, not because anything happened with the buyer but because that is what stops the reminder firing in Slack. Nothing about that registers as an error. The field is populated, the validation passed, the report runs green.

Then someone adds more fields, because the data still is not right, and the layout grows until updating a deal takes long enough that people batch it into Friday afternoon and reconstruct from memory what happened on Tuesday.

Where it lands

Marketing pulls a segment and launches into it. Some of those contacts left their companies months ago and the CRM still has them active, because nothing in the system was ever going to catch that on its own.

An inbound lead routes to the wrong owner because a territory field was blank and the rule had no branch for blank. That one can sit unnoticed for a week.

The forecast gets built on stage dates that were edited to silence a bot, and that is the number that goes to the board.

What has to happen first

The process needs settling before it gets automated, and settled means agreed by the people running it, including the two AEs who currently do it their own way and are both making number. Automating a contested process picks one version and freezes it, and whoever lost that argument goes straight back to working around it.

The data needs to be worth reading. A rule firing on a duplicate contact, a stale lifecycle stage, or a property that two integrations both write to will not throw an error. It does exactly what it was told, on a record that was wrong, and the result looks identical to a correct one until somebody traces it back by hand.

Something stays checked by a person. Not review-everything, which is a queue wearing a costume, but the one or two calls where a rule is known to be unreliable, written down as a deliberate choice so the next admin does not clear it out as dead weight.

The admin raising all this is usually the only person in the building who has opened the underlying records recently.

Common questions