Resources / templates

Working templates for real decisions.

Use the project brief to define the buyer, offer, existing workflow, first release and measures of success before requesting a proposal.

How to use the worksheet

Bring decisions, not a feature wish list.

Start with the customer action: booking a reading, buying a product, joining a course or choosing a practitioner. Describe the current route and the step that fails. Name the person who handles an enquiry, payment, change or refund.

List existing website and system access, the markets and time zones served, brand and content ownership, required integrations and any policy or legal review. Mark assumptions that have not been confirmed. A useful brief can be short when it is specific.

For a marketplace or hotline, add participant roles and one failure scenario. For a growth project, define a qualified enquiry and how it is counted. The worksheet helps both sides agree on the first release; it is not a quote or a promise of results.

Open the project brief ↗   Discuss the scope ↗

Decision guide

Use one brief to compare proposals fairly

The project brief is a working worksheet, not a sales questionnaire. It asks for the buyer, offer, current workflow, the first customer action to improve, constraints and an owner for decisions. A useful answer can be “unknown”; that is a scope question to resolve rather than a reason to invent certainty.

A practitioner website brief might describe one consultation, local and international booking, birth-data intake and follow-up. A shop brief adds catalogue, stock, shipping and returns. A reader platform needs roles, availability, billing, payouts and support. The same headings reveal different risks.

Share the brief with prospective agencies so each proposal responds to comparable requirements. Ask which assumptions they have made, which accounts you will own, how launch will be tested and what happens after handover. Open the worksheet and revise it as decisions become clearer.

Practical detail

A short worked brief

Example: a tarot reader sells live sessions and written reports. Live sessions need an available slot, price, time-zone confirmation and rescheduling. Written reports need an order, question policy and turnaround. The brief should identify these as separate customer actions, name the person who fulfils each, and state which one will launch first.

The same worksheet can reveal that a desired “app” is actually a website and booking problem, or that a proposed marketplace needs support and payment rules before design. Mark decisions that require a practitioner, legal or technical reviewer. A comparison of proposals is only fair when each team responds to the same first-release scope.

Copy the prompts into your planning document and keep a version that the business owner can approve. Update it when the offer or delivery process changes.