'Guaranteed results' sounds reassuring until the buyer asks what result is being measured and who controls it. For a website project, a useful promise describes the work to be delivered and what happens if an agreed element fails acceptance.
Check the real path
- Write observable acceptance criteria for pages, links, forms, responsive layouts, and handover items in the proposal.
- Separate an in-scope defect from a new feature request, content change, or third-party failure.
- State how a problem is reported, who triages it, and the correction window agreed for that project.
- Keep sales, search-ranking, and uptime claims out of the promise unless the provider can measure and control them.
Decide what to change
A correction period can be useful, but no universal number fits every contract. The parties should agree the period and support route before launch. A blog article does not change signed terms.
Put it in the project brief
Before paying for a fix, ask the provider to name the affected page or workflow, the change they will make, how they will test it, and which dependencies or exclusions could change the estimate. Keep the baseline and the completed test so both sides can see what improved.
How ARCHV can help
ARCHV's public website process says the proposal defines review, handover, and after-launch support. The exact correction period belongs in the project agreement. Share the current page and the problem through ARCHV's website estimate form. If you are an agency seeking delivery support, see the partner route.