ProofDevs
Specialists for this

Requirements

A worked example, annotated

Free analysisNo commitment2 min

What is actually going on

The example below is deliberately ordinary: a small company replacing a manual process. That is the shape of most real projects, and it is the shape that generic RFP templates handle worst.

How the work runs

Step 01

Read the sections and the notes together

Each note explains what the supplier extracts from that section and what happens when it is missing.

Step 02

Substitute your own situation

The structure carries over unchanged to most small business systems.

Step 03

Check it against the checklist

The pre-send checklist catches the gaps that are easy to leave in your own draft.

The problem, as written

"Our eight field engineers complete paper job sheets. Every evening an administrator retypes roughly forty of them into our accounts system. Transcription errors cause about six invoice disputes a month, and the administrator spends around two hours a day on this. We want engineers to record job details on their phones, and that data to reach the accounts system without retyping."

Note what this does. It gives volume, it gives the cost in hours and in disputes, and it states the outcome without naming a technology. A supplier can size this immediately, and can tell you if there is a cheaper route than building software.

Users, as written

"Eight field engineers, using Android phones, often with poor signal. One administrator, on a desktop, who checks and corrects entries before they go through. One manager who needs a weekly summary."

The signal detail is the valuable line. It means the app has to work offline and sync later, which is a materially different piece of software. Left out, it appears after the contract as a change request.

Environment and constraints, as written

"Accounts run on Sage 50, on a machine in the office. We do not know whether it has an API. Budget is 15 to 25 thousand. We would like it running before our busy season in September. Nobody here can maintain software, so we will need a support arrangement."

Admitting the unknown about Sage is better than guessing. Suppliers will price the integration as a stated assumption and flag it as the main risk, which is exactly the conversation you want to have before signing rather than after.

What was asked for in return

"Please break the work into items with days against each. Give a range, not a single figure, and list what the range assumes. Tell us who would do the work. Tell us what happens if the Sage integration turns out to be harder than expected. Confirm that we own the code and the accounts from the start."

Five sentences, and they make the resulting proposals directly comparable. The question about the integration going wrong is the one that separates suppliers who have thought about your project from those who have not.

Common questions

Is this too short to be taken seriously?

Short and specific is taken more seriously than long and generic. Suppliers who require volume to engage are usually the ones with a proposals department.

Should I say we do not know something technical?

Yes. A stated unknown gets priced as an assumption. A hidden one gets discovered mid-project at your expense.

Related