Operations Consultant, New Software, or Custom Build? What to Do When Operations Are a Mess

This question usually arrives in a specific shape. Revenue is fine, maybe growing. But the owner is the person who knows where everything is, jobs fall through the gap between the office and the field, and every week there is a fire that should not have been possible. Three people have given three different answers: hire a consultant, buy better software, get something built.

I am in the unusual position of doing all three for a living, so I have no reason to push you toward any one of them. Here is how I would actually decide.

Why does the order matter?

Diagnose first, then buy, then build, in that order. Each step decides whether you need the next one. Most of the expensive mistakes I see come from starting at step two or three: a business buys a platform to fix a problem it has not defined, or commissions a custom build for a workflow that a standard product would have handled.

The three options are not competitors. They answer three different questions:

1. An operations consultant answers “what is actually broken, and what is it costing me?”
2. Off-the-shelf software answers “is there a product that already does this the way we work?”
3. A custom build answers “what do we need that nobody sells?”

You cannot answer the third question well until you have answered the first two.

How do I know if I need an operations consultant first?

Try to finish this sentence: “The step that breaks is ____, it happens about ____ times a month, and each time it costs us roughly ____.”

If you can fill in all three blanks, you have already done the diagnosis. Skip the consultant and go straight to the tooling question.

If you cannot, that is the signal. Software cannot fill in those blanks for you. It automates a process you have already decided on. Hand a platform an undecided process and you get the same confusion, now running faster and harder to change.

The other signal is when the problem you suspect turns out not to be the problem. This happens more often than owners expect. At a plumbing company doing around $2M a year, the reporting we built showed that 86% of routine maintenance visits sold nothing beyond the visit itself. The same service, done by different technicians, converted very differently: one tech turned 3 of 8 visits into a bigger job, another turned 2 of 33. No scheduling tool, CRM, or dispatch board would have surfaced that on its own, because nobody had asked the question. That is a finding, not a fix. But it is the kind of finding that changes what you should spend money on next.

What a consultant is not for: doing the work forever. If the engagement never produces a written process, a decision, or a tool, it is an expensive habit.

When is buying software the right answer?

More often than people who build software will tell you.

Buy when a standard product does roughly 80% of the job the way you already work, and the missing 20% is not the part that makes you money. For most service businesses that covers scheduling, dispatch, invoicing, payroll, and accounting. Field service platforms like Jobber, Housecall Pro, and ServiceTitan exist because those workflows are genuinely similar from one business to the next, and a vendor with thousands of customers will maintain them better and cheaper than you can.

Buying goes wrong in three predictable ways:

• Buying to fix an undefined process. The tool arrives, nobody agrees how to use it, and six months later half the team is back on the spreadsheet.
• Buying a second tool to patch the first. Each tool does one piece, and somebody in the office becomes the human integration between them, re-keying the same customer into two systems.
• Buying for the demo, not for your Tuesday. The feature that sold you is rarely the one your team touches forty times a day. Test the boring, frequent path before you sign.

When should a service business build custom software?

Build only for the workflow that makes you money and that no product fits. I use three tests, and you want a clear yes on at least one:

Is this workflow how you compete? Not bookkeeping. The specific way a lead becomes a scheduled job becomes an invoice becomes a repeat customer, if that sequence is what makes you better than the company down the road. Bending it to fit generic software files down the edge.

Are you paying several tools to each do part of one job? Three tools doing three jobs is normal. Three tools doing one job, with a person moving data between them, is where custom pays for itself, because you are already paying for the integration. You are paying in hours instead of dollars.

Does the number you need exist anywhere? Some of the most useful questions in a service business, like which technician’s visits turn into follow-on work, cannot be answered by any tool you can buy, because the data lives in two systems that were never designed to meet.

If all three answers are no, do not build. Use what you have properly. That answer is less exciting and it is right more often.

I wrote a longer piece on that last decision: build custom software or buy off-the-shelf.

What does an operations consultant do that software cannot?

Finds the problem, and prices it. Software executes. A consultant decides what should be executed, which is often not the thing the owner walked in worried about.

In practice that means three things:

• Watching the work, not the org chart. Where does a job actually wait? Who re-types what? Which step only works because one specific person remembers to do it?
• Putting a number on it. “Scheduling is a mess” is a feeling. “We lose this many jobs a month to callbacks nobody logged, and each one costs this much” is a decision.
• Choosing the smallest fix. Sometimes that is a written process and a checklist. Sometimes it is a setting in software you already own. Occasionally it is a new tool. The consultant who always recommends the same answer is selling that answer.

What order should I do this in?

Here is the sequence I would follow if it were my business:

1. Name the break. Fill in the three blanks above. If you cannot, get help doing it. This is the step where an operations consultant earns the fee.
2. Fix what is free. A surprising share of operational pain is an undecided process or a tool nobody set up properly. Settle the process and configure what you already pay for.
3. Buy for the standard parts. Scheduling, invoicing, payroll. Let a vendor carry them.
4. Build for what is left. The workflow that is yours, connected to the tools you kept. That is the only part worth owning, and by this point you know exactly what it is.

Skipping steps is how businesses end up with a platform nobody uses, a consultant’s report nobody read, or a custom system built around a process that changed a month later.

Why I can say this without a conflict of interest

I spent 12 years at Google in operations, programs, and product launches, and I have since taken on more than 30 client engagements, most of them some version of this question. Some of them needed a consultant. Some needed a better way to use the software they already had. Some needed a system built, which is what my sister company Build My System does.

Because I do all three, the only way I make the wrong recommendation is by getting the diagnosis wrong. That is the right incentive, and it is the one you should look for in anyone you ask.