Start with the decisions
Give the project enough context to be scoped responsibly.
This guide is for a Hong Kong business planning a company website or web-production project. It helps make the useful choices visible before a proposal: what the site must help customers understand, what evidence exists, who owns each input, and what must be checked before launch and handover.
- Business goal and customer next action
- Current pages, content, and publishable proof
- Languages, systems, and existing-site constraints
- Roles, approvals, timing, and budget assumptions
- Launch, handover, exclusions, and third-party dependencies
Begin with the business decision the website must support
A useful brief starts with the customers the site needs to help, what they need to understand, and the next action that matters. A trading business may need buyers to identify products, capability, certification proof, and an RFQ route; a professional service may need clear services, relevant credentials, and a practical first enquiry.
Name the business change behind the project as well. A new offer, changed market, confusing navigation, outdated proof, a weak mobile experience, or a manual enquiry process creates different page, content, and implementation priorities. A style reference can help, but it is not a substitute for these decisions.
Make the page and content inventory concrete
List the current site map or main pages, the pages that still earn trust or useful visits, the content that is out of date, and the evidence that can be published. That may include product information, services, certifications, team biographies, approved testimonials, case context, photographs, downloadable materials, or FAQs. Do not add claims merely because a competitor has them; the source and approval of each proof item matters.
Then state who prepares missing copy, translation, images, or specialist review. A website project can plan the structure and responsive implementation, but research, copywriting, translation, photography, legal review, or technical source data are only included when they are confirmed in writing.
Identify systems and access without exposing credentials
Record the systems that affect the project: current CMS or host, domains, forms, analytics, CRM, booking, ecommerce, email, product data, or other third-party services. Explain the useful outcome and owner of each connection, rather than assuming every integration should be rebuilt or that every account will be accessible.
A first brief does not need passwords or broad account access. If a current-site audit, migration, analytics review, or integration requires access, agree the reason, the least permission needed, the secure sharing method, and the responsible owner as part of the scope.
Agree how decisions, launch, and handover will work
Name the decision makers, reviewers, available materials, timing assumptions, and constraints that could change the scope. The written proposal should distinguish an agreed first release from later ideas, define review points, and list what happens if content, translation, integrations, or approvals are delayed or added.
Before approval, confirm existing URL treatment, testing, launch checks, analytics consent, handover, support, licences, domains, hosting, third-party costs, and exclusions. This makes the project easier to assess; it does not guarantee rankings, enquiries, or a business result.