Describe the work to be done

List the users, tasks, constraints and expected outputs. Separate essential requirements from preferences and future ideas. Give each essential requirement a practical acceptance test. Avoid specifying a feature merely because one vendor mentioned it. The brief should explain the problem in enough detail that different suppliers can propose credible approaches. Include the people who will operate the service, not just those approving the purchase.

Use the brief consistently

Share the same core requirements with each shortlisted vendor and record clarifications. Ask suppliers to identify gaps rather than forcing every response into yes-or-no language. Keep custom work, existing capability and planned development separate. Review the brief after discovery if the team learns that its assumptions were incomplete. Document changes so comparisons remain fair and the selected supplier understands the final scope.

Put the guide to work

Ask the intended users to rank the requirements by consequence if missing. This often reveals that a modest administrative feature matters more than a visually impressive extra. Keep that reasoning with the brief so later reviewers understand why the shortlist prioritises particular workflows.

Imagine this

Hypothetical example

A company wants employee profile management but starts with a generic software demo. Its revised brief specifies who can edit profiles, how departures are handled and what reporting is required. The next demonstrations become easier to compare because all suppliers answer the same operating questions.

Make it practical.

Use this checklist as you read. Checks are not stored.

Published by Tap Tap Go. Product availability and eligibility vary by programme and market. About our stories.