What to write down before you commission software

Write down the rules your business already runs on: the three workflows that decide whether you make money, how each one works today including its exceptions, and who is accountable when a record is wrong. One page of those rules gives every vendor the same thing to price, and gives you something to test at the end. The answer flips if you cannot state a rule in a single sentence with its exceptions — then you are not ready to commission software, and the cheaper move is to buy a package and change your process to fit it.

Which three workflows decide whether you make money?

Three, not ten, and workflows rather than departments. A workflow starts when something arrives — an order, a delivery, a request — and ends when money or stock has moved. Everything between those two points is what you are buying.

Ask each manager a blunt question: which decision, taken wrongly twice in a month, would cost you the month? The answers repeat across businesses. How a price is agreed and then held. How stock is reserved and released. How a delivered order becomes an invoice and a payment. Put those three at the top of the page.

The rest of the operation is real work, and it is not what this purchase is for; a list, a form and a printout can wait. If you specify them first, they are built first, and the workflow that pays the salaries arrives late and thin.

How does the rule run today, including the exceptions?

Write the rule as it runs, not as the procedure manual claims it runs. Sit with the person who does the work, ask for one real case, and watch what they touch: which screen, which notebook, which phone call, which messaging thread. Then ask what happens when the customer is over their credit limit, when the delivery arrives short, when the price was agreed on the phone, when the same customer orders twice before noon.

The exceptions are the requirement. A rule with one exception a month is a note in a procedure. A rule with one exception a day is part of the workflow, and software that cannot express it will be worked around inside a month. Record how often each exception occurs, in days or weeks, because that frequency is what tells a vendor whether they are pricing a field or a feature.

Do not clean the process at this stage. If you write the version you intend to enforce, the team keeps the version it actually uses, and the system becomes a second set of books.

Who is accountable for each record?

One record, one owner, one place of correction. For the customer, the order, the delivery note, the invoice and the stock movement, name a person or a role who answers for it being right. Then name where it may be edited, and what is never edited at all.

Write that as a list rather than a diagram: record, owner, where it is created, where it is corrected, what must never change. It decides your import, permissions and audit trail later, and is the only defence against two systems claiming to be the truth about the same customer.

What does an acceptance test look like?

An acceptance test is one sentence you can run on a Tuesday with real data. "Given a customer with an unpaid invoice, when the salesperson confirms a new order, the system either blocks it or asks a named role to approve, and records who approved and when." That is testable. "The orders module works" is not.

Write five to ten of them for the three workflows, each built on a case from last month, including the awkward one everybody remembers. Get them signed before the build starts. At delivery, "done" stops being an opinion and becomes a list you can run in an afternoon.

What can you compare two quotes on?

What you hand over	What the quote prices	What you can hold the vendor to
Rules, exceptions and owners	A defined scope	The acceptance tests
A feature list of screens	A number	Nothing in particular
A competitor's system as the model	Their interpretation of it	A demo, not the build

With the page in hand, two quotes become comparable line by line: what happens to exception three, what a change costs after sign-off, what the first module contains. Without it you are comparing two numbers produced under different assumptions, and the lower one usually assumed less.

What not to write

Do not write a wish list of screens. "A dashboard for the manager", "an app for the drivers", "a portal for suppliers" — each is an answer to a question nobody asked, and a list of screens returns a list of screens with a database behind it.

Leave the technical decisions to the vendor as well: the framework, the database, the hosting. Every one you take is a question you can no longer ask, and a risk you adopt without the knowledge to carry it.

The order to write it in

1. Name the three workflows that decide the month, in one line each.
2. Watch one real case of each and write the rule in a single sentence.
3. List the exceptions under each rule, with how often they occur.
4. Name one owner per record and one place where it is corrected.
5. Turn five to ten real cases into acceptance tests.
6. Mark what belongs to phase two, and state what the first module must do to be useful on its own.
7. Send the same page to every vendor and require written answers to the same questions.

Where this goes wrong

• The page becomes a document. Sixty pages get skimmed, priced vaguely, and quoted with a large contingency. One page of rules beats ten pages of description.
• Written by one person, unread by the people who do the work. If the team has not read it, it describes a business that does not exist.
• Acceptance tests written as feature checks. "Can create an invoice" passes on a system that produces the wrong totals.
• Treated as frozen. It will change. Write down who decides a change and how it is priced, instead of promising that nothing will.
• Nobody signs it. An unsigned page is a suggestion, and the first disagreement goes back to memory.

What this does not cover

It does not cover the contract: payment schedule, warranty, liability, ownership of the code. Those need their own document, and a lawyer decides the wording — this page helps your lawyer ask better questions, it does not replace them. It also does not cover a business with no history yet, a new line or a new company where the process is genuinely unknown; there, run a month on paper and write down what happens before buying anything.

We write this page with the people who do the work and then build against it, so the first acceptance test is one your team already passes by hand.