Your first 30 days with an inherited B2B website

Days 1–5: establish ownership and access

Create an ownership register for the domain, hosting, content system, source files, analytics, search reporting, forms, and customer relationship management system. For each, record the business owner, administrator, renewal responsibility, and recovery route. Keep credentials in the company's approved password manager rather than in the register.

Confirm that someone on the current team can publish and restore a change. Ask the outgoing owner or vendor to demonstrate the process. A folder of design files does not explain how the production website is maintained.

Collect existing agreements and identify what support remains available. Resolve access gaps before starting a new build. Record unknowns plainly so they become assigned tasks instead of background anxiety.

Days 6–10: follow one inquiry all the way through

Choose a priority audience and enter the site through a page that audience actually encounters. Read the page, follow the main action, submit an authorized test inquiry, and check the receiving system with its owner. Mark test records clearly and remove them according to your team's process.

Check what the visitor sees after submission, where the inquiry arrives, who is notified, and how the next response happens. Test a mistake as well as a successful submission. A confirmation screen alone does not prove that the lead reached the right person.

Write the journey as a short sequence with evidence attached. For example: campaign page, demo form, confirmation, CRM record, assigned sales owner. A broken link in that sequence is a more immediate priority than a disagreement about the homepage photograph.

Days 11–15: build a baseline you can explain

Save a dated snapshot of the priority pages, current messaging, available traffic reports, known inquiries, and open technical issues. Describe what each metric counts. A form submission, a sales-accepted inquiry, and an opportunity belong in different columns.

Review the previous period for campaign changes, outages, and missing tracking. If collection is unreliable, label the baseline incomplete. You can improve instrumentation now without inventing a historical comparison.

For loading and responsiveness, separate controlled diagnostics from real visitor measurements. Google's Web Vitals documentation distinguishes field and lab approaches. A local test helps investigate a problem; it should not be presented as the experience of every visitor.

Ask sales and customer-facing colleagues for recurring questions, then trace each question to the page intended to answer it. Treat their observations as leads for investigation, not a representative survey of all buyers.

Days 16–20: choose one useful first change

Sort candidate work into three groups: failures that stop a task, confusion that blocks a decision, and improvements whose value is still uncertain. Put evidence beside each item and name the smallest change that addresses it.

Hypothetical example: a product page invites visitors to see a demo, but the destination is a general contact form with no explanation of the meeting. A first change could align the button, form introduction, and confirmation message around that specific request. It does not require replacing the entire site.

Choose a change you can finish, verify, and explain within the available time. Define success initially in terms you can observe, such as correct routing and a clear next step. Any claim of improved conversion requires additional evidence.

Days 21–30: ship, verify, and establish a working rhythm

Give the selected improvement a brief owner, a content approver, a delivery owner, and an acceptance checklist. Walk through it in staging, then verify the live experience after release. Capture the date so later reporting can distinguish the periods.

Create a single backlog with the next few priorities. Each item should include the buyer problem, supporting evidence, dependency, estimated effort, and intended observation after release. Avoid a long undifferentiated list of everyone else's preferences.

Agree how new requests enter the queue and when priorities change. A small team can use a short weekly review: what shipped, what is blocked, what changed, and which decision is needed. The meeting should produce an ordered queue.

Leave the month with a one-page decision record

• Control: accounts and publishing responsibilities are assigned; remaining access gaps have owners.
• Buyer path: one priority journey has been tested through receipt and follow-up.
• Evidence: the baseline lists its definitions and known gaps.
• Delivery: one completed improvement has a release date and verification record.
• Next decision: the team knows whether it needs targeted work, ongoing help, or a broader rebuild.

If a rebuild is justified, the month has produced better inputs for a website project brief. If it is not, you have avoided making a major commitment before understanding the operating problem.