A dumpster rental is simple on the day it is dropped: a container, a date, a price. By the second week the customer has called twice, the box has been swapped once and the pickup has moved. Three records describe that rental, the term, the pickup job and the invoice, and the mistakes in this business come from updating one of them and not the others.
The term is the truth
A rental term carries the container, the start date, the expected end date, the included days, the day rate past them, and the disposal model. Everything else reads from it. The nightly process that flips a rental into overage reads the term's end date; the final invoice reads the term's days and rates; the portal shows the customer the term's pickup date. If the term is right, the rest follows.
Extensions move the end date, not just the pickup
The customer calls Thursday to keep the box through next Wednesday. The easy mistake is to reschedule the pickup job to Wednesday and leave the term's end date on Friday. Friday night the term goes into overage, the customer is quoted five overage days they were told they would not pay, and the office spends Monday morning on the phone.
An extension changes the term's end date, and the pickup follows it. If the customer is paying extra days by agreement, the day rate applies from the new end date, and the invoice says so. The server should refuse an extension to a date in the past or earlier than the current end, and it should re-read the current end date when the request is actioned, not when it was typed, because two people can extend the same rental in one afternoon.
Swaps continue the term
A full box out, an empty box in. The customer is on the same rental, the same days, the same rates; the only thing that changed is which container is on site. The outgoing container goes to the landfill as a pull with its own scale ticket and disposal line; the term now points at the incoming container; the pickup at the end is a pull too. On the invoice the customer sees one rental with two disposal lines dated by pull, which is what happened.
Do not model a swap as a new rental. It doubles the container charge and resets the days, and the customer notices both.
Overage days are a meter, not a penalty
Each day past the end date, with the container on site, is a day at the overage rate. Count it from the end date the customer was last told, in your company's time zone, not the server's. A pickup that completes at 7 pm on the end date in Denver should not be billed one overage day because it was already tomorrow in London. The ledger should show every rental in overage with the days so far, so dispatch can book the pickups before the number gets embarrassing.
Let the customer do it from the portal
Most of these calls can be requests: a new rental, a swap, a pickup, an extension. A portal that takes them, shows the status and lets the customer cancel one that has not been scheduled yet replaces the morning's phone calls with a queue the office works in order. One open request per rental per kind, so a customer cannot queue three pickups; a request to move a pickup to the date it is already on just confirms it. When the office books the job from the request, the request closes itself when the job completes and reopens if the job is cancelled, so nobody has to remember to update it. The portal post covers the rest of what a customer should be able to do.
The final invoice
Container, included days, overage days at the day rate, and every pull's disposal from its ticket. If a pull's ticket is still out, the final should wait and say why; the scale ticket post covers that. If the customer prepaid a deposit, it is credited on the final, not refunded separately. And if the rental's pricing was on included tons, each pull's line shows only the overage, as the pricing post describes.
