How We Build HubSpot Sales & Marketing Automation
When a company tells us their automation "isn't working," we almost never find a gap. We find a pile.
A portal with 140 workflows and 30 active isn't automated — it's haunted. Nobody remembers what the inactive ones did. Nobody wants to delete them, because nobody can prove what breaks. And a few of them are quietly still enrolling people.
So our approach to sales and marketing automation starts somewhere unglamorous: with an inventory, a naming standard, and documentation you can actually read six months after we're gone.
Here's how we build.
Everything gets a name that explains itself
The fastest way to tell whether a portal was built or accumulated is to read the workflow list.
If you see "New Workflow (3)," "Copy of Lead Nurture," and "test — DO NOT TURN ON," you're looking at a portal nobody can hand off. The person who built it knew what each one did. That person is often gone.
We use three layers, and every workflow gets all three:
The title says what it does. Not the theme, not the campaign — the mechanism. "[Sales] Deal Stage: Closed Won → Onboarding Handoff" tells you the trigger and the outcome before you open it.
The description says why and what it touches. Which properties it writes to, which teams it affects, what it assumes about the data going in.
The documentation says how it fits the system. This is where the reasoning lives — the decision that led to this design, and what would need to change if the business changes.
Workflows in a series get numbered. If a nurture sequence runs across five workflows, they read 1 of 5, 2 of 5, and so on. It sounds trivial. It's the difference between an admin confidently disabling step 3 and an admin refusing to touch anything.
Folders, so the list is navigable
Two hundred workflows in a flat list is not an inventory. It's a wall.
We organize by team and function, so that a marketing ops person looking for the lifecycle logic doesn't have to scroll through service ticket routing to find it. When a new person inherits the portal, the folder tree is the first thing that tells them how the business is structured.
Re-enrollment gets decided, not defaulted
This is the single most common source of "why did this customer get emailed four times."
Re-enrollment isn't a setting you turn on or off as policy. It's a decision that depends on what the workflow does. A workflow that assigns an owner should almost never re-enroll. A workflow that updates a lifecycle stage might need to. A nurture sequence depends entirely on whether the trigger is a state or an event.
So we decide it case by case, deliberately, and we write down the reasoning.
And when we inherit a portal, one of the first passes we make is a re-enrollment review across every active workflow — not just the ones you've complained about. A surprising share of automation problems that look like logic bugs are simply a re-enrollment setting nobody chose on purpose. It's one of the cheapest, highest-yield reviews in a portal.
The rest of the checklist
While we're in there, we're also looking at:
Enrollment logic
Are triggers specific, or does everything enroll on "Contact is known" and get filtered later? Broad triggers are how portals end up processing hundreds of thousands of enrollments to accomplish very little. The workflow still works, technically — it just does most of its work deciding that a record doesn't qualify. That costs you performance, it makes the enrollment history useless for troubleshooting, and it hides the actual intent of the workflow inside a stack of branches. A trigger should read like a sentence about who this is for. If you can't tell from the trigger alone which records will enter, the filtering is in the wrong place.
Overlap
Do three different workflows all set Lifecycle Stage? They shouldn't. They frequently do. One property, one owner. Overlap is what turns automation into a haunted house, because the symptom never appears where the cause lives: a record flips back to Lead, and the workflow that flipped it is one nobody was looking at. We map every automated write to a property and find out who else is writing to it — workflows, forms, imports, integrations, and reps typing into the record by hand. Then we pick an owner. Everything else that touches that property either gets retired or gets a documented reason to exist.
Dead ends
Branches that go nowhere, delays measured in months, actions referencing properties that were deleted in 2023. These are usually the residue of a good idea that got half-built, then abandoned when priorities moved. Individually they're harmless. Collectively they're the reason nobody trusts the portal, because you can't tell a dead branch from a live one without opening it, and after the fourth one you stop opening them. We clear them out and note what was there, so that the next person doesn't rebuild the same abandoned idea from scratch.
Active vs. inactive
What's genuinely retired, what's paused mid-thought, and what's "off" but still enrolling. That last category surprises people. A workflow that's turned off still holds records that entered before it was disabled, and delays that were running when it stopped are still counting down. Turn it back on to "test something" and a two-year-old queue empties into your contacts' inboxes. So we don't take the toggle at face value. We check what's currently enrolled, what's sitting in a delay, and whether anyone remembers deciding to turn it off — and then we retire it properly or restart it on purpose.
Sales automation and marketing automation are the same system
Most portals are built as if they marketing and sales are separate systems entirely - which should never be the case.
Marketing builds lifecycle stage logic. Sales builds deal stage logic. Neither knows the other writes to the same properties. Six months later, a contact becomes an MQL, then gets kicked back to Lead by a workflow nobody remembers, then re-enrolls in a nurture sequence they already finished — while a rep is actively working them.
We treat the two as one system with one set of rules about who owns which property and when a record is allowed to move backward. That decision is usually more valuable than any individual workflow we build.
On the sales side, that means routing and ownership assignment, deal stage automation that reflects your actual sales process, and knowing when a sequence is the right tool instead of a workflow. On the marketing side, it means lifecycle and funnel tracking that survives contact with reality, lead attribution you can defend to a CFO, and nurture logic that doesn't fight your reps.
You should be able to take the ball and run with it
This is the part we care most about.
Every engagement ends with documentation and flowcharts — a visual map of what runs, when it fires, what it touches, and why it was built that way. Not a login and a shrug. Not "call us when it breaks."
The test we hold ourselves to: could a competent internal admin who has never met us open the documentation, understand the system, and change something next quarter without breaking three other things?
If the answer is no, we haven't finished. Plenty of our clients take the documentation and run their own portal from that point forward. That's a good outcome, not a lost one.
When automation isn't the answer
Sometimes a client asks for a workflow to solve a problem that isn't an automation problem.
If your reps aren't updating deal stages, no automation will fix it — a stage definition they actually understand will. If your data is inconsistent at the source, automating on top of it just spreads the inconsistency faster and more confidently. If a process changes every quarter, hard-coding it into eleven workflows makes the next change more expensive, not less.
We'll tell you when that's what's happening. It's usually the cheaper answer, and it's usually not the one we were hired to give.
Where to start
If you're not sure what's actually running in your portal, start with an audit. The workflow inventory is where we spend the most time, and it's where the most expensive surprises tend to be hiding.
Book a free 15-minute call or email contact@koishark.com.
KoiShark Consulting is a certified HubSpot Solutions Partner. We audit, rebuild, and train teams on HubSpot in English and Spanish, for startups and midsize companies across the US, Canada, and Latin America.