The most useful question in a website redesign meeting is often: what would become harder for the buyer or the business if we left this out? It helps separate necessary work from features that have entered the conversation because another company has them.
To define a B2B website redesign scope, start with the buyer tasks the first release must support, protect the parts of the existing site that already serve them and price optional additions separately. A feature earns its place when it solves a recognised problem and someone can maintain it. That leaves room for good design without committing the business to an unnecessarily complicated system.
Give each requested feature a reason to exist
“We need a customer portal” describes a proposed solution. “Repeat customers keep asking for copies of the same documents” describes a problem. The second statement allows several answers: better public product pages, a maintained document area, an improved response process or, where access genuinely needs controlling, a portal.
Ask who needs the feature, what they are trying to do and how the business handles that task now. Use actual sales questions, support requests and staff experience. Where evidence is thin, record the assumption instead of presenting it as a requirement. A director’s plausible idea can remain a useful experiment without becoming a launch dependency.
Then consider the consequence of omission. If a contractor cannot establish your service area, the site is missing essential information. If a procurement manager can request a quotation clearly without creating an account, account registration may add little to the first release. The distinction is the job being done, not whether the feature sounds advanced.
Decide what deserves to stay
A redesign does not require a new domain, replacement platform, rewritten page addresses or a different brand identity. Keep accurate content, useful project evidence, recognisable terminology and dependable functions where they still serve the business. Identify what is worth retaining before inviting proposals to replace everything.
Retaining something is an active scope decision. A contact form that works technically may still ask poor questions; a dated product page may contain the most useful technical information on the site. Assess the content, presentation and underlying function separately. You may need to change one without paying to rebuild all three.
Record the reason for any substantial replacement. An unsupported platform or a publishing process that prevents necessary updates can justify a deeper rebuild. A preference for a different tool is a weaker reason on its own. Ask the supplier to explain the practical benefit and the work involved in moving.
Separate essential information from optional machinery
For an established B2B company, the initial scope should support a coherent route: understand the offer, assess fit, check credible evidence and make contact. The pages required will vary. A fabricator may need process and capability information; a materials supplier may need product distinctions and current documents. Their content can be essential even when the site is small.
Features supporting that route need a separate judgement. A search box is useful when visitors need to find known references in a substantial range. With a compact, clearly grouped range, navigation may do the job. A news area can support an active publishing plan; an empty commitment to monthly updates creates work without answering a buyer’s immediate question.
Do not reduce the scope by removing the information that makes the business understandable. Reducing animation, automation or the number of launch templates is different from omitting approved specifications or making contact difficult. The first release should be complete for its chosen purpose, even if later releases broaden that purpose.
An illustrative scope: an industrial supplier’s first release
The following is an example, not a Smartcon Works customer project or quotation. Imagine an industrial supplier whose staff repeatedly explain product-family differences and resend datasheets. Orders require a conversation about quantity, application and delivery. The proposed wish list includes a trade portal, live stock, product filters and CRM integration.
Keep: the useful starting material
Retain the domain, accurate product references, approved photography, useful page addresses and existing contact details. Review the datasheets before reusing them. Keeping these assets reduces avoidable preparation work while preserving the information customers already recognise.
Change now: the route to a specific enquiry
Agree product-family pages, a consistent product detail format, clearly labelled documents and an enquiry route that carries the selected reference. Include the agreed records and downloads, mobile and accessibility checks, migration and a handover process. Give document replacement a named owner. This release addresses the repeated questions directly.
Postpone: functions that need more evidence
Defer live stock until the source is dependable and the team has agreed what happens when it is unavailable. Review filters after testing whether buyers struggle with the simpler range structure. Reconsider CRM integration if measured manual handling becomes burdensome. Keep the portal separate until there is a task that warrants accounts and access control.
Compared with commissioning the whole wish list, this scope concentrates the first investment on information buyers and staff already need. It does not establish a percentage saving or prove the deferred features will never be worthwhile. Each has a reason for waiting and a condition for reconsideration.
Choose a CMS around the updates people will make
A content management system is justified by an editing workflow. Identify who will update which material, how often and with whose approval. An engineering company adding frequent project records may benefit from structured editing. A company with stable service pages may be comfortable commissioning occasional changes through its studio.
Specify the editing tasks before specifying the software. Replacing a datasheet, adding a product and creating an entirely new page layout are different permissions and responsibilities. Training, access management, backups and maintenance should be understood alongside the build cost. An editor is only useful if someone has the time and authority to use it.
Where you postpone a CMS, discuss how existing content could be transferred later. That does not mean pre-building an unused system. Clear product fields, organised source files and consistent page types can make future work easier without making the first release carry every possible requirement.
Make integrations justify their continuing cost
An integration can remove repeated manual work or make information available where people need it. It also introduces dependencies on accounts, data quality and the behaviour of another system. Scope the full process: the trigger, the information transferred, the destination and what happens when the transfer fails.
For example, sending an enquiry to a CRM may be worthwhile if staff otherwise re-enter a substantial flow of well-defined requests. It is less persuasive when the team has not agreed how leads should be recorded. Automating an unresolved process can simply move the confusion into software.
Ask for a separate estimate covering setup, testing and ongoing charges, with an owner for failures. Compare that with the current handling effort before making the integration a launch requirement. Where the manual process is manageable, use it to learn what a later connection actually needs to do.
Protect continuity, ownership and maintenance in the first phase
Content and SEO migration are easy to overlook because they are less visible than new features. Inventory useful pages and downloads, retain appropriate URLs and map changes to relevant destinations. Include metadata, internal links and enquiry-route testing in the launch scope. These are delivery tasks, not optional enhancements to add if money remains.
Google’s site-move guidance covers URL mapping, redirects and monitoring, and notes that rankings can fluctuate during a move. A smaller first release still needs a responsible transition. Use our website migration guide to identify the work that should stay in scope.
Agree what the business will own or be licensed to use, who controls the domain and hosting, and how content and data can be obtained at handover. Identify ongoing charges and responsibility for maintenance. These decisions affect the cost of future changes; leaving them unanswered does not make the initial project simpler.
Turn the decisions into a first-phase scope
Write down the chosen buyer tasks, retained material, pages and records to be delivered, required functions and launch checks. List postponed items with their reasons and review triggers. Assign content approval and maintenance, then ask suppliers to quote that defined first release with optional work shown separately. Our website brief guide can help communicate those decisions once you have made them. When quotations arrive, use the same agreed scope to compare the deliverables and exclusions in each proposal.
If the scope is still crowded, bring the current site and the disputed requirements to our Website Redesign UK service. The useful conversation is about what customers need next, what the business can maintain and which changes justify their place in the first build.