In a website redesign, the supplier can organise the work, but the business still has decisions only it can make. Someone must confirm the offer, approve technical claims, provide access to existing systems and decide when the new site is ready. Naming those owners early is one of the simplest ways to keep a project moving.
This is a guide to project responsibility rather than another launch checklist. If you need to describe the business and its requirements to a prospective studio, use our website brief guide. The arrangements below help the people behind that brief make timely, informed decisions.
Give the project one accountable sponsor
The sponsor can approve priorities, budget and changes to scope. In a smaller company this may be the managing director; in a larger SME it could be a marketing or commercial director. The title matters less than the authority to settle a disagreement between departments.
The sponsor need not review every paragraph. They should agree the purpose of the site, the key audiences, the boundaries of the project and the final launch decision. If they delegate approval, make that delegation explicit.
Appoint a day-to-day content owner
A website often stalls because the supplier receives comments from several people with no single view of which version is approved. One internal owner can collect feedback, resolve contradictions and return a consolidated decision. They also need time in their working week to do it.
This person should know where current copy, imagery and documents live, who can authorise their use and which information needs updating. They do not have to write everything. They do need a reliable way to obtain answers from the people who understand the services or products.
Bring specialists in at the right point
Sales can test whether service descriptions match real enquiries. Operations can confirm delivery areas and practical capacity. Product or technical colleagues can review specifications and downloads. Someone responsible for IT can arrange domain, hosting, form and integration access. Ask each to review the part they can judge, then set a date for that review.
For example, a manufacturer should not leave a product datasheet decision to a marketing sign-off alone; the technical owner should approve the current version. Nor does the technical owner need to decide the visual hierarchy of every page. Clear boundaries make expertise useful without creating a committee for each sentence.
Agree what the studio delivers and what you supply
A proposal should say who inventories the old site, proposes the new structure, drafts or edits copy, prepares images, maps changed URLs, builds pages, configures forms and tests the result. It should also say what the client must provide and by when. “Content supplied by client” can mean anything from approved final copy to a folder of notes; clarify which one.
If an existing site is being replaced, appoint an owner for the list of pages and documents to keep, update, combine or remove. The studio can recommend a route, but the business needs to confirm that an old product or service has actually been withdrawn. Our SEO migration guide covers the separate technical steps when URLs change.
Use decision gates, not endless rounds of comments
A practical sequence has a few clear approvals. First agree the page list and priorities. Then approve the messages and representative content before design is finalised. Review the design against real pages, not placeholder copy. Finally, check the working site, its forms and the move from old URLs before the sponsor authorises launch.
At each gate, record who decides, what they are approving and what remains open. A signed-off page structure need not freeze every sentence, but a late change to the service hierarchy is different from a minor copy correction. That distinction helps both parties handle changes fairly.
Plan for absence and handover
Name a deputy for the internal owner if approvals could fall during annual leave or a busy trading period. Keep access details in the business's chosen secure system rather than in one person's inbox. At handover, confirm who controls the domain and hosting account, who can edit the site, where source files or documentation are held, and how support requests will be made.
The redesign checklist remains useful for the detailed launch checks. The responsibility question is simpler: can each important decision and test be traced to a named person? If so, the project can move without asking the studio to guess how the business works.