A service request is a build brief, not a mood. The useful ones name the user, the job, the data, and the thing that counts as done.
What belongs in the first note
Say who uses the system on a Tuesday morning and what they do in the ten minutes that matter. Name the records involved — orders, cases, invoices, members — and where those records live today. If a spreadsheet is the system of record, say so. A sentence about volume helps more than a paragraph about vision: how many people, how many transactions a day, and which step currently breaks.
Price follows a boundary
We can price a portal that accepts a request, shows status, and sends the invoice. We cannot price “a platform” until the first release has a boundary. Put the later ideas in a list called later. The first release should be something a customer can finish, not a tour of every department.
Leave room for the answer
You do not need the database schema. You do need the decision you are trying to make: replace a tool, add a payment, or stop retyping the same brief into email. Attach an example if you have one — a redacted invoice, a screenshot of the queue, a failed export. Examples shorten the discovery call.
A brief you can hand to a developer
Write the request as a record, not as a thread. The fields below are the ones we can turn into a price without a second meeting to discover the subject. Leave a field blank when you do not know it. An empty field is more useful than a guess, because we can see the gap.
Volume is a number. “A lot of customers” is not a volume. “About 200 invoices a week, two people entering them, and the export fails when a line has no tax code” is a volume and a defect. The defect is often the first release.
Put later ideas under a heading called later. They are not deleted. They are outside the price. When the first release is in use, the later list is the backlog, and it is already written in the client’s words.
JSON · A request that can be priced
{
"user": "Accounts clerk, weekday morning",
"job": "Record a supplier invoice and see whether it is paid",
"records": ["supplier", "invoice", "payment"],
"today": "Spreadsheet plus email to the bank",
"volume": "About 200 invoices a week",
"done": "Clerk can submit an invoice and a manager can mark it paid",
"example": "Redacted invoice PDF attached",
"later": ["Mobile approval", "Supplier portal"]
}How the first call uses the brief
We price the done line, not the vision. In the example above, the first release is a clerk submitting an invoice and a manager marking it paid. That is a form, a status, a list, and a permission. It is not a supplier portal and it is not a mobile app. Those sit under later, where they can be estimated after the clerk has used the first screen for a week.
The example file is part of the price. A redacted invoice shows the fields that are mandatory, the ones that are free text, and the tax line that currently breaks the export. Without it we invent a form, and the invented form is the thing the client then says is wrong. Attach the real artifact even if you have to cover the names with a pen.
Bring the person who does the job to the first conversation, not only the person who sponsors it. The sponsor knows the outcome. The clerk knows the exception: the cash purchase with no supplier, the invoice that arrives as a photograph, the approval that happens in a corridor. Those exceptions are either in the first release or they are named as out of scope. They should not be a surprise in week three.
When the brief is this specific, the reply can be specific. A range, a first release, and the list of questions that are still open. An open question is not a failure of the brief. An open question that hides inside “and so on” is.
Before you send the brief
- Write the job in one sentence before you list features.
- Add one real example, even if it is a photo of a paper form.
- Mark anything that can wait until after the first release.
