Resources / worksheet
Project brief template.
Use these prompts to make discovery concrete before asking for a proposal. Unknowns are useful to flag; you do not need to guess answers.
Write a brief someone can scope.
Copy these headings into your working document, or use the guided project form when you are ready to contact SoulGait.
- Business and audience: What do you offer, to whom and in which regions or languages?
- Current situation: What site, team, tools and processes exist today? Which parts fail?
- Outcomes: What measurable change would make the project worthwhile in six months?
- Journeys: What must a visitor, practitioner, admin and support colleague each do?
- Requirements: List must-have features separately from ideas to test later.
- Content and evidence: Who owns copy, images, policies, prices, reviews and approvals?
- Connections: Name payment, CRM, calendar, messaging, analytics or API systems.
- Constraints: Budget range, deadlines, access, legal review, privacy and internal sign-off.
- Success measure: Define what will be checked at launch and after launch.
For each requirement, add an owner and mark it “must have”, “later” or “uncertain”. This makes trade-offs easier during discovery.
Turn an idea into a testable first release.
Situation: An independent astrologer offers a 45-minute online consultation to clients in several time zones. Enquiries arrive through messages; appointments are confirmed manually and double bookings occur.
First release: A service page states format, duration, price and preparation. A booking flow collects only needed birth and contact details, shows the visitor’s local time, prevents conflicts and sends a confirmation to both sides. The operator can change or cancel a slot and the customer receives the correct update.
Evidence and owner: The practitioner supplies approved method wording, a biography, actual fees and a cancellation policy. The site owner controls domain, scheduler and analytics accounts. The team tests the form delivery and a failed payment before launch.
Success check: In a supervised test, a visitor can understand the offer, book and receive a valid confirmation. After launch, compare delivered enquiries, confirmed sessions and support corrections; do not treat traffic alone as success.
For a marketplace, replace the single practitioner with provider onboarding and support roles. For a shop, replace the booking with catalogue, checkout, shipping and returns. Keep the first release tied to one complete customer action.
A brief is complete when it enables trade-offs
Do not begin with a demand for a fixed number of pages or features. Describe a real user task and the current workaround. For example: a new client cannot see available reading times, sends a message, waits overnight and sometimes books elsewhere. The first release could make the offer and availability clear and deliver a confirmed appointment.
Separate requirements from ideas. “Must have” should mean the first customer journey cannot work without it. “Later” can wait until usage proves a need. “Uncertain” needs a test, a source or a decision owner. Record the budget range and deadline so a proposal can show realistic options.
Ask each bidder to state ownership of domain, content, code, data, third-party accounts and ongoing support. Request one acceptance scenario and one failure scenario. These answers are more useful than a long feature list without responsibilities.