Skip to content
Ryan GinsbergAI-Native Operating Partner
How I think

Automation problems

Why HubSpot automation breaks—and what to check first.

Missing information, duplicate records and exceptions nobody owns can turn automation into more work. Here’s how I investigate the problem before adding another workflow.

The workflow runs. The team still has to chase the work.

A deal closes and a delivery record is created. The automation reports success. But the delivery team still has to ask sales for the agreed start date, the site contact and what was actually sold.

That is a common kind of failure to look for: the software completed an action, but the next person still cannot do their job. Before adding more automation, I follow the work through to the person who receives it. The examples below show what I check.

Agree the rule before automating it.

Suppose “job complete” means the crew has finished to operations, but finance also needs approved extras and signed paperwork. Sending every completed job straight to invoicing will expose that disagreement.

I ask both teams what makes the job ready, identify the information that proves it and decide who handles a missing item. The automation then follows an agreed rule.

Check what arrived, not just whether it sent.

A record can reach another system without its line items or its link to the right customer. A retry can create a second copy. The connection is working, but someone now has to repair the result.

I test the full record and its relationships, repeat a submission and check how a failed transfer is recovered. The receiving team needs a usable record.

Give the difficult cases somewhere to go.

A standard quote may be easy to automate. A missing carrier rate or an unusual installation still needs a person. If the process silently stops, the customer waits while nobody knows who owns the problem.

I make the exception visible, give it an owner and provide a way to resolve it. That review time belongs in the estimate of how much work the change will save.

Test with the person doing the task.

A new interface can work perfectly in a demo and still force an operator through more steps than the spreadsheet it replaces. Keeping both routes open can leave two conflicting versions of the truth.

I test the daily task with its users, including a difficult case. We agree when the new route becomes the normal one and what happens to the old process.

Protect the decisions that affect money.

A person may need to see a quote total without being allowed to change its pricing rules. An integration or agent may have different permissions from the person viewing the record.

I check what each path can read and change. For calculations such as the Abs Company quote build, the server checks the amounts before saving them.

Decide who responds when something changes.

A field is renamed, a source system changes or a new exception appears. A process that nobody owns can quietly become another manual workaround.

Before handover, we agree where failures are visible, who responds and how changes are made. Some teams need ongoing support; others need documentation and someone on the team who can maintain the system.

Look for an improvement in the daily work.

After the change, can the next person complete the task? Are fewer records missing information? Is the team spending less time correcting or chasing it? These questions matter alongside successful workflow runs.

Start with one recent failure and follow it from the trigger to the final task. That usually tells us more than adding another notification to the same broken handoff.

Check what your metric is measuring

Let’s talk

Show me where the process breaks.

What still needs chasing or correcting?

Bring a recent failed handoff, duplicate record or stalled job. We’ll trace what happened and work out which part needs fixing.

A free 30-minute conversation with me, followed by a written recap. You can decide on the next step from there.

Included when you choose to email me.