Start With One Problem: How to Choose the First Process to Turn Into a System

Most process automation projects do not fail because of the technology. They start from the wrong place: a long list of "everything we want to fix," or an all-in-one system meant to cover everything from day one. Either way: months of meetings, and a system nobody uses fully.

At Rabet Solutions we always start with one problem. Not because the others do not matter, but because the first process you turn into a system decides whether the team trusts the whole idea. If it works, everything after it gets easier. If it stumbles, everyone returns to spreadsheets and WhatsApp.

Here is how to choose it, with a method you can apply in one meeting.

Why one problem instead of an all-in-one system?

Three practical reasons:

  1. Clarity. One process fits on a sheet of paper: where the request comes in, who receives it, what happens next. An all-in-one system cannot be described that simply, or reviewed easily.
  2. Faster learning. Once the first version is running, you discover details nobody mentioned in meetings: a recurring exception, or a step one person did silently. Those details make a system work, and they only surface in real use.
  3. Trust. A team that watches one problem disappear from its day asks for the next one itself. That beats any slide deck.

The scoring method: frequency × cost × rule clarity

Score each candidate process on three axes, then multiply the results.

Frequency: How often does the process happen? Daily, weekly, or monthly? Process automation earns its keep when the process runs often. A task that happens twice a year, however annoying, is a poor start.

Cost: What does doing it manually cost? Not just time, but the cost of an error: a rejected invoice, a customer nobody followed up with, an approval that sat a week. The costlier the error, the higher the priority.

Rule clarity: Can the rule be written in one or two sentences? "Every incoming request is assigned to the person on duty, with a reminder after one day if it is not closed" is a clear rule. "We decide case by case" is not, and automating what you cannot describe produces a system people bypass within a week.

Why multiply instead of add? Because weakness on one axis should drag the whole process down. A very frequent, very costly process whose rule nobody can state is not ready for automation. It is ready for documentation.

Illustrative example: scoring four common processes

The numbers below are an illustrative example only, on a 1-to-5 scale, not actual results from any business. They show the thinking; yours will differ.

Process Frequency Cost Rule clarity Score (multiplied)
Customer follow-up after an order 5 4 3 60
Issuing e-invoices 4 5 5 100
Internal approvals 3 3 4 36
Compiling weekly reports 2 4 2 16

(Illustrative example — hypothetical scores to explain the method.)

What does this illustrative table say?

  • E-invoicing comes out on top because the rule is completely clear (the official authority sets it; nothing to debate) and the cost of an error is high. For many companies it is the ideal first candidate.
  • Customer follow-up is very frequent, but the rule is less clear: when do we follow up? Who does it? What do we say? The first step is not building but agreeing on one simple rule; then its priority jumps.
  • Internal approvals have a fairly clear rule but happen less often. A good phase-two candidate.
  • Compiling reports looks painful, but the rule is usually unclear (every manager wants a different layout). Postpone it until the data lives in a system; then the report becomes a by-product, not a project.

What should "version one" give you?

Once the process is chosen, the next common mistake is building the complete version immediately. Version one is not a throwaway prototype. It is the smallest system that actually runs and solves the problem end to end. It needs:

  1. One entry point. Requests arrive through one defined channel (a form, an email, a dedicated WhatsApp line), not five.
  2. A clear owner for every state. At any moment, the system and the team know who owns this item.
  3. Only the core states. Three or four (new, in progress, awaiting approval, closed) are enough. Sub-states come later, when actually needed.
  4. One useful alert. A reminder when something is late or changes state. Not ten alerts; one people read.
  5. One measured number. Overdue items, average time to close, or the share of documents accepted first time. One number tells you whether it works.
  6. An exit for exceptions. A clear way to handle cases the rule does not cover, without breaking the system or reverting to the old way.

What it should not include: multiple dashboards, complex permissions, integrations with every system you own, a report for every manager. All of that comes once the core process proves itself.

Common mistakes when choosing the first process

  • Starting with the hardest one. "If we solve this, we solve everything." The hardest is usually the least clear, and starting there burns trust before you have built any.
  • Starting with the manager's problem alone. If the process does not touch the people doing the work, they will not take it seriously.
  • Skipping the documentation. If you cannot write the rule on paper, you are not ready to build. Documenting is not a delay; it is half the job.
  • Measuring success by feature count. Success is one number chosen in advance, not the length of the feature list.

Frequently asked questions

Do we need an accounting system or an ERP before starting with process automation? No. Version one is built around a single process and can connect later to the systems you already use. One problem needs no complex infrastructure.

What if two processes get similar scores? Pick the clearer rule. In a tie, rule clarity means fewer surprises during the build and a faster version one.

How long does version one usually take? It depends, but as a rule: if the documentation runs past one page, the scope is bigger than a "version one" and should be split.

When do we move on to the second process? When the team uses version one unprompted and the measured number has held steady for a few weeks. Too early weakens the first; too late loses momentum.

Start with one problem

If you have a long list, do not send all of it. Pick one process, score it on the three axes, and send us a few lines describing it. We will tell you honestly whether it is ready for automation or needs documenting first.

Less running. More work done.