When the Fix Isn't What You Thought It Was
How a senior moving company went from broken automations and duplicate work to a system that actually runs.
Industry: Senior moving services Stack: Pipedrive, Trello, Zapier, Google Workspace, QuickBooks Engagement: Tech Audit + Partnership
My client runs a senior moving company, helping people transition from a family home into a care facility, or from one facility to another. It's careful, human work, and the last thing a business like this needs is systems making it harder.
But that's exactly what was happening.
The business had already invested in getting its tech set up. A company came in, built out the automations, connected the tools, and handed it back. Before long, things started breaking, automations weren't firing correctly, information wasn't transferring, and instead of the systems saving time, the team was manually re-entering the same information across Pipedrive, Trello, and job files, over and over again.
They went back to the original company to get it fixed, paid again, and it still wasn't right.
By the time they came to me, a significant amount of money had been spent on a system that wasn't working, and they were being asked to trust someone new to come in and make it right. I don't take that lightly.
What they thought the problem was
The business came in with two things on the table: broken automations, and a project management tool they were curious about switching to.
Pipedrive was the CRM, Trello was where the field team worked, and the Zapier automations connecting them weren't working. The obvious starting point seemed to be: fix the automations, or maybe move to a better tool.
During the Tech Audit, I identified Asana as a potential answer for the project management piece. Based on the documentation, reviews, and integration specs, it seemed better connected to Pipedrive, and I felt confident enough that we built our partnership around making that switch.
Then I actually got in there and started building.
Asana wasn't as flexible as I'd expected, and it didn't do what I thought it could do. I had to make a call.
I went back to my client and told them straight: Asana isn't the answer. I was wrong about that, and I'd rather say so now than keep going in the wrong direction. We'd already paid for an annual subscription, about a thousand dollars, but I got the refund within thirty days and we regrouped.
That moment mattered, not because I made a mistake (I did, and I own it), but because of what came next. I had a clear plan, I communicated it, and we moved forward. I also made myself a firm rule I haven't broken since: no annual subscriptions on new tools until they're proven in the system. Monthly only, until it's locked in.
What the problem actually was
Once I stopped chasing the tool question, I started looking harder at what was underneath everything, and that's where the real issue showed up.
The data structure inside Pipedrive was never set up to match how the business actually worked. Fields were used inconsistently, information was stored in the wrong places, and the deal module had custom fields that duplicated data that should have lived in the people or organization module instead. There were multiple conflicting sources for the same piece of information.
And there was something even more fundamental. Some of the automations that had been built were trying to pull information from fields that had no data in them, the source didn't exist. The automation would fire, find nothing, and fail, not because the automation itself was broken, but because it was built without anyone stopping to ask where the information was actually coming from.
What looked like an automation problem on the surface was a structure problem underneath, and no amount of fixing the automations would have helped if the foundation was still wrong.
This is the part of the work that's invisible to most people, and the part that matters most.
What I actually did
Fixed the foundation first
Before touching a single automation, I remapped the entire data structure inside Pipedrive, every field, every module, every place information was being stored or duplicated. I laid it all out, got sign-off on the plan, and then we used a slower period over the holidays to implement it cleanly.
I sent Looms walking the team through what changed and why, they asked questions, we refined, and by the time we were done the foundation was solid enough to actually build on.
Rebuilt the automations, all five of them
Twenty broken automations became five that work, each one built intentionally, timed correctly, and designed to support the workflow instead of interrupt it.
One of the biggest shifts was rethinking when information flows where. The field team was getting Trello notifications for jobs that weren't confirmed yet, which created noise and confusion, so we moved the trigger so Trello only gets involved when a move is actually scheduled, when the team on the ground actually needs to know.
Here's how the flow works now. Early in the process, when a home visit is scheduled, a Google Drive folder is automatically created for that client, organized with before, during, and after move folders, permissions already set, and linked back to the Pipedrive deal. It's there before anyone needs it for estimates or site visits.
Then when the deal moves to scheduled, one automation does the heavy lifting. It creates the Trello card with everything the field team needs, generates a pre-filled job file from the information already in Pipedrive, and links everything together, the Drive folder, the job file, the Trello card, all connected back to the Pipedrive record so nothing gets siloed. The information is in two places at once and they're talking to each other.
The team used to copy-paste that job file by hand, and now it's just there, already filled in correctly, because the data it's pulling from actually exists and lives where it's supposed to.
Addressed contracts and payments from the start
One of the first things I flagged when we started working together was that there wasn't a consistent contract process. Estimates were going out, but contracts weren't reliably getting signed, and that's real liability for any service business.
I brought in PandaDoc, which integrates directly with Pipedrive. Now when an estimate is created, the client information is already populated, no re-entering, no switching between platforms. The estimate goes out as a document the client signs, so the contract is built right into the step they were already taking, no extra process, no extra friction. When it's accepted and signed, everything flows into QuickBooks automatically, the team stays in Pipedrive for almost everything, contracts are actually getting signed, and the liability gap is closed without adding a single extra step to their workflow.
Made sure the team could actually use it
Part of my work is making sure the system makes sense to the people using it day to day, which means talking to those people before decisions are made, not just after. Throughout the build, I was checking in with the team to understand how they actually worked, what they needed to see and when, and what was getting in their way, and that informed a lot of the decisions about structure and timing, not just the training at the end.
I also found out during those conversations that the field team was struggling to access Trello and their Google Drive folders on job sites without reliable internet, so I trained them on setting both up for offline access so they had what they needed regardless of signal. No surprises in the field.
What it looks like now
"Nothing is sticking. Everything is working exactly how it should be."
That's the goal. A system that works shouldn't demand your attention, it should just run.
The duplicate data entry is gone, job files create themselves, the field team has what they need when they need it, and contracts and payments flow from one place instead of three. The business has a system the whole team understands, which means they can maintain it and build on it.
The thing my client said that stuck with me: "I feel like if I were going to franchise, you've already done the work to create that foundation."
That's the real outcome, not just fixing what's broken right now, but building something that holds up. Whether that means franchising, bringing on more staff, eventually selling, or simply keeping a business that runs the way it should for years to come, the foundation matters, and this business has one now.
What this project is really about
The presenting problem is rarely the real problem.
This business came to me with broken automations, but the real issue was a structure that was never set up to support how the business actually worked, and automations built on top of data that didn't exist in the first place. If we'd just patched the automations, they would have kept failing.
This is why I don't jump straight to solutions. Before I touch anything, I need to understand what's actually happening, because the wrong fix, even a well-intentioned one, just creates more work.
If your systems feel harder than they should, if your team is re-entering information that already exists somewhere else, if your automations keep breaking, if you've invested in tools that still aren't working, there's usually something deeper going on, and it's worth finding out what it actually is.
Want to talk through what's going on in your systems?
Book a free 30-minute call and let's figure out what's actually happening and whether I'm the right person to help.
