Pipedrive automation
Somebody built an automation once. Nobody can tell you what it does now.
Most Pipedrive accounts have a handful of automations that fired for a while, then quietly stopped mattering. A stage got renamed. A field got repurposed. The person who set it up left, or simply forgot. What is left is a system nobody fully trusts, so the team goes back to doing it by hand.
What we do
We read what is already there, and we build what is missing.
We work with a software engine we built ourselves, on top of Pipedrive's own API. It reads every Workflow Automation in your account (including detail Pipedrive's own screens do not show you clearly) and turns it into a diagram and a spreadsheet you can sit down and review. Not a guess at what your automations do. What they actually do, as configured today.
From there we build what is missing. That covers ordinary things (a stage change sends an email, a field update creates a task) and it covers logic Pipedrive's own recipe builder cannot express on its own: multi-step waits, branching conditions, a scheduled trigger tied to a date field, a rule that fires only when a custom field holds a particular value. Where an automation needs to reach outside Pipedrive, we can connect it to Make.com: when a deal changes stage, for instance, or when a field updates.
How it is handed over
Every automation lands inactive. You turn it on.
When the engine builds automations, they are written to your account as inactive drafts. Nothing runs until a person reviews it and switches it on. That is deliberate. Automation that fires on real deals before anyone has checked the logic is how accounts end up in the state we usually get called in to fix.
The same discipline applies to documentation. Whatever we build, we hand back a written record of what it does and why: the diagram, the spreadsheet, plain language underneath. You can give that to your own staff, or to a future consultant, or to anyone else. Nothing lives only in our heads.
A composite example
Telling "waiting on purpose" apart from "forgotten".
Illustrative, assembled from patterns that recur across engagements. It is not any particular company's setup.
A distributor's deals routinely sat idle for legitimate reasons: a customer's budget cycle, a permit, a signature nobody in the building controlled. Every one of those deals tripped the same stale-deal reminders as a deal someone had genuinely forgotten. The team learned to ignore the reminders, which meant they stopped trusting them for the deals that really had gone cold.
The fix is a "Hold Until" date field on the deal. Set it, and reminders and rot warnings pause until that date passes. It is one field and one extra condition on the existing automations, but it draws a distinction the account could not make before.
| Situation | Without Hold Until | With Hold Until |
|---|---|---|
| Deal waiting on customer budget approval | Flagged stale after the usual idle period | Reminders paused until the date the rep sets |
| Deal genuinely forgotten | Flagged stale, but buried among false alarms | Still flagged (there is nothing to suppress it) |
| Manager reviewing the pipeline | Learns to ignore the warnings | Trusts the warnings, because they mean something again |
Honest limits
Where this does not help.
If your stages, your fields, or your sales process itself are not settled, automating them locks in the confusion and makes it faster. Deciding what the process should be comes first, and that is a different conversation from this one.
This also reaches Pipedrive and Make.com, and no further. If the real bottleneck sits in your calendar, your email, or another tool entirely, an automation built here will not touch it. And no automation replaces a conversation a rep needs to have with a customer. It can remind someone to have it. It cannot have it for them.
Next step
See what your account is actually doing.
A 30-minute call costs nothing, and it is usually enough to tell you whether this is worth doing at all.