How to write an ERP requirement that vendors can quote

The reason ERP quotes are hard to compare is rarely that vendors are being evasive. It is that the requirement was vague enough to be interpreted differently by each of them.

Then the cheapest quote wins, having assumed the least — and the difference reappears as change requests once work starts.

Describe processes, not features

"Inventory management" means nothing. Every vendor says yes.

What is quotable is a process: material arrives at the gate, is weighed, checked against the purchase order, received into a specific store, and the supplier is paid against the received quantity rather than the ordered one.

Now a vendor can tell you whether that works as standard, needs configuration, or needs building — and two vendors' answers become comparable.

Include volumes

Effort scales with volume, and vendors who do not know your volumes guess.

Transactions per day at peak. Number of users, and how many at once. Items, customers, vehicles, employees, beds — whatever the relevant count is. How many locations, and whether they need to work independently.

These change both the price and the technical answer, and providing them up front prevents a revision later that feels like a bait and switch but is not.

Name what must be integrated

Weighbridge indicators, biometric devices, batching plants, lab analysers, payment gateways, banking, whatever exists.

State the make and model. "Weighbridge integration" is not quotable; a specific indicator model is. Integration effort varies enormously between devices, and this is where estimates most often go wrong.

Separate must-have from nice-to-have honestly

The instinct is to mark everything essential, on the theory that you will get more.

What actually happens is a larger, slower, more expensive project, and the genuinely critical items get the same attention as the rest.

A useful test: if this were missing at go-live, would we delay go-live? If not, it is not a must-have. Most lists shrink considerably under that question, and the resulting project is faster and likelier to succeed.

Say what you are replacing

What runs today — software, spreadsheets, registers — and what data has to come across.

Migration is a significant part of most projects and is routinely under-quoted because vendors do not know what they are inheriting until they see it. Telling them early produces a more honest number.

State your constraints

• When you need to be live, and why that date exists
• Budget range, even approximate
• Cloud, on-premise, or open to advice
• Who internally will be available, and how much
• Any quiet period that must be avoided, or targeted

Withholding budget is common and usually counterproductive. It produces proposals aimed at the wrong scale, and you spend weeks discovering that.

What to leave out

Do not specify how it should work technically. Describe the outcome you need and let vendors propose the method — you may get a better answer than the one you would have specified, and prescribing implementation eliminates that possibility.

Do not copy a requirement list from another business. Their workarounds are not your requirements.

The comparison this enables

With processes, volumes, integrations and a real must-have list, quotes become comparable on the thing that matters: what each vendor says is standard, what needs configuration, and what needs building.

A higher quote that classifies more items as standard is often cheaper in total than a lower one that defers everything to development.

If you would like help turning your operation into a document like this, see our consultation approach or get in touch.