Why did this client project go over its agreed hours?
A practical method for tracing unbilled project hours back to the contract, the request and the work recorded, before making a client decision.
QAIZEN
Product team
- Compare the same client, project and period before interpreting extra hours.
- Connect the agreed scope, the change request and the recorded work.
- Keep the explanation and its human confirmations together for the next decision.
Start with a question the team can actually answer
“Why is this client less profitable?” sounds precise, but hours alone cannot answer it. Revenue, delivery costs and the comparison period matter too. A more useful first question is: why did this fixed-fee project use 60 hours when the contract included 40, and were the extra hours billed?
This is a fictional worked example. Atlas has a fixed-fee project with 40 hours included. The business records show 60 hours, including 20 hours tagged to an additional redesign. A Slack request and the agreed scope explain what happened. These figures illustrate an investigation, not a customer result.
1. Make the records comparable
Write down the client, project identifier, delivery period and contract version. Check that the 60 recorded hours belong to this project rather than support work, a previous phase or a different account with a similar name.
Separate actual hours from estimates. Also check for duplicate entries and late corrections. The arithmetic, 60 minus 40, establishes a difference of 20 hours. It does not yet explain that difference or establish a loss.
2. Give each source a specific job
Use the contract to establish what was agreed. Use the conversation to trace the additional request. Use the business records to identify the work performed and whether it was billed.
- Contract: the accepted scope and the 40 included hours, with its version and relevant section.
- Slack: the redesign request, its date, the people involved and any discussion of scope or price.
- Business data: 60 hours recorded, the 20 redesign hours and the billing information for that work.
A request in Slack does not, by itself, prove that a paid change was approved. If approval or billing evidence is missing, make that uncertainty explicit instead of filling the gap with an assumption.
3. Ask the people who can check the explanation
In this example, Alex checks the hours and confirms that the additional redesign was not billed. Sam checks the contract and confirms that this work fell outside the agreed scope. Each person confirms the part they can verify.
Keep the supporting references with their confirmations. If Sam disagrees with the scope interpretation, retain that disagreement and identify the next check. A confident sentence should not conceal an unresolved question.
4. Save an explanation that supports the next decision
The resulting answer can be short: “Atlas used 60 hours against 40 included in the fixed-fee contract. The additional 20 hours were an out-of-scope redesign and were not billed.” Keep the contract section, Slack request, work records, confirmation names and confirmation date attached.
Maya can then use that context to prepare the renewal. It supports a discussion about scope, approvals and future pricing. It does not tell Maya what price to charge or whether the client is profitable without the relevant financial inputs.
5. Recheck before carrying the answer forward
Before reusing it, verify that the question still concerns the same project and period. A new contract, a corrected time entry or a later invoice can change the answer. Access matters as well: finding a confirmed answer should not expose records that the person is not allowed to read.
Use the confirmed-answer record method to preserve that context. QAIZEN is developing an AI knowledge assistant for this workflow: find context across documents, conversations and business tools, then reuse answers checked by the team. The method above can already be applied to the records your team maintains today.