"While you're in there, could you..."
The build is halfway through. The client emails: could the team page have a filter by department. Two days later: could the contact form ask how they heard about us. Then: the MD saw a competitor's site with a map of locations, can we have one. Then: can the blog have categories after all.
The developer does the first two because they take an hour each and the client is pleasant. The map takes a day. The blog categories touch the templates, the design and the menus. By launch, the project has quietly absorbed a lot of unplanned work. The final invoice is the one in the proposal, and the project made little or nothing.
Why changes slip through unpriced
- Requests arrive by email, phone and comments on the staging site, straight to whoever the client talks to.
- Developers are asked directly and say yes to keep the client happy.
- Each change is small, so raising a quote feels petty.
- The approved scope is a proposal PDF, and nobody checks requests against it.
- There is no quick way to price a change, so pricing it feels like more work than doing it.
The agency is not bad at saying no. It simply has no easy way to say "yes, and here is what it adds".
What unpriced changes cost
Fixed-price projects run over, and the loss is only seen at the end. Launch dates slip because of work that was never in the plan, and the client may still blame the agency for the delay. Developers get frustrated at moving targets. The client never learns that their requests had a cost, so the pattern repeats on the next project.
The change request log we build
- The approved scope is recorded as a list of pages, templates and features at sign-off, so there is something to compare against.
- Any request from the client, whether by email, a form or a comment on staging, is logged as a change request against the project. Emails to a project address are logged automatically.
- The project manager marks each request as in scope, a change, or a phase two idea.
- For changes, the developer adds a quick estimate in hours or as a size band, and the system turns it into a price using your rates.
- The client receives the change with its price and impact on the timeline, and approves or declines it on a link.
- Approved changes are added to the project plan in your project tool and to the final invoice. Declined ones go to a phase two list.
| Request | Classification | What happens |
|---|---|---|
| Fix a typo on an approved page | In scope | Done, no approval needed |
| Add a department filter to the team page | Change | Estimated, priced, sent for approval |
| Locations map on the homepage | Change | Estimated, priced, with timeline impact |
| Rebuild the blog with categories | Change or phase two | Client chooses now or later |
Many changes are worth doing for free as goodwill. The log lets you do that on purpose and record it, instead of by accident.
The same project with a log
The client asks for the department filter. The project manager logs it, the developer sizes it, and the client receives a small price with an approve button. They approve. The map request comes with a price and a note that it would move launch, and the client decides it can wait for phase two. At launch, the final invoice includes the approved changes, and the phase two list becomes the start of the next conversation.
Is your build absorbing changes?
- Clients ask developers directly for extra features.
- Small changes are done without a price because quoting feels petty.
- Fixed-price projects regularly run over.
- The approved scope is a PDF nobody checks requests against.
- Final invoices rarely include extra work.