Four people, one transition
A transition goes wrong at the seams between roles. STR is built around those seams rather than around a single user.
Owns transition of new services into support
Service Delivery Manager
You are accountable for services you did not build, and asked in CAB whether they are ready — with a spreadsheet as your only evidence.
What they get
- A portfolio across every project on the site, with tiles for what is awaiting a gate and what is in warranty
- One consistent readiness standard, enforced by templates rather than by nagging
- A CSV export of the filtered view for the review pack
- Gate history per service, showing who decided what, when, and against which score
Runs individual transitions day to day
Transition / Project Manager
You are chasing knowledge transfer, monitoring onboarding and training across half a dozen teams, and reporting status by hand every week.
What they get
- Phased plans with owners, due dates and linked Jira issues
- Progress, overdue and blocked counts computed for you on every write
- A "my tasks" view across every service in the project
- A readiness score that shows the gaps early, while there is still time to close them
Receives services into business as usual
Service Desk / Operations Lead
Services arrive on go-live day whether or not you are ready for them, and the first you hear of a gap is when a customer reports it.
What they get
- A genuine veto at the gate, recorded with your name against it
- Exit criteria you define, that block handover until they are actually met
- A daily incident trend for the service, from your own JQL, over the whole warranty period
- An extension mechanism with a recorded reason, when the service is not ready to hand over
Configures and defends the Jira estate
ITSM Tooling Admin
Every new app is a security review, a vendor questionnaire, and a data-residency conversation you have had too many times.
What they get
- A Forge app with no external servers, no egress and no third-party processors
- Four scopes, each mapped to a single visible feature, and no admin scopes at all
- Data that stays in the customer’s Atlassian site and inherits its residency
- Template, threshold and archive actions gated behind existing Jira admin permissions
Who can do what
STR does not invent a permissions model. It defers to the one your Jira site already has.
| Action | Required |
|---|---|
| View services, scores, plans and the portfolio | Access to the Jira project or global page |
| Create and edit services, score assessments, manage plans and ELS | Any licensed app user with page access |
| Record a gate decision or sign off handover | Any licensed app user — the decider is captured in the audit trail |
| Archive a service | Jira project administrator |
| Manage readiness templates, thresholds and defaults | Jira site administrator |
| Set per-project configuration overrides | Jira project administrator |
Gate decisions are deliberately open to any licensed user with access, because in most organisations the person who chairs the gate is not the person who administers Jira. Accountability comes from the immutable audit record rather than from restricting the button. If you need role-restricted sign-off, tell us — it is a design decision, not a technical limit.
Bring the whole transition into one place
Bring readiness scoring, gate sign-off and early-life support into the tool your teams already run transitions in.
Free for small teams · 30-day evaluation on every paid tier