How to choose the first workflow to fix

Ask an owner which workflow is broken and you will usually get a list, fast. Invoices go out late. Quotes sit for days. The schedule falls apart by mid-morning. Parts never reach the invoice. The office retypes everything the field sends in. Every item is real.

The mistake is picking from that list by size. The instinct is to go after the biggest, most expensive, most painful problem first. It feels responsible. It is also the most common way we see a first project stall.

A first project has a job beyond fixing its workflow. It has to prove to the company that a change can stick. If it does, the next one is easier. If it does not, you have spent money and taught everyone that new tools come and go. So we pick the first workflow for how likely it is to be used, and we treat the size of the problem as a second question.

The four questions we ask

When we sit down with an owner or COO to pick a first workflow, we run each candidate through four plain questions.

How often does it happen? A workflow that runs every day, or many times a day, gives people dozens of chances to use the new tool in the first few weeks. That is how habits form and how problems surface early. A workflow that runs once a month gives you almost nothing to learn from before people have forgotten the training.

Who owns it? There needs to be one named person who is responsible for the workflow working, and one executive who will stand behind the change. If ownership is split across three departments, every decision becomes a negotiation, and the tool gets shaped by committee.

Does the information already exist? The best first workflows move information the crew or office already produces: a ticket, a photo, a note, a timesheet. If the plan depends on people starting to capture something they have never captured, the project is really a behavior change dressed up as a tool, and that is the hardest kind to land.

Whose day gets easier? Name the person. Not "the company" or "management". The person who, a week after launch, will notice that something takes less time or causes fewer phone calls. If you cannot name them, nobody has a reason to use the tool except that they were told to.

A workflow that scores well on all four is a strong first candidate, even if it is not the biggest problem on the list.

Where the good first workflows usually hide

In field operations companies, the strongest first candidates tend to sit at a handoff between the field and the office. That is where information gets retyped, delayed or lost, and where one small tool can make a difference people feel right away.

Some shapes we see often:

The job ticket that reaches the office days after the work. It happens every day, the information exists, the office manager's day gets easier, and invoices can go out sooner. See our guide on job tickets that reach the office late.

The quote that takes too long to go out. It happens constantly, it usually has one clear owner in sales or estimating, and the estimator feels the difference on the first busy week. See our guide on quotes that take too long to go out.

The office retyping field paperwork into the billing system. We call it the re-entry trap. The person doing the typing knows exactly how much of their day it takes, and they become the tool's first advocate.

What these have in common is not that they are small. It is that they are contained. One handoff, one owner, one set of people who feel the result.

One more thing tends to show up when owners run their list through these questions. The workflows that score best are rarely the ones anyone would put on a slide. They are ordinary. The ticket, the quote, the report, the reconciliation. That is a good sign. Ordinary daily work is where a small improvement repeats often enough to matter, and where the people doing it will notice the difference without being told to look for it.

The traps that make a first project stall

There are a few choices that look sensible and reliably go badly as a first project.

The cross-company workflow. Anything that touches sales, dispatch, the field, purchasing and billing at once. It may be the most valuable thing to fix eventually. As a first project it asks too many people to change at once and gives nobody a clear win.

The workflow with no owner. If the answer to "who is responsible for this working?" is a shrug, stop. Tools without owners drift. When something goes wrong in week three, nobody has the authority to decide what to do.

The workflow that depends on a system being replaced. If you are halfway through moving to a new accounting system or field service app, do not build the first tool against the one that is going away. Wait, or pick a workflow that does not touch it.

The workflow chosen because it would demo well. Some problems make a great presentation and a poor daily tool. If the pitch is exciting but you cannot name who uses it every day, you have picked a demo.

The workflow that is really a people problem. Sometimes a process is broken because a role is missing, or two managers disagree, or a policy was never set. A tool will not settle that. Settle it first, then build.

Write down what "used" means before you start

Once you have picked a candidate, write one sentence that says what success looks like, in terms of behavior you can count. For example: of the jobs closed each week, how many had their ticket completed in the new tool before the end of the shift?

Count it from your own job records, not from the tool's login numbers. Logins tell you someone opened the app. Job records tell you the work actually went through it.

This sentence does two things. It keeps the project honest, because everyone agrees before the build what a win looks like. And it forces the choice to be real. If you cannot write that sentence for a workflow, it is probably too vague to be the first one.

Then share the sentence with the people in the workflow before anything is built. Ask them whether it describes their work fairly and whether the count would be honest. They will often catch something you missed, such as a type of job that should not count, or a step that happens at a different time than you assumed. Getting that right at the start is far cheaper than arguing about it after go-live.

What to do next

Take your list of broken workflows and run each through the four questions: how often, who owns it, does the information exist, whose day gets easier. Cross off anything that falls into one of the traps. What is left is your shortlist.

If you want help pressure-testing it, the guides walk through dozens of common field and office breakdowns and where each one usually starts. And how we work explains the paid Workflow Spec, where we do this on site, map the work and tell you plainly whether it is worth building, including when the answer is no.