The website project is underway. Everyone liked the direction at kickoff, the schedule looked reasonable, and the team was ready to get moving.
Now the designer is waiting on product details. Marketing is waiting on the founder. The founder wants sales to take another look. Someone has suggested adding a resource library.
The launch date hasn't changed. Somehow, everything needed to reach it has.
You don't need a dramatic disagreement to lose a week. A few unanswered questions and a review that slips to next Tuesday can do it.
If you've already worked through The Decisions to Make Before Redesigning Your B2B Website, you should have a good starting point. The next challenge is making room for the work and handling the questions that come up along the way.
Here’s what that looks like.
“We have the content” needs a closer look
There's a difference between having information somewhere in the business and having material someone can use to build a website.
You might have a sales deck, a folder of product screenshots, and several customer quotes. That's useful. But which screenshots show the current product? Can the quotes be published? Does the deck describe the offer you're selling now?
Those questions don't require perfectly written website copy. They require someone who can tell the project team what they're looking at.
Imagine a page built around a customer story. The layout is ready, the copy is taking shape, and then someone realizes the customer hasn't approved being named.
Now you need permission, another example, or a different page.
Before work starts on that section, flag what is ready to use and what still needs checking. A shared folder with a few notes is enough:
- This deck is current.
- These screenshots need replacing.
- This quote is approved, but we can't use the customer's logo.
- Product needs to confirm this claim.
- We don't have photography yet.
Rough material is workable. Material that looks finished but hasn't been checked is harder to plan around.
If something is missing, say so early. Then you can decide whether to get it, work around it, or leave it out of the launch.
Someone has to make time for the review
Naming a decision-maker is a good start. That person also needs time to do the job.
A review landing in someone's inbox doesn't mean they've had a chance to review it. If they're traveling, closing out a quarter, or waiting on three colleagues, the project can sit untouched while everyone assumes it's moving.
Put the review dates on the calendar before kickoff. Know who needs to contribute and give them enough notice to participate.
If a key person is unavailable, work that into the schedule. It's better to plan around a known absence than discover it when a page is ready for approval.
The person leading the project on your side should also be able to resolve conflicting feedback. Forwarding five separate emails leaves the designer guessing whether the founder's comment overrides marketing's, or whether two people are asking for opposite things.
Have that conversation internally. Return one response that makes the decision clear.
That might be:
“We're keeping the headline. Please revise the supporting copy to explain the implementation timeline. Product has confirmed the details below.”
There's enough direction there to keep working.
Review the thing that's in front of you
Different stages need different kinds of attention.
When you're reviewing the page structure, look at what belongs on each page and whether anything important is missing. You don't need to settle the button color yet.
When you're reviewing copy, check the meaning. Is the offer accurate? Are the claims supportable? Does the language sound like your company?
When you're reviewing design, consider how well it presents the content and whether it feels appropriate for the business.
It's easy for a review to wander. Someone notices a phrase they dislike, which starts a discussion about the offer, which turns into a question about whether the whole page should exist.
Sometimes that discussion reveals a real problem. It deserves attention. But the team needs to recognize that it's reopening an earlier decision, with consequences for work already done.
A useful review should come with a clear question: what are we deciding here?
If that isn't obvious, ask before your team starts commenting.
Say what's bothering you, even if you don't know the fix
You don't need to speak like a designer to give useful feedback.
“The headline makes it sound like we only work with startups” is clear. So is “Our implementation support is important, and I barely noticed it on this page.”
Both explain a concern the designer can work on.
“Make the headline bigger” may be a reasonable suggestion, but it doesn't explain why. Are people missing the offer? Is the page difficult to scan? Does the opening feel too quiet?
Say what you noticed first. You can discuss the solution from there.
The same applies to personal preferences. You're allowed to dislike something. Just give the team a little more to work with than “I'm not feeling it.”
For example:
“This feels more casual than our sales conversations. The photography is probably the biggest part of that.”
That's a useful starting point. It doesn't require you to choose the replacement images yourself.
And if your team disagrees, don't hide the disagreement in a long comment thread. Work through it before returning feedback, or identify the specific question you need help resolving.
New ideas need a place to go
A website project will give you ideas. Once you see the new direction, you may start thinking about a resource library, another service page, a calculator, or a better way to connect the site to your CRM.
Some of those ideas will be worth doing.
The question is whether they belong in the current project.
A request that sounds small can involve more than it first appears. Adding a resource library, for example, raises questions about categories, content entry, page templates, search, and who will maintain it.
Before adding it to the launch, ask:
- What would be missing if this waited?
- Who will provide the content or requirements?
- What work does it add?
- Does it change the budget or launch date?
You may decide it's essential. That's fine. Adjust the plan openly.
You may also decide it can follow the launch. Keep it on a second-phase list so the idea isn't lost and the current project doesn't have to carry it.
If a request starts turning the website project into a larger identity change, pause and reassess. Does your B2B Company Need a Rebrand, or Just a Better Website? can help you work through what should stay and what needs more attention.
If something slips, update the plan
Even a well-organized project can run into a delay. Someone gets sick. A customer takes longer to approve a case study. A product detail changes.
Tell your project partner as soon as you know.
Then work through the actual options. Can another page move forward? Can the missing section launch later? Does the date need to change?
What doesn't help is leaving the original deadline in place while everything feeding into it moves.
If a review is late, the designer may not have the next day free to make revisions. If content changes after development, it may need another round of layout work and testing.
Those are scheduling questions you can solve together, provided everyone is working from the same information.
Make room for your side of the work
You don't need to write every word or arrive with every answer. You do need someone available to check details, gather input, and make decisions.
Before kickoff, take a realistic look at your team's availability. If nobody has time to review the work, a shorter production schedule won't fix that.
At Cohesion Studio, we agree on the materials, review milestones, and decision ownership before the sprint starts. You bring the knowledge of your business. I shape it into the messaging, design, and website, with clear points for your team to review along the way.
If you're planning a project, explore Cohesion Studio's brand and web sprint options to see how the work is scoped.