Requirements written in vendor dialect
An RFP feels responsible: compare three suppliers, score features, let procurement run the clock. It fails when the process in the document is the idealised version from a workshop — not what actually happens when the depot is short-staffed and finance needs a number by four. Vendors optimise to win the document. You live the exceptions.
You cannot procure against a process you have not drawn. An RFP written from brochure language buys you a three-year subscription to someone else's fiction — and then a rescue project when go-live meets reality.
Fix the order before the RFP goes out
Map the process before you write a single requirement — this is not optional paperwork. Name owners and the system of record for each fact that must not be wrong. Then write requirements as test cases: given this job state, show me the invoice line and who approved it; given a partial delivery, show me inventory and billing without a manual export.
Only then invite demos on those cases — the same discipline as running vendor demos on your workflow. The RFP should read like an exam vendors can fail on your data, not a wish list copied from an analyst report.
What to put in the RFP that actually bites
Ask for export formats and exit cost at year three — shelfware is cheap to enter and expensive to leave. Ask who can change a posted record and what audit trail exists. Ask what happens on partial completion, change orders, and credit notes. Ask how multi-site or multi-entity actually works, not what the slide deck claims.
On the softer elements: what training is included versus billed separately, who owns middleware when the API changes, and what support tiers look like with named response times. Tie those response times to naming owners for every alert, not vague "best efforts" language.
Scoring without theatre
Weight test case pass rate above feature checkboxes. Two vendors may tick the same forty boxes, but only one survives your Tuesday. Include someone from the floor in scoring — if they say "I would still use email", that is a fail even if procurement likes the price.
If vendors cannot answer on your scenario, that is data, not rudeness. Work through bespoke versus off the shelf before signatures. An ROI framework helps the board see past licence cost to the actual relief a system provides.
When the RFP is the wrong tool
Sometimes you need a thin build or one integration, not a platform bake-off. Sometimes the honest answer is to integrate before you replace. An RFP written against a fictional process is procurement busywork — it delays the map you needed first.
Reference customers that look like you
Ask vendors for reference calls with firms your size, in your sector, with similar handoffs — not enterprise logos on a slide. Ask those references about go-live pain, about training, and about what still lives in a spreadsheet. Ask what they would not buy again. References are not cheerleaders; they are data if you ask blunt questions.
Do not overlook your internal references either. The ops lead who said "I would still use email" during scoring should be heard, not overruled because procurement liked the price. Their objection is often the truest test case you have.
Book a free systems review — Teesside and the North East, remote when fit. A process audit gives you the map before the RFP goes out, not a PDF nobody on the floor recognises.