A customer asks for one more page, a different material, or an earlier delivery date. The request may be reasonable, but it still changes the project you estimated. A useful revision process makes that change visible before it becomes an unexplained charge or a scheduling problem.
You can prepare the updated document in the Trojan estimate generator. First, identify what changed and what it affects. Editing the total is the last part of the job, not the first.
Classify the change before pricing it
- Media
- Advertising spend.
- Landing page
- Work on the destination page.
- Measurement
- Tracking and review.
- Management
- Campaign planning and upkeep.
A changed quantity is different from a changed deliverable. Adding two more printed copies may use the same unit price. Adding a new design concept may require a separate item. A request to finish earlier may affect scheduling even when the final deliverables stay the same. Classifying the request helps you avoid treating every change as an arbitrary percentage added to the total.
Also distinguish a correction from new scope. If the original estimate has a typing error, explain the correction plainly. If your own description failed to reflect the customer’s documented request, review that history before describing the adjustment as an extra. The revision should reflect the facts of the project.
| Change | What to review | Where to show it |
|---|---|---|
| More units of the same item | Quantity and any agreed pricing effect | The existing line and revision note |
| A new deliverable | Work, price, dependencies, and timing | A new descriptive line |
| A changed material or specification | The replacement specification and cost | The affected line and assumptions |
| A different completion target | Availability and the schedule dependency | The timing notes and any agreed cost |
Record the request in one useful paragraph
Write down who requested the change, what they requested, and the date. Then describe its effect on the deliverables, expected price, and timing. This can be brief. A useful note says “Add a fourth service page using supplied copy; adds one page layout and a review step.” It does not say only “Updated per conversation.”
Keep the note close to the project record. If the request came through a call, send a written recap through your normal communication channel so the client can correct a misunderstanding. The purpose is a shared understanding, not a long administrative ritual for every minor clarification.
Show the difference as well as the new total
Suppose an illustrative estimate includes four display panels at $70 each, totaling $280. The customer requests two additional panels of the same specification. If the agreed unit price remains $70, the revised line becomes six panels and $420, a $140 increase. The revised document should make that difference easy to see.
Recheck the whole estimate after making the change. An added deliverable may also affect a setup fee, delivery arrangement, or scheduled review. Do not add charges that were never discussed, but do not ignore a real dependency simply because the first visible change was a quantity. Explain the relationship and let the customer review the complete proposal.
If an item is removed, make the removal equally clear. Deleting a row without a revision note can leave the customer wondering whether the work disappeared accidentally. A short “removed at customer request” note connects the new total to the decision.
Keep one current review version
- Observe → review
- Check the page and its evidence.
- Update → recheck
- Publish the change and check the result.
Use a stable estimate reference and a clear revision label, such as a version number or issue date. Preserve the earlier sent version in your records, but identify the new document as the one being reviewed. Avoid naming both attachments “final.” That word does not tell anyone which final file is current.
State whether the revision replaces the previous estimate or presents an alternative option. Those are different situations. A replacement asks the client to review an updated project. An alternative gives the client a choice between scopes. If the document is an option, label its total and contents so it cannot be mistaken for an additional charge on top of the base version.
Close the review loop before the next step
Ask the customer for a specific response: confirm the changed scope, select an option, supply a missing measurement, or arrange a discussion. Record the response and update the project’s current version. A revised PDF sitting in an email thread is not, by itself, a clear operating instruction for the person doing the work.
Share the current scope with anyone responsible for delivery and billing. The production team should not work from version one while the invoice is prepared from version three. This is where a small version habit can prevent a larger handoff problem.
Export and check the revision
Save the estimate through the browser’s print workflow and inspect the actual PDF. Check that the changed line, revised amount, notes, and version label are all visible. The browser print action opens the device’s print dialog; MDN explains that behavior.
If you are building the first version, start with how to write a reviewable project estimate. Before billing, read when to use an estimate or invoice. For website projects, Trojan’s design services and the guide to small business website costs can help you define the original scope carefully enough that a later change has something clear to be compared against.