Automation makes a process faster. It doesn’t make it right.
If leads are currently assigned by a sales manager who remembers that “Dave handles the healthcare accounts unless they’re in Canada”, a workflow that copies that logic will copy the gaps too. When Dave leaves, or Canada gets a new rep, nobody remembers the exception lives inside a branch of a workflow last edited eighteen months ago. Healthcare leads start going to the default owner, and it takes weeks for anyone to spot the pattern.
So the first part of our automation work is unglamorous. We write down the rule, check it with the people who follow it, and only then build it.
Questions we answer before building anything
- What has to be true about the record for this to start? Which field, which value, which source?
- What event triggers it? A form, a property change, a deal moving, a date passing, an event from another system?
- Who should be excluded? Existing customers, open opportunities, unsubscribed contacts, competitors, test records.
- What happens if the data is missing or wrong?
- Can a record go through this twice, and should it?
- How will we know it worked?
These sound obvious. Most of the broken automation we see skipped two or three of them.
What we automate
The same thinking applies to internal processes that aren’t strictly sales: approval steps, renewal preparation, data hygiene jobs that flag records missing key fields.
What a well-built automation looks like
Take a simple case. A trial user hits the usage limit on day five.
The data says they’re on a trial and which plan they chose. Their state is “Trial, active”. The event is the usage limit being reached, sent from the product into the CRM. The business rule says: if the company has more than 20 employees and no open deal, create a deal and assign it to sales; otherwise, start the self-serve upgrade email. The automation carries out that rule, and the action is either a task for a rep or an email to the user. Then we measure how many of each path converted, and adjust the threshold if 20 turns out to be the wrong number.
Written out like that, it’s easy to see where things fail. If the product never sends the event, nothing happens. If employee count is blank for half of trials, the rule needs a default. If someone already has an open deal, they shouldn’t get a second one. Each of those becomes a branch or an exclusion, and each one is tested.
Workflows piling up and no one's sure what they do?
We can review your current automation, map what each workflow touches and propose what to keep, merge or retire before anything new gets built.
Where CRM automation usually goes wrong
Workflows that fight each other. One sets lifecycle stage to “Lead” on form submission, another sets it to “Customer” from the billing sync. Whichever runs last wins. We map which workflows write to each critical property so there’s a single owner for every value.
Re-enrollment surprises. A contact who meets the criteria again gets the whole sequence again, including the “welcome” email, two years after they joined.
Silent failures in middleware. A Zapier or Make scenario that errors on one in twenty records, with alerts going to someone who left the company.
Automating volume instead of judgment. Sending more sequences to more people is easy. Deciding who shouldn’t get them is the useful part.
If you suspect several of these, it’s worth starting with a CRM audit, which includes a full workflow inventory.
How engagements work
Small automation projects, such as rebuilding lead routing or setting up deal-won handoffs, are scoped and priced individually after a short call. Larger programs usually sit inside a CRM implementation or an ongoing CRM optimization arrangement. Customer-facing journeys like nurture, onboarding emails and win-back are covered under lifecycle automation.
We build in your platform’s native tools wherever they can handle the logic: HubSpot workflows, Zoho workflow rules and Blueprints, ActiveCampaign automations. Integration platforms come in when data has to cross between systems.
Should we automate everything we can?
No. Automate what is frequent, rule-based and costly to get wrong manually. Rare decisions that need judgment, like pricing exceptions or handling an unhappy enterprise client, are better left to people with good alerts and clear context.
Native CRM workflows or Zapier, Make and n8n?
Native first, when the logic lives inside one system. It’s easier to see, debug and hand over. Integration platforms make sense when you’re moving data between systems or need logic the CRM can’t express. See our integrations page for how we choose.
Can you fix automation someone else built?
Yes, and it’s a large part of what we do. We document what exists before changing anything, so you don’t lose behavior that something else quietly relies on.
How do you test automation before it goes live?
With named test records run through every branch, including the edge cases: duplicates, missing fields, existing customers, people who unsubscribe mid-sequence. Then we watch the first real records go through.
Will our team understand the workflows afterward?
They should. We use clear naming, add descriptions inside the platform where it supports them, and give you a written map of what each automation does and what it writes to.