What should I prepare before asking a designer to build a service business website?

Describe the business decision the website should support

Start with what a visitor needs to understand and do. A service business may need people to compare services, request a quotation, make contact or book an appointment. Identify the primary action and any important secondary action instead of asking for every possible feature at once.

Describe the intended customers, their common questions and the information they need before enquiring. Use actual conversations and service experience where available. Do not invent a customer profile solely because it appears in a competitor's marketing.

Define success in observable terms. A working enquiry route and clear service information can be checked at launch. Future enquiry volume depends on other factors and should not be presented as a guaranteed result of the design project. Separate the site's functionality from later marketing outcomes.

Prepare accurate service descriptions

List the services the business actually provides and the boundaries of each. Explain who the service is for, what is included and which information is needed to discuss it. Identify services that are planned but not yet available so they are not accidentally advertised as current.

Provide approved prices or explain how quotations are prepared. If a price has not been decided, mark it unresolved rather than asking the designer to invent a figure. The same applies to turnaround times, stock availability and claims about outcomes.

Check credentials and supporting evidence before handing over copy. The Consumer Protection Act addresses misleading marketing within its scope. A useful content brief separates confirmed facts from proposed wording that still needs business approval.

Build a content pack the designer can use

Label files clearly and identify the latest approved version. A folder containing several old profiles and unnamed logo images leaves too much room for error. Keep private verification documents separate from material authorised for publication.

Assign a contact who can resolve factual questions. The designer should know who may approve service claims and who is merely providing background information.

Explain what must be preserved in the existing brand

If the business already has an approved visual identity, provide it before design begins. Include examples of current materials that represent the intended style. Identify which elements are fixed and which may be explored within the project scope.

For a replacement website, record useful existing layouts, wording, navigation and customer journeys. A rebuild does not automatically authorise changing every part of the experience. Tell the designer which content and functions must be preserved, especially where customers already rely on them.

Provide references with an explanation of what is relevant. You may like a reference's readable service structure without wanting its colours or branding copied. Clear comments are more useful than a large collection of unrelated screenshots and help avoid unrequested design changes.

Define what happens after a visitor contacts the business

Decide who receives enquiries, who responds and how the team tracks them. Specify whether different services need different recipients or whether a single team handles initial requests. A form is only useful if the receiving process works.

Choose the minimum information needed for the first response. Name, contact route, service and a short description may be enough for an initial enquiry. Detailed identity or financial documents can often wait until the need and appropriate handling process are established.

Describe the actual information handling to the person preparing the privacy content. POPIA provides relevant processing requirements. A generic consent checkbox should not replace a clear purpose, appropriate safeguards and an understandable notice.

Confirm ownership and access before work starts

Identify who controls the domain, hosting, business email and any existing website account. Collect account ownership information and arrange appropriate access for the work. Do not make personal password sharing the default handover method where separate authorised access is available.

Agree which accounts will be held by the business and how access will be managed after the project. Clarify responsibility for renewals, subscriptions and recovery details. A website that works at launch can still become difficult to maintain if essential accounts belong only to a departing employee or supplier.

Record existing integrations such as booking, payments or customer-management tools. Explain whether they are already operational or only proposed. The designer needs to understand the authorised scope before connecting systems or changing a route that customers currently use.

Explain whether the site will take payments or bookings

Describe the full customer journey for any transaction feature. Identify what the customer selects, which terms apply, when payment is taken and how confirmation or cancellation works. Do not treat a checkout button as an isolated design element.

The Electronic Communications and Transactions Act includes requirements relevant to consumer electronic transactions. The applicable disclosures and process should be reviewed against the actual model, together with other relevant obligations.

If the initial site only collects enquiries, state that scope clearly. Adding payments, accounts or document uploads later can create new operational and information-handling work. Agree how such changes will be assessed, approved and tested rather than assuming they are minor additions to the original brief.

Agree the deliverables and review process

List the pages, functions, content responsibilities and handover items included in the project. Clarify who writes or approves copy, provides images and checks business facts. Define how review comments will be collected and who gives final approval.

Identify assumptions and dependencies that affect timing. Missing content, inaccessible accounts or an undecided service offer can delay work. Keep those matters visible and agree how the schedule will be updated, without treating every estimate as an unconditional delivery guarantee.

Separate necessary corrections from new scope. If the business later asks for another service category or booking workflow, assess the effect on effort, cost and testing before proceeding. A written change record helps both parties work from the same expectations.

Prepare acceptance checks for the finished website

Agree a practical review before launch. Check the approved company facts, service copy, links, forms and any transaction journey. Inspect common screen sizes and keyboard access so that essential information and controls remain usable.

1. Trace an enquiry from submission to the authorised recipient.
2. Confirm acknowledgements describe the actual result.
3. Check important existing URLs and planned redirects.
4. Verify identity, contact and policy information.
5. Confirm business access to the agreed accounts and files.

Use controlled test information and keep a record of what was verified. A local demonstration, a preview and the public website are different stages. Confirm the agreed launch environment before claiming the live customer journey works.

Plan who keeps the site accurate after launch

Assign responsibility for content updates, account renewals, technical maintenance and enquiry handling. Identify how the business requests changes and how urgent corrections are made. A finished design still needs accurate service facts and functioning contact routes over time.

Website-design support can turn this preparation into a practical site brief. The business should approve the facts and operational commitments, while the builder confirms the agreed implementation and checks.

Keep the brief, approvals and handover record together. They provide continuity when staff or suppliers change and make it easier to distinguish a fault from a new requirement. Include the agreed contact for support and the process for reporting a failed form or incorrect business fact, so problems reach someone able to resolve them. The preparation is complete when the people involved understand both what will be built and how the business will use and maintain it.