“Fix the website” is not a repair list. It is a broad instruction that can mean a corrected phone number, a working form, a changed page, a new image, a rewritten section, or a larger rebuild.
Marque & Heir recommends agreeing on the repair list before anybody starts changing the site. The list should name each defect, show the evidence, state the approved target, identify what the owner must supply, and explain how the live result will be checked.
That is an operating recommendation, not a rule for every business. Its job is to keep the repair tied to a visible problem and an approved finish.
Start with a defect, not a general complaint
Each repair item should describe one condition somebody can find again. “The site feels old” is an opinion. “The public phone number in the header does not match the owner-approved number” identifies a location, a current state, and a decision that can be checked.
Use plain fields for each item:
- the live page or site area involved;
- the current condition;
- the evidence used to record it;
- the approved target condition;
- the person responsible for the next move; and
- the check that will mark the item complete.
Keep the evidence narrow. A dated screenshot can show what a page displayed. A labeled test can show where a form submission arrived at that time. An owner-approved business record can show which public detail should replace the old one. None of those records needs to become a claim about traffic, leads, or sales.
Keep the current state and target state separate
A repair list should show what is live now and what the owner wants to be live after the work. Do not blur the two.
The current state belongs to the checked evidence. The target state belongs to the owner’s approval and the written scope. If the target has not been approved, mark that input as missing.
This separation also protects the status. A target shown in a working file is not a live correction. A staged page is not a published page. The repair becomes complete only after the approved target is live and the agreed check passes.
Gather owner inputs before the repair starts
The list should name those inputs beside the affected item. They may include approved wording, current contact details, a real image, account access, a destination link, a service decision, or the name of the person who receives a form or booking notice.
Do not hide a missing input in a general note at the bottom. Put it on the repair it holds. State who supplies it and what work waits for it. That gives the owner a direct question instead of a vague “pending” label.
For any business, coverage wording still comes from the owner’s approved facts. A repair does not create permission to add places or make the service area broader than the business has approved.
Name the permissions with the work
Access to edit a site and permission to publish a change are different responsibilities. The repair list should say who can provide access, who approves the target, who can make the change, and who can approve the live result.
If an outside account, embedded tool, or business-owned system is involved, record the boundary before repair begins. The website shop should not assume it may replace an account, redirect a destination, or expose information just because the page can be edited.
When permission is missing, hold the item. Keep the reason exact. “Owner approval needed for the new contact destination” is useful. “Waiting on website” is not.
Define the done check before making the change
The done check should match the defect. For a public fact, compare the live page with the approved record. For a link, open the live destination. For a form, send a clearly labeled internal test and confirm where it arrives. For an image, check the approved file on the live page and confirm that the caption or context is correct when one is required.
Write that check on the list before work begins. The person handling the repair then knows what evidence will close the item. The owner also knows what “done” means without having to judge a broad claim after the work is finished.
Keep the result bounded. A successful form test shows that the labeled test reached the expected destination at the checked time. It does not promise that every future submission will arrive or that a visitor will complete the form.
Put exclusions beside the repair
An agreed list should also show what the item does not include.
Correcting a phone destination does not automatically include rewriting the contact page. Replacing approved wording does not automatically include changing the page structure. Repairing one form does not automatically include moving every contact route into a new system. Those may be useful requests, but they are separate decisions until the scope says otherwise.
Write the exclusion in direct language. Marque & Heir uses that exclusion to hold the repair to its approved boundary and to give later work a separate owner decision.
Handle new findings without losing the original list
Repair work can uncover another problem. The agreed list should have a simple change path for that moment.
Record the new finding with its own evidence. Decide whether it blocks an existing repair, belongs in the current scope, or waits for a separate approval. Do not fold it into another item without changing the record. The original list should still show what was agreed, and the change note should show what was added, removed, or held.
Retest the live site, not only the working version
A repair can pass in a working view and still need a live check. After the approved change is published, repeat the done check on the live page. Use the public path a visitor would use. Record the checked date, the person who ran the check, and any remaining hold.
If the live check fails, reopen the item. Do not mark it complete because the working version looked right. If the live state cannot be checked because access, publishing, or another dependency is held, say that plainly.
Hand the owner a repair record
The handoff should be the agreed list with its final states, not a general message saying the site was fixed.
For each item, show the original evidence, approved target, owner input, permission, change made, live check, checked date, and any exclusion or remaining hold. Remove internal test records under the business’s approved handling process, but keep the short test result needed to explain what was checked.
The completed record does not turn repair work into a performance result. It shows which listed defects were addressed, which live checks passed, and which decisions remain with the owner.
Start with the free check, keep the findings, and put any website repair into an agreed scope before changes begin.