From worklogs to customer entitlements: support contracts inside JSM

TL;DR

• The situation. JSM records worklogs accurately, but a worklog does not know what the customer bought.
• The failure mode. The agreement sits in a document, usage sits in worklogs, the balance sits in a spreadsheet, and the customer waits for someone to reconcile them.
• The release. Support Time Contract Management for JSM now models three distinct promises: Fixed Term, Recurring, and Hour Bank.
• The shared view. Service teams see status, progress, remaining hours or days, and expiry risk in one dashboard; customers can see the same contract position in the JSM portal.
• The decision rule. Choose the contract by what ends or renews the promise: a date, a recurring period, or a purchased pool of hours.

A customer on a 20-hour monthly retainer closes the week with three open requests. They ask a simple question: “How much support time do we have left?” The agent sees fourteen worklogs. The service owner opens a spreadsheet. Finance checks the contract document. The customer sees the tickets, but not the answer. The work is recorded. The entitlement is not.

That distinction is the entire problem. Jira Service Management is very good at recording who worked, where, and for how long. It does not, by itself, know whether those hours belong to a monthly allowance, a date-bound engagement, or a prepaid bank that ends when its balance reaches zero.

A worklog tells you what happened. A support contract tells you what was promised.

A worklog records effort. A contract defines permission.

This gap appears repeatedly in practitioner discussions. One Atlassian Community user described two common commercial models: a set number of hours per month and a bulk package that remains available until it is used. Agents could log time in JSM, but there was no customer allowance against which to benchmark it.

That missing layer creates four different questions:

• Delivery: how much work has the team performed?
• Entitlement: how much work was the customer entitled to receive?
• Commercial: what is included, what has expired, and what is chargeable next?
• Trust: can the customer see the same answer before the invoice arrives?

Treat those as one “time tracking” problem and the spreadsheet returns. It has to. A timesheet can total hours. It cannot infer the commercial rule that gives those hours meaning.

Small service teams describe the same split in plainer terms: ticketing in one tool, retainer tracking in another, and a manual decision at month-end about what was covered and what was extra ^[2]. Agencies report an even wider version — tasks in Jira, contracts in documents, and the financial picture in Excel.

The problem is not missing data. It is missing context.

The contract model is the business rule

Support agreements that all contain “hours” can still behave very differently.

One ends on 31 December whether the customer uses ten hours or one hundred. Another refreshes on the first day of every month. A third has no meaningful calendar boundary at all: the customer bought fifty hours, and the agreement remains active until those hours are gone.

Putting all three behind one generic “contract” type hides the rule that matters most.

The new Support Time Contract Management experience makes that rule explicit. The dashboard identifies the contract model, shows the applicable remaining value, and makes the relevant expiry condition visible next to the work.

Three contracts, three promises

1. Fixed Term: the calendar defines the commitment

Use Fixed Term when support is available within a defined service window.

With Contracted Hours enabled, the agreement has both an hours allowance and an end date. It expires when the hours are exhausted or the date is reached. The dashboard shows the hours target, logged hours, remaining hours, and progress.

With Contracted Hours disabled, the agreement becomes date-only. Jira worklogs are still collected, so service owners retain an effort record, but there is no artificial hours target. Progress follows elapsed calendar time and the contract expires on its end date.

That distinction matters for warranties, hypercare periods, temporary cover, and fixed-duration managed services. The service still consumes effort; the commercial promise is time, not a quota.

2. Recurring: the allowance renews

Use Recurring when the customer receives a fresh allowance every month or year.

The contract calculates eligible worklogs against the current period and renews the allowance automatically. Optional rollover carries unused hours into the next period. The Advanced edition can also limit how long rolled-over hours remain valid.

This is the model behind retainers and renewable support packages. It removes the monthly ritual of copying a contract, resetting a spreadsheet, and explaining why last period’s balance does or does not still apply.

Rollover is not a minor checkbox. It is a commercial policy. Practitioner discussions show that some providers allow unused time to accumulate, some cap it, and others use a strict “use it or lose it” rule. The system should apply the policy the contract actually contains — consistently, period after period.

