General Project Brief
A flexible starting brief: overview, users, requirements, integrations, constraints.
Reach for it when: The enquiry does not fit a category yet, or you want one brief for everything.
- sections
- 6
- questions
- 22
- required
- 8
- AI assisted
- 22
Every section, every question
This is the template as it ships. Edit the wording, reorder the sections, or delete what does not apply to your studio.
About Your Organization
- Organization name*Short text
- IndustryShort text
- Company sizeSingle choice
- Geographic marketSingle choice
- Primary products or servicesShort text
Project Overview
- Project description*Long text
- Goals and objectives*Long text
- Background and contextLong text
- Desired timeline*Single choice
- Primary business objectiveMulti choice
Target Users
- Who will use this solution?*Long text
- Internal or external users?Single choice
- Estimated number of usersSingle choice
Requirements
- Must-have functionality*Long text
- Nice-to-have functionalityLong text
- Biggest challenge today*Long text
- What does success look like?*Long text
Integrations
- Required integrationsMulti choice
- Additional integration detailsShort text
Constraints
- Technical constraints or limitationsLong text
- Budget expectationsSingle choice
- Anything else we should know?Long text
* marks a required question. Every question in this template has AI suggestions available while the client is writing.
How to write a client project brief
Most project briefs fail the same way: they describe a solution the client has already decided on, and never capture the problem that produced it. By the time someone asks "what were we actually trying to fix," the estimate is signed.
This is the general project brief in Coligna — six sections, twenty-two questions. It's the one to reach for when a project doesn't fit a specialist template, and it's built to get at the problem before the solution.
The six sections, and what each one is for
About Your Organization. Name, industry, size, market, primary products or services. Scale changes everything downstream — the same requirement costs differently for a twelve-person firm and a national distributor.
Project Overview. Project description, goals and objectives, background and context, timeline, and the primary business objective. The background field is the quiet one: it asks why this is happening now, and "now" usually has a reason worth knowing.
Target Users. Who will use what you build, whether they're internal or external, and roughly how many. Internal-versus-external is a small question with large consequences for security, support and training.
Requirements. Must-haves, nice-to-haves, the biggest challenge today, and the definition of success. Asking for must-haves and nice-to-haves separately is the point — a client who won't separate them hasn't prioritised, and you'll be the one doing it later under deadline.
Integrations. What it has to connect to, plus a detail field. Everything named here is scope; everything discovered later is a change request.
Constraints. Technical constraints, budget expectations, and a catch-all. The catch-all earns its place — it's where clients mention the thing they assumed you already knew.
Two questions clients answer badly — and two the brief doesn't ask
"What's the biggest challenge you're facing?" — and don't accept a feature. Clients answer with the thing they've decided to build. "We need a portal" is a solution; "our clients call us for status updates we could publish" is a problem, and it might not need a portal.
"Must-have or nice-to-have?" — make them choose. Every requirement arrives as a must-have. The brief asks for both lists precisely so the conversation happens at brief stage rather than in week six.
Two more worth asking in the kickoff call, even though the template doesn't ask them:
"What have you already tried?" Failed prior attempts tell you what's actually hard, and clients rarely lead with them.
"Who has to approve this, and who else has opinions?" The approver and the stakeholders are rarely the same people, and discovering that after the second round is expensive.
From brief to project
A submitted brief arrives in your inbound queue, sectioned and typed, not pasted into an email thread. It becomes an estimate, the estimate becomes a proposal, and the accepted proposal becomes a live project carrying those original answers with it. See how the full lifecycle works →
A PDF gets filled in once and filed. A brief-capture link is shareable, needs no account from the prospect, and starts the work the moment they hit submit.
Frequently asked questions
What should a client project brief include?
Who the organisation is, what problem they're solving and why now, who will use the result, what's required versus merely wanted, what it must integrate with, and what constrains it.
When should I use a general brief instead of a specialist one?
When the project doesn't match a specialist template. It isn't a lesser version of the others — it's the right choice for work that spans categories or sits outside them. If your project is a website, a CRM rollout or a store, the specialist template asks sharper questions.
Who fills it in — the agency or the client?
The client, with your structure. A brief written entirely by the agency captures the agency's assumptions; one written entirely by the client usually misses what the build needs.
What happens after the client submits it?
It arrives as structured answers, ready to review, estimate and convert into a project without re-typing anything. See pricing for what each plan includes.