A website project is easier to steer when the business and its design team know what is being built, who makes decisions and what has to happen before launch. A shared task board can help, but it cannot replace a clear scope or a person who can approve the work.
Editorial update: 30 October 2026. This guide retains its original URL and 2025 publication history. It now focuses on practical website-project decisions for small businesses. The change-request example below is hypothetical, not a client result.
1. Start from an agreed brief
Describe the customers, the services or products you want to grow and the useful next step the site should support. List the pages, functionality and content included in the proposed build. Identify what is explicitly outside the current project, such as a separate campaign or a later store expansion.
Use the website project brief guide and worksheet to gather the starting information. You do not need to know every answer immediately. Record unknowns and assign someone to resolve them before they block the relevant stage.
Distinguish a project deliverable from a business ambition. Publishing an agreed service page is a deliverable. More qualified enquiries is an outcome to work towards and measure. A target is not a guaranteed result, and completing a task list does not prove the outcome has occurred.
2. Name the decision-maker and the people doing the work
Agree who represents the business, who manages design and build questions, and who checks content. A clinic may need an authorised person to approve clinical information; a retailer may need the person responsible for product and delivery details. Do not assume the designer can confirm facts held by the business.
One accountable approver can gather several viewpoints. Set review dates with enough time for those conversations, and agree where decisions are recorded. A message in a personal chat and a comment on an old screenshot can otherwise become conflicting instructions.
3. Track content, access and dependencies
For each page, record who supplies and approves the wording, photographs, service facts and contact routes. Mark material as missing, in review or approved rather than treating an unfinished draft as ready for publication. Confirm permission to use supplied images and testimonials.
List the integrations the project depends on: booking tools, shop systems, forms or CRM connections. Identify who already controls each business account and how authorised access will be arranged. Use the appropriate account-access process; avoid sharing passwords in a general project document.
Put dependencies in the schedule. A build stage may rely on approved content, while a launch may rely on another provider’s domain or integration work. Make the dependency visible and agree what can progress independently when one item is blocked.
4. Give feedback against a specific version
Keep one current review version and use a single place to collect the business’s response. Refer to the page and element, explain the customer problem and distinguish an error from a preference. “The phone action is hard to find on this screen” gives the team something more concrete to investigate than “make it pop”.
Review the page as a customer would use it. Read the service information, find the next step and check the phone layout. Separate content approval, visual approval and functional checks so one approval is not mistaken for completion of all three.
Agree how feedback rounds work and what happens when the original brief changes. These are project-specific arrangements, not a fixed allowance that applies to every agency or website.
5. Assess changes before adding them to the build
New ideas are normal. Record what is requested and why, then assess the effect on pages, design, integrations, testing, timing and cost. Decide whether to include it now, replace something in scope or defer it to a later phase.
For example, a hypothetical service business might request online booking after initially scoping a quote form. That can change the customer journey, availability rules, notifications and testing. The useful next step is to agree those requirements and their impact, rather than promising the original launch date still applies.
| Record | What to write down | Hypothetical example |
|---|---|---|
| Request and reason | The change and the customer or business problem it addresses | Explore booking a suitable service rather than sending a general quote request |
| Impact to assess | Content, layout, integration, testing, timing and cost implications | Service choices, availability, notifications and request-versus-confirmation wording |
| Decision owner | The person authorised to approve the scope change | Named business approver; decision still pending |
| Outcome and date | Approved now, changed, deferred or declined, with the agreed scope | Do not mark approved until the decision and any revised scope are recorded |
| Verification | Who checks completion and what evidence they need | Planned internal journey test and confirmation of receipt by the responsible team |
6. Agree launch checks and a recovery plan
Set out the key customer journeys to check on phone and desktop: useful service information, working contact routes, booking or purchase paths where relevant, and the destinations of important links. Assign a person to confirm each result and record unresolved issues.
Plan controlled internal form or booking tests with the responsible team. Confirm that the intended notification reaches its destination instead of assuming a success message proves receipt. Exclude internal tests from genuine enquiry and conversion reports.
For a replacement website, review existing URLs, useful content and the redirects that are actually needed. Agree the launch responsibilities, available rollback evidence and who handles a material issue. A redesign or redirect does not guarantee that search positions remain unchanged. Our website migration planning guide covers that decision in more detail.
7. Close the project with a usable handover
Confirm the business can access the agreed accounts, content and assets. Record who handles hosting, software, updates, backups and later changes. Provide the editing guidance and support arrangements included in the scope, with outstanding tasks and responsibilities clearly listed.
Use our fillable website handover record (PDF, 2 pages) to organise account responsibilities, renewals, recovery evidence and open items. Save a copy for the review and mark anything not yet checked as pending. Record who is responsible and where evidence is held, without entering passwords, recovery codes or payment details.
Keep delivery checks separate from later business reporting. A launched page, a recorded phone-link click and a qualified enquiry are different events. Agree which outcomes can be measured and what remains unknown. Our marketing measurement guide helps define those distinctions.
No Brainer is based in Auckland. Our web design service explains the website scope we can discuss, with digital marketing and CRM and automation available where they fit the brief. Specific deliverables, timing, testing and support arrangements need to be agreed for the project.
Tell us about your website project or call +64 22 125 2166. Bring the current problem and the decisions you need help resolving; a finished specification is not required.
Website project management questions
Who should approve a small business website project?
Choose an accountable decision-maker and identify any people who must check specialist details. Gather their input before the agreed approval point so the designer receives a clear response rather than conflicting instructions.
What is useful design feedback?
Refer to the page, element, customer task and reason for the change. Separate a factual correction from a preference or new requirement. Consolidate feedback and identify which version it applies to.
What happens if we need extra features during the build?
Record the request, reason and likely effects on content, design, integrations, testing, timing and cost. Agree whether to include it now, replace another item or defer it. Do not treat an unassessed idea as an approved deliverable.
Does a project tool guarantee that work will be on time?
No. A task list can make responsibilities and dependencies clearer, but delivery still depends on scope, decisions, content, access and available people. Agree realistic milestones and surface blockers early.
Who should test website forms and booking journeys?
Agree who carries out each test and who confirms the result. A form should be checked through to receipt by the intended team, and a booking request should be distinguished from a confirmed booking. Use planned internal tests and exclude them from customer reporting.
What should be included in handover?
Agree business access, editing instructions, final assets, support responsibilities and the checks completed at launch. Record outstanding items and any ongoing hosting, maintenance or software arrangements rather than assuming everything is included.