client requirements gathering template

Requirements should expose risk before the work is quoted.

Requirements gathering should translate a broad client request into decisions, constraints, assets, acceptance criteria, and missing information.

Use the template See related tools
Search intent Agencies, consultants, and freelancers who need structured requirements before a proposal, portal, website, or workflow build.

This page is a practical guide, not a guarantee of leads, revenue, compliance, payment collection, or platform approval.

Requirements fields

A safe starting template.

Adapt this to the buyer's business, tools, consent rules, contracts, and platform policies before using it with real customers.

01
Goal: what the client wants to change and how success will be reviewed.Review manually before external use.
Step
02
Constraints: deadline, budget, tools, compliance concerns, access, and dependencies.Review manually before external use.
Step
03
Assets: brand files, examples, copy, logins, data, screenshots, and source links.Review manually before external use.
Step
04
Acceptance: who approves, what must be delivered, and what is outside scope.Review manually before external use.
Step

Checklist

What to verify before using the workflow.

Ask why the project matters before asking what tool they prefer.

Keep this visible before sending, publishing, collecting data, or handing the workflow to another person.

Separate business requirements from feature requests.

Keep this visible before sending, publishing, collecting data, or handing the workflow to another person.

Mark missing assets as blockers, not minor notes.

Keep this visible before sending, publishing, collecting data, or handing the workflow to another person.

Document approval roles before delivery begins.

Keep this visible before sending, publishing, collecting data, or handing the workflow to another person.

Convert answers into proposal scope and kickoff tasks.

Keep this visible before sending, publishing, collecting data, or handing the workflow to another person.

Avoid these mistakes

The page should reduce risk, not just increase clicks.

Collecting preferences instead of requirements.

Fix this before treating the workflow as production-ready.

Skipping acceptance criteria.

Fix this before treating the workflow as production-ready.

Starting build work while access is missing.

Fix this before treating the workflow as production-ready.

Letting requirements live only in meeting notes.

Fix this before treating the workflow as production-ready.