Prepaid Support Hours: Which Customer Package Should a Ticket Actually Consume?
A customer may have bought support hours without every new request automatically belonging to that package. Before adding a remaining-hours badge to a helpdesk app, specify which service purchase covers the work, when recorded time reduces it and what the team must do when the allowance runs out.
The useful distinction is between recording work and consuming an agreed service entitlement. A timer, a paid invoice and a response-time promise answer different questions. This guide helps define the operational workflow; your commercial terms, accounting treatment and any expiry or refund rules need their own professional review.
Make the purchased service identifiable
A package should refer to the customer and the particular service arrangement, not merely to a reusable field called “hours left” on the customer profile. A company may hold separate support purchases for different teams, products or periods. Staff need to know why a ticket belongs to one of them.
Odoo 19's track-and-bill documentation provides a concrete example. It distinguishes a service invoiced from recorded timesheets from a prepaid, fixed-price service product measured in hours. In the prepaid flow, the number of hours is supplied on a sales order before work is recorded.
That model explains why a ticket needs a link to a purchased service line. It does not establish that every confirmed purchase has been paid or that any ticket is contractually eligible. Define those activation and coverage rules separately. Do not label an unpaid or unreviewed purchase as an active entitlement merely because a record exists.
Do not mistake automatic selection for a coverage decision
In the documented Odoo prepaid-ticket flow, adding the customer automatically populates the Sales Order Item field with the most recent prepaid item that has time remaining. That is a selection rule, not proof that the selected purchase covers the requested work.
For your own setup, demonstrate a customer with more than one eligible-looking purchase. Can staff see the selected service, the relevant terms and the reason it was chosen? Who may change the allocation? What happens if the chosen package is for another service or is no longer valid under your agreement?
Require an explicit unresolved state when no applicable purchase is established. A system should not quietly take hours from a different company's package or sell another package without the agreed authority. These are requirements to commission, not verified safeguards of the cited platform.
Define the event that consumes the allowance
Odoo describes recording an employee, work description and hours spent on a ticket's Timesheets tab. Adding entries updates its remaining-hours field and the Delivered field on the related sales order. This demonstrates a concrete connection between ticket work and the purchased-hours record.
Your business must still decide which work counts. Are investigation, meetings, internal corrections and travel included? Does an entry consume hours immediately, or only after an agreed review? A customer's package must not lose hours simply because an internal retry created a duplicate time entry.
Keep recorded duration and chargeable package consumption distinguishable if your terms treat them differently. If work is corrected or moved to another ticket, show the effect on the relevant allowance. Preserve the original relationship and the authorised correction according to the agreed history and retention policy. Do not silently rewrite already communicated usage.
A red remainder does not prove an enforced stop
The Odoo guide says the remaining-hours value turns red when recorded hours exceed those sold. That documents a warning state. It is not evidence that the platform prevents further work, obtains a customer's approval or creates a permitted additional charge.
Decide what your business actually wants at exhaustion: a staff warning, a supervisor decision, a request for customer authorisation or another supported route. Define the treatment of work already underway. A strict technical stop and a commercial request to pause are not interchangeable.
Two staff members may work on different tickets against the same package. The remaining position should therefore be checked across its contributing work, not independently treated as available in full on each ticket. If you require a hard consumption limit, ask how concurrent entries and corrections respect it. Do not assume that a coloured badge enforces shared capacity.
Keep time promises, service outcomes and package balances separate
Unused hours do not establish that a response deadline has been met. Conversely, a solved ticket does not prove its work has been allocated correctly. Preserve each outcome with its own meaning.
Also decide what happens when a package reaches an agreed end date with hours still unused. Do not invent automatic expiry, rollover or refund behaviour from the quantity field. Have the responsible person approve the actual rule, then show how staff and customers can understand it. The cited Odoo passage does not supply a universal expiry policy.
A top-up needs a clear identity as well. Explain whether it creates a new purchase or changes an existing arrangement, which balance will be used next and what the customer sees. Avoid a single editable total that cannot explain where the allowance came from.
Demonstrate the customer's full support story
Use fictional purchases and tickets in your acceptance criteria. Include competing service purchases, a ticket with no established coverage, ordinary time consumption, a correction and two tickets drawing on the same allowance. Show the chosen overrun policy and any agreed expiry or top-up path.
The reviewer should be able to trace the displayed remainder to the purchased service and contributing work without rebuilding it from emails. Bring the approved service terms and a blank usage statement to a helpdesk integration discussion. The deliverable is an explainable entitlement-to-work relationship, not merely a timer beside a declining number.