What this template is for
Stakeholder requests are how teams get knocked off plan. A VP asks for “a quick dashboard”, three weeks evaporate, and nobody can remember why. This template makes each inbound ask an explicit intake ticket with routing rules attached - accept now, schedule for later, or decline with reason.
It is built for PMs and team leads who want intake to be a structured queue rather than a series of ambushes.
When to use it
Use this template for any unplanned inbound ask that would require team work. For asks that are already on the roadmap, point the requester at the existing Epic. For genuinely tiny asks (under an hour), do them and skip the ticket.
How to set it up in Jira
Create an intake project with the custom fields above on the Create Issue screen. Use Custom Fields for Urgency and Routing Decision select lists. Mark Requester and Requested Outcome required-on-create. Build a dashboard filtered by Routing Decision = “Accept now” to feed planning.
Sub-task breakdown
- Acknowledge is the SLA: every requester gets a response within one business day.
- Clarify outcome prevents accepting an ambiguous ask.
- Estimate effort and impact is the basis for the routing decision.
- Decide accept / schedule / decline is the routing.
- Communicate decision closes the loop with the requester.
- Create downstream issues turns accepted work into committed tickets.
Use STM Issue Templates to auto-create the sub-task list on every new intake issue so the SLA gates are always tracked.
Fields to add to your Jira create screen
These are the fields a project admin should make sure exist on the Create Issue screen for this issue type (Project settings → Screens). Without these on the screen, reporters can't provide the information triage needs - and STM can't reference them either.
| Field | Example value | Required |
|---|---|---|
Summary | Stakeholder ask - Custom dashboard for board meeting | Yes |
Requester Name (custom) | VP of Sales | Yes |
Requester Team (custom) | Sales leadership | No |
Requested Outcome (custom) | What does done look like? | Yes |
Business Justification (custom) | Why this, why now | No |
Urgency (custom) | Critical / High / Medium / Low | Yes |
Needed By (custom) | 2026-06-10 | No |
Estimated Effort (custom) | S / M / L | No |
Routing Decision (custom) | Accept now / Schedule / Decline | No |
Linked Work (custom) | Issues created from this ask | No |
Component/s | intake, stakeholder-requests | No |
Labels | intake, sales-request | No |
Attachments | Slack thread, email, supporting context | No |
Note on custom fields. STM currently supports up to 5 custom fields per template. You can add as many custom fields as you like to your Jira Create Issue screen - the 5-field limit only applies if you want STM to set or update those custom fields itself.
Sub-tasks STM creates automatically
Build an STM sub-task template containing the items below, then wire it to an On Create Issue Executor scoped to this issue type. Whenever a new issue of this type is created in the project, STM creates the full sub-task set in one step - with assignee, due date, and components inherited from the parent unless you override them.
- Acknowledge the requester within one business day
- Clarify requested outcome and constraints
- Estimate effort and impact
- Decide accept / schedule / decline
- Communicate the routing decision back to requester
- Create downstream issues for accepted work
Common questions
What is a Jira stakeholder request template?
It is a Jira issue for intaking a single inbound ask from a sponsor, exec, or another team. It captures requester, requested outcome, business justification, urgency, needed-by date, and routing decision. One issue per request gives the team an auditable intake queue rather than a chaotic inbox of Slack DMs and corridor asks.
How do you triage stakeholder requests in Jira?
Create an intake project. File one Jira issue per inbound ask using this template. Within one business day, acknowledge the requester and start clarification. Within five days, route the request - accept now, schedule for a future cycle, or decline with rationale. Link any downstream work created. Close the intake issue once routing is communicated.
Should stakeholder requests live in the team's main Jira board?
No - intake belongs on a separate queue from execution work. Mixing them makes the team's backlog look like a black hole to stakeholders, and the team feels constant pressure from un-triaged asks. A dedicated intake project (or a dedicated component) keeps the boundary clear: intake is for routing, the main board is for committed work.
What custom fields are required for a stakeholder request?
Requester, requested outcome, urgency, and needed-by date are the must-haves. Business justification, estimated effort, and routing decision are filled during triage. Use Custom Fields for Urgency and Routing Decision select lists. Required-on-create for requester and requested outcome so no anonymous, ambiguous asks land in the queue.
Automate the sub-tasks with STM
STM Issue Templates saves the sub-task list above as a reusable template and creates them on every new issue of this type - via an Executor on issue creation, on status transition, or triggered manually from the issue's "Create bulk sub-tasks" menu. STM does not change the parent issue's create screen (that's a Jira project-settings job) but it removes the manual work of creating the sub-tasks every time.
Try STM on the Atlassian Marketplace ↗ See how STM templates are built →