Describe one process from start to finish
A useful brief starts with the work rather than a list of software features. Explain what triggers the process, who handles each step and what a completed result looks like. An agency might start with an incoming enquiry, prepare a quotation, record acceptance and assign a job. Write down where that handover currently breaks.
Include one normal example and one exception. For example, what happens when an accepted quotation changes or a customer pays only part of the agreed amount? Use fictional or redacted examples during early discussions. You do not need to send a full customer database, private bank records or passwords just to request a quotation.
Make users, records and boundaries explicit
Describe who needs to view, create, edit, approve or export each type of record. A job coordinator may need the deadline without access to every financial detail. These requirements affect design, testing and hosting; they are more useful than choosing a package by the longest module list.
List the tools you already use and the records that must move or connect. An integration needs feasibility and permission checks, while importing data may require cleaning and mapping. Mark what can wait for a later phase. A reusable base may cover the core process without a completely new build.
Share constraints before committing to a build
An estimated budget and target timeframe help both sides find a realistic first scope. It is fine to say the budget is not settled. Ask the provider to explain the work, assumptions and trade-offs before agreeing a price. Avoid treating a starting package fee as a fixed price for requirements that have not been reviewed.
Your quotation should separate project work from hosting, third-party usage, migration and optional maintenance. Agree milestones, payment arrangements, revisions and how changes are authorised. Delivery dates depend on the agreed scope, capacity and your inputs; a public example is not a delivery commitment for your project.
Define what you need at handover
Ask which accounts, files, usage rights and source-code rights you receive, including limits from pre-existing components and third-party licences. Name the owner of backups, recovery, monitoring and updates. Confirm a practical data export and how support or exit works. These responsibilities matter after the first walkthrough is finished.
Acceptance should use observable tasks: an authorised user can complete the agreed workflow, restricted actions fail, and the intended records remain connected. Each client deployment needs its own tests and recovery checks. Use ArifLab's fictional example to discuss behaviour, then send a brief about your own process. Only agreed requirements become the project scope.