Features
What is in the register
ImproveDesk is deliberately opinionated. The data model follows the ITIL 4 continual improvement practice, and the rules that make the numbers defensible are enforced by the app rather than left to convention.
The record
Every improvement, fully described
One record holds the whole story: where the opportunity came from, who owns it, what it is worth, how it will be measured, and which Jira issues deliver it.
| Field | What it holds |
|---|---|
| Reference | Project-scoped and sequential — CSI-1, CSI-2 — allocated by the app, never by the client. |
| Title and description | What the opportunity is, and what evidence prompted it. |
| Source | Where it came from: incident, major incident review, problem, change review, service review, customer feedback, survey, internal or external audit, management review, risk assessment, staff suggestion, supplier review, or other. |
| Category and service | Your own category list, configured per project, and the service affected. |
| Owner, sponsor and raised by | Accountability. Owner and sponsor are Jira accounts; raised by is stamped by the server. |
| Priority | Critical, high, medium or low. |
| Target date and review date | When it is due, and when its benefit is next reviewed. |
| Benefit case | Type, forecast value, realised value, cost estimate and a narrative. |
| Measures (KPIs) | Baseline, target and actual per measure, with correct handling of lower-is-better measures such as MTTR and incident volume. |
| Prioritisation inputs | Reach, impact, confidence and effort for RICE; value, effort and risk for the composite score. |
| Linked Jira issues | The delivery work that implements the improvement. |
| Tags and standard references | Free-text tagging, and the clause you are evidencing. |
| Risks and dependencies | What could stop it. |
The register
Find the improvement you are talking about
Filter by status, category, priority, owner or overdue state, and search across titles, references, tags and linked issue keys. Filtering is applied consistently across the whole predicate set rather than split across storage indexes, so the count you see is the count that exists.
- Search is debounced, so typing does not flood the register with requests
- Archived records are hidden until you ask for them
- Overdue is derived, not a field somebody has to maintain
- Export the current filtered view to CSV
Prioritisation
RICE and a composite score
RICE multiplies reach, impact and confidence and divides by the effort implied by the t-shirt size. Alongside it, a composite score combines the benefit case, the effort size and the record's priority, using weights you set per project.
An unscored improvement returns nothing, not zero. A record nobody has sized is never ranked alongside work that has been genuinely assessed as low value.
Benefits realisation
Forecast, realised, cost, net
Each improvement carries a benefit case. The dashboard rolls these into realisation rate, return on cost and net benefit — but counts realised benefit only from records that reached verified or closed.
Benefit types
Measures
Lower is better, when lower is better
Each measure carries a baseline, a target and an actual. MTTR, incident volume and change lead time all improve as they fall — so ImproveDesk asks whether a measure is lower-is-better and computes progress accordingly. A measure that has gone the wrong way shows as negative progress rather than quietly reading as an improvement.
| Measure | Baseline | Target | Actual | Direction |
|---|---|---|---|---|
| P1 incidents per quarter | 9 | 3 | 2 | Lower is better |
| Mean provisioning time (hours) | 26 | 4 | 5 | Lower is better |
| Change lead time (days) | 12 | 3 | 4 | Lower is better |
| First-contact resolution (%) | 61 | 80 | 74 | Higher is better |
Automation
The register tells you when it has stopped moving
Daily attention sweep
A scheduled job recomputes a per-project digest each day: what is overdue, what has gone stale, what is due for benefit review and what has no owner. The register shows it as a banner.
Weekly KPI snapshot
A second job persists the dashboard figures each week, which is what the trend is drawn from. Without it a dashboard can only ever show today.
A run log, as evidence
Every scheduled execution is recorded, successful or failed. If a sweep stops working, an empty run log proves the handler never completed — a digest that has stopped advancing otherwise looks exactly like a healthy backlog.
Absence is treated as evidence. The register banner states the age of the last sweep. A silent scheduled job is one of the few failures a user cannot see, so ImproveDesk surfaces it rather than letting it hide.
Export
CSV that is safe to open in Excel
Export the current filtered view — 34 columns covering the whole record, with user account ids resolved to display names.
Formula characters are neutralised. A register exported from Jira is
opened in a spreadsheet the same afternoon. An unescaped
=HYPERLINK(...) sitting in a free-text field is a live
spreadsheet injection, so leading =,
+, - and
@ characters are prefixed before the file is written.
Configuration
Per project, by an administrator
Categories, services, currency, review cadence, the stale threshold, the composite score weights and two approval policies — whether an owner and a benefit case are required before an improvement can be approved.
See how the lifecycle holds it together
The strict transition graph is what makes the benefit figures defensible. It is worth two minutes of your time.