“It loads” is a very low bar.
Open the homepage. It appears. The website must be working.
Now try to request a quote. Check whether the message arrives. Look for the service you actually want to sell. Complete a purchase on a phone. A site can pass the first test while failing several of the ones a customer depends on.
A broken website is not always a blank screen. Sometimes it is a form that quietly loses inquiries, a booking link leading nowhere, or information your team has to correct on every call. Those problems deserve attention even when the logo still looks excellent.
Count the costs you can actually see.
Start with documented costs: emergency repair work, time spent re-entering information, avoidable support calls, and advertising that sent visitors into a known broken journey. Be precise about the period and the evidence.
For example, if your team spends two hours each week correcting an order export, record those hours and the work they displace. That does not automatically make a complex integration worthwhile. It gives you a realistic problem to compare against the cost of a fix.
Keep confirmed spending separate from estimates. If a campaign ran during an outage, you can identify the affected spend. You cannot assume every click would otherwise have become a sale. Dramatic arithmetic is still arithmetic with assumptions.
Missing opportunities are harder to price.
Someone who cannot find the right service may leave without telling you. A visitor who abandons an awkward form might have been a good prospect, or might not. Your analytics cannot read their mind.
Use the evidence available: customer complaints, failed submissions, checkout errors, sales feedback, and changes in completed actions. If you estimate lost opportunity, state the assumptions and use a range rather than presenting it as money you definitely lost.
Check what happens after the website does its part, too. An inquiry that reaches an unattended inbox is a business process problem as well as a customer experience problem. Fix the whole handoff.
Repair in the order that matters.
Start with failures that block important customer actions or require urgent technical attention. Next, address inaccurate information and repeated friction. Put cosmetic refinements in their proper place alongside those priorities.
Reproduce the problem, decide what a successful fix looks like, and test the affected journey afterward. Include the confirmation message, notification, or back-office step rather than stopping at the button.
A focused repair may be enough. A rebuild becomes worth discussing when the existing setup cannot reasonably support the required changes, or when its accumulated constraints make maintenance impractical. The fact that a website has a problem is not, by itself, a brief for a new website.
Make checking part of the job.
Assign someone to review the important journeys and keep the content accurate. Agree which checks happen regularly and which should follow a release or a change to a connected service.
Clarify the boundary between hosting and ongoing care. Hosting makes the site available on its infrastructure; the particular maintenance, monitoring, and support tasks depend on your agreement. Confirm who receives alerts, who can investigate, and how recovery is handled.
Keep a record of recurring issues. It helps you decide whether you need a small correction, a different process, or a larger investment. A useful maintenance plan should make those decisions less frantic. It should not depend on a customer being the first person to tell you something is broken.
Put the thinking to work
Run one complete customer journey.
On a phone, start at a service or product page and complete the next step. Check the message, order, or booking at the receiving end. Assign an owner and priority to every issue you find.
Explore website care