3. Hour Bank: the purchased balance defines the commitment

Use Hour Bank when a customer prepays for a pool of support time.

There are two expiry rules:

• When hours are exhausted. The contract has no customer-facing end date. It remains active while hours remain.
• Hours or End Date, whichever comes first. The customer can use the balance only within an agreed window. The contract expires as soon as either limit is reached.

The second rule is where manual trackers tend to fail. A spreadsheet may show forty hours remaining while the agreement has only three days left. Both numbers are true; only one may matter first.

The dashboard and portal make that risk explicit by showing hours and days together.

The customer should not need your spreadsheet

Internal accuracy is only half the value. The other half is shared visibility.

Without a customer-facing view, a perfectly maintained worklog still produces the same awkward exchange: the customer asks how much time remains, the service team exports data, someone reformats it, and the answer arrives after the decision it was meant to inform.

Community practitioners describe this as an accessibility problem rather than a tracking problem. The records exist; customers cannot see them when they need them.

Hours-based contracts show consumed and remaining hours.

• Date-only Fixed Term contracts show elapsed and remaining days.
• Hour Bank contracts with dual expiry show both hours and days in one gauge.
• Expired contracts show a clear expired state instead of leaving the customer to interpret a zero or a date.

The customer does not need access to internal reporting. They see the agreed commercial position where they already raise and follow requests.

Transparency becomes part of the service, not a report someone remembers to send.

Why this matters operationally

The obvious benefit is less administration. The more important benefit is earlier action.

When remaining entitlement is visible while work is happening, teams can:

• discuss an extension before a bank reaches zero;
• re-scope lower-priority work before a date-bound contract expires;
• identify customers consistently exceeding a recurring allowance;
• distinguish billable work from non-billable activity using worklog rules;
• apply the agreed rounding policy instead of correcting invoices later;
• give support, account management, and finance the same operating number.

That protects margin without turning agents into accountants.

The calculation stays anchored to Jira worklogs. Contract filters select the customer work that counts, using standard fields or Advanced JQL. The Advanced edition can include or exclude worklogs by comment prefix and round entries to configured time blocks. Recalculation and export tools give administrators a controlled way to rebuild or take the data downstream.

The app is not a second ticketing system. It is the commercial context Jira worklogs are missing.

Choose by what ends the promise

Choose the model by asking one question:

What event changes the customer’s right to receive more work?

Do not choose by which form looks familiar. Choose by the commercial event your team must honour.

Start with one contract

Start with one contract whose scope is easy to verify.

Map it to a narrow set of Jira issues. Add a test worklog. Confirm that Logged Hours, Remaining, Progress, and Status change as expected. If customers should see the position, enable Contract Metrics Visibility and open a matching request in the portal.

Then agree the operating rules:

• Which projects and organizations are in scope?
• Which activities are non-billable?
• Are worklogs rounded?
• Do recurring hours roll over, and for how long?
• Who acts when a balance or end date approaches?
• Does the customer-facing description explain what the contract covers?

The contract is only as useful as the decision it triggers. “Ten hours remaining” should lead to a renewal, a re-scope, or a deliberate decision to continue — not another spreadsheet.

The contract belongs next to the work

Most teams do not need another way to record time. Jira already records time.

They need the layer that says what the time means: which customer promise it belongs to, what remains, what ends it, and who can see the answer.

That is the value of managing support contracts inside JSM. The worklog and the commercial rule stay together. Service teams act earlier. Customers get fewer surprises. Finance receives a cleaner story. The contract stops being a document reviewed after the fact and becomes a live part of service delivery.

Put the promise next to the work.

Put the contract next to the work.

view26 Support Time Contract Management for JSM connects customer entitlements to Jira worklogs, monitors remaining hours or time, and shares the same view in the customer portal. Explore Support Time Contract → https://marketplace.atlassian.com/apps/1228498/view26-support-time-contract-management-for-jsm