Before you commission software, follow one order.

The brief says “We need an inventory system.” That sounds specific until someone asks what happens when a customer changes an order after the stock has been picked.

The answer might live in a phone call, a handwritten note, or the memory of the person who manages the store. A software estimate that misses that answer is estimating only part of the job.

Before you write a feature list, choose one recent order and follow it all the way through the business. Use an ordinary order first. Then find one that went wrong.

Start with the evidence already on your desk

Gather the enquiry, quotation, approval, invoice, picking record and delivery confirmation. Remove customer details before sharing examples with a prospective supplier. Put the documents in the order people actually use them, rather than the order the procedure manual suggests.

For each step, write down four things: who acts, what they need to see, what they change, and who takes over. If two people maintain the same figure in different places, mark it. If somebody waits for a message before continuing, mark that too.

You now have the beginnings of a scope. It is more useful than “a modern dashboard with real-time reporting” because a developer can ask concrete questions about it.

Give the exceptions their own page

Consider a hypothetical distributor. The standard flow is simple: an order is approved, stock is reserved, and a delivery is arranged. But a useful tool also needs a position on partial deliveries, damaged items, cancelled orders and credit customers.

The first release does not have to automate every exception. It does need to say how each exception will be handled. “The store manager records a manual adjustment with a reason” is a legitimate design decision. Leaving the situation undefined is a future argument.

Define one useful release

“Everything our business does” is a poor first milestone. Choose a complete piece of work that a real person can finish with the new tool. For example: receive an order, check available stock, record an approval and produce a picking list.

Keep a separate list of later improvements. A customer portal may be valuable, but it should not quietly become a prerequisite for replacing an internal spreadsheet. Reporting can start with a reliable export before it grows into a complex analytics screen.

Be careful with the word “simple.” A simple screen may sit on top of difficult permissions, historical data or third-party integrations. Ask which assumptions could change the estimate and how those assumptions will be checked.

Write the acceptance example

Here is a more testable requirement than “support approvals”:

A sales colleague can submit an order. A manager can approve or reject it. The record shows who made the decision and when. A rejected order cannot generate a picking list.

Add one example of an unauthorized action and one correction. Now you have something to demonstrate at a review. You can disagree about the behavior before it becomes expensive to change.

Use the same approach for exports, notifications and integrations. What information appears? Who receives it? What happens if the other system is unavailable?

Take this to the first meeting

• One ordinary workflow, with anonymized examples.
• One awkward case and its current workaround.
• A list of users and what each may change.
• The systems the new tool must connect to.
• A small first release and a clear example of success.
• An owner who can answer operational questions during the build.

There is another useful outcome: you may discover that a change to an existing tool would solve the problem. That is a good reason to do this exercise. The decision to commission software should follow the work you need to improve.

If you do proceed, ask the supplier to return your workflow as a written scope. Check that the exceptions, handover and ongoing costs survived the translation.