What Needs to Be Defined First in a B2B Website Redesign

There's a version of this that happens all the time.

A business decides it needs a new website. Someone gets put in charge of the brief. They gather feedback from a few internal stakeholders, pull together a list of pages they want, and write up what they're looking for.

The problem is that most of the important decisions haven't been made yet — and by the time anyone realises this, the project is already underway.

The questions that come back to haunt you

A B2B website brief typically covers things like: how many pages, what kind of design style, whether there's existing content to use, budget, and timeline.

What it often doesn't cover — at least not explicitly — is why this website exists in the context of how the business actually works.

That sounds abstract, but it shows up in very concrete ways:

Who is this website actually for? Not a general description of "our target audience" — but a specific kind of person making a specific kind of decision. What are they comparing you against? What do they need to see to feel confident enough to make contact?

What should this website change about how we get business? If the current site isn't working, what specifically isn't working — and is a new website the right solution to that problem?

What happens after someone enquires? If you don't have a clear, consistent process for handling inbound leads, a website that generates more of them creates a different kind of problem.

These questions are uncomfortable because they reveal that the website project is sometimes a symptom of something else: a business development process that hasn't been fully defined, or a service offering that isn't yet clearly articulated.

Why booking is a useful example

One specific scenario that illustrates this well: businesses that decide they need a booking function on their website.

The brief usually includes something like "we need a booking page." A form, a calendar, a way for clients to select a time. That's straightforward enough to build.

But the moment bookings start coming in, the actual questions emerge.

How do you manage availability? If a staff member is unavailable, who updates the calendar and how? What happens when someone needs to cancel or reschedule? Do you need to send confirmation emails, reminders, follow-ups? Does booking data need to feed into another system — invoicing, CRM, reporting?

A simple booking form doesn't answer any of these. It just creates a new front end to what was previously a phone call or an email. The operational complexity doesn't go away — it just becomes more structured, and often more visible.

This isn't an argument against booking features. It's an argument for defining what "booking" actually means for that business before building anything.

What gets defined late tends to get built wrong

The reason this matters practically: changes are significantly cheaper before development starts than after.

If the scope of a booking system isn't defined upfront — whether it needs an admin interface, what data it captures, how it integrates with existing tools — you end up making those decisions mid-build. Which usually means scope creep, timeline extensions, and a system that works technically but doesn't quite fit how the business operates.

The same applies to any functional element of a B2B website: contact forms, quote request flows, user portals, or content management. Each of these has downstream operational implications that are easy to underestimate when you're looking at a list of features.

A different way to start the brief

Rather than beginning with pages and sections, it tends to be more productive to start with a handful of specific scenarios.

Walk through what happens when your ideal client finds the website. What do they do first? What question do they have that the homepage needs to answer? If they want to find out more, what path do they take? What information do they need before they'll make contact?

Then walk through what happens internally when that contact comes in. Who receives it? What do they do with it? What information do they need from the client to move forward?

This process usually surfaces the structural decisions that need to be made before design begins — and often before the brief is formally written.

The cost of skipping this step

Projects that skip this step tend to converge on a common pattern: the build is completed, the design looks solid, and then the internal adoption is harder than expected.

Features that seemed important in planning don't get used. The enquiry flow doesn't quite match how the sales team actually works. Content management becomes someone's second job because the system wasn't built around how they operate.

None of this is a design failure. It's a scoping failure — and it's almost always recoverable earlier in the process than later.

---

Webpreme approaches business websites as operational tools, not just design projects. If you're starting a website project and want to think through the structure before the brief is locked, we're happy to have that conversation.