How to describe a business process so AI can build it

In an AI-native ERP, you do not configure the software — you describe what you need and it builds it. Which relocates the entire skill of the thing: the hard part is no longer knowing the software. It is describing your own process precisely.

And most people are much worse at this than they expect. Not because they do not understand their business, but because they understand it implicitly — as habit and instinct — and habit is very hard to put into words. You will find you cannot cleanly state a process you run flawlessly every day. That gap is the whole difficulty, and closing it is a learnable skill.

Why vague descriptions produce vague systems

"Build me an inventory system" produces something generic and disappointing, and the disappointment gets blamed on the AI. But the failure happened in the description. The system faithfully built the fog you gave it.

The AI is not a mind-reader and it is not a consultant who will interrogate you for a fortnight until your real requirements surface. It builds what you describe. So the quality of what you get back is set by the quality of what you put in — garbage in, garbage out, exactly as it has always been, just faster.

The good news: precise description is a skill, not a talent. Here is how to do it.

The five things every process description needs

For any process, answer these five, explicitly:

1. What triggers it?

What starts this process? A customer enquiry, a delivery arriving, a date, a threshold being crossed. "It just happens" is not an answer — something specific kicks it off, and naming it is the first act of precision.

2. What information is involved?

What does this process touch? A customer, an amount, a product, a date, a document, an approver. List the actual things. This becomes your data — get it complete here and the rest follows.

3. What are the steps, in order?

Walk it start to finish. Someone raises it, someone reviews it, something is checked, a decision is made, a result is recorded, someone is notified. Be concrete about the sequence. This is where you discover steps you do without thinking — and steps different people do differently.

4. What are the decision points and their rules?

Where does the process branch, and on what rule? "If the amount is over X, it needs the finance manager; otherwise it goes straight through." "If the customer is on credit hold, stop and flag." These conditionals are the logic of your business, and stating them precisely is what separates a useful system from a generic one.

5. What are the exceptions?

What happens when it does not go to plan? The request is rejected — then what? The customer disputes it — then what? These are the paths people forget to describe because they are rarer, and they are exactly where systems feel broken when they are missing.

Before and after

Vague: "We need to handle purchase requests."

Precise: "Anyone can raise a purchase request. They enter what they want, the supplier, the cost, and attach a quote. If it is under RM1,000 it is auto-approved. Between RM1,000 and RM5,000, the department head approves. Over RM5,000, the finance manager approves as well. If rejected, it goes back to the requester with a reason and they can revise and resubmit. Once approved, it becomes a purchase order and the requester is notified. Show me everything pending, grouped by who needs to approve it."

The second describes a working system. The first describes a wish. The difference is not effort or eloquence — it is the five questions, answered.

The trick that surfaces the gaps

Here is the technique that catches the fog before the software does: describe it to another person and have them repeat it back.

When they explain your process back to you, you will immediately hear the gaps — "wait, no, that's not what happens when it's rejected", "actually the finance manager only approves if it's a new supplier". Those corrections are the precision you were missing, surfaced for free.

Better still, have two people from the same team describe the process separately. When they disagree — and they usually do — you have found something important: a process that is not actually defined, that different people run differently, that no software can implement because there is no single version to implement. That disagreement is not a problem the AI creates; it is one it reveals, and it was costing you quietly all along. Resolve it now, in words, before it becomes a system that half your team ignores.

What you do not need to describe

Reassuringly, a lot. You do not need to specify the data types, the relationships, the screens, the technical structure. That is the software's job — the part the AI genuinely does. You describe the business; it handles the implementation.

You must be able to say "anything over RM5,000 needs finance to approve". You do not need to know what a database relationship is, or how a conditional rule is built, or what a foreign key does. That division — you own the business logic, the AI owns the technical construction — is the whole promise of Vibe ERP, and it holds. Stay on your side of the line and describe the process; let the machine build it.

Practise on something small

Do not start by describing your most complex process. Start with something contained — a single tracker, one approval flow, per which process to automate first.

Describe it using the five questions. Build it. See what comes back. You will immediately notice what you left vague — "oh, I didn't say what happens when it's urgent" — and refine. That describe-build-look-refine loop is the actual method, and a few rounds of it will make you dramatically better at description than any amount of reading, including this article.

The skill compounds. Once you can describe one process precisely, you can describe the next faster, and the one after that faster still. It is the single most valuable capability in an AI-native business, and almost nobody arrives with it — they build it, one workflow at a time.

Common questions

What do I need to include when I describe a process for AI to build?

Five things, answered explicitly: what triggers the process, what information it touches, the steps in order, where it branches and the rule at each branch, and what happens when it does not go to plan. The exceptions are the ones people skip because they are rarer, and they are exactly where a finished system feels broken when they are missing. Answer all five and you have described a working system rather than a wish.

Why did the AI build something generic and disappointing?

The failure almost always happened in the description, not the build. "Build me an inventory system" gives the AI nothing to work with, so it faithfully builds the fog you gave it. Compare that with naming who can raise a request, what they enter, the approval thresholds, what happens when something is rejected, and what you want to see pending. Garbage in, garbage out, exactly as it has always been, just faster.

Do I need to understand databases to describe a process?

No. You do not specify data types, relationships, screens or technical structure — that is the software's job and the part the AI genuinely does. You need to be able to say something like "anything over RM5,000 needs finance to approve". You do not need to know what a database relationship is or what a foreign key does. You own the business logic; the machine owns the technical construction.

How do I find the gaps in my own description?

Describe the process to another person and have them repeat it back — you will hear the gaps immediately in their version. Better still, have two people from the same team describe it separately. When they disagree, and they usually do, you have found a process that is not actually defined and that different people run differently. That disagreement is not something the AI creates; it reveals it, and it was costing you quietly already.

If you want to work out what this would look like in your business, talk to us — including if the honest answer is that you are not ready yet.

Related: Vibe ERP explained and which process should you automate first.

Also worth reading: build a sales tracker in minutes.