Picture a team that delivers IT work for another company: an IT partner, an MSP, a software vendor, or an in-house IT team serving the rest of its own organization. Throughout the year the customer raises requests through the Jira Service Management portal, a small enhancement here, a new integration there, a report someone needed for one meeting in spring that has probably done its job by now. By autumn the list has grown into a mix of things that were delivered, things still waiting, and things that were important at the time and are now simply old.
Before the annual planning meeting, someone on the delivery side, usually a service delivery manager, a project manager or a support team manager, needs to know which of the open requests are still relevant and how much they matter today. If the customer hasn’t gone through their own list first, that job lands on the delivery manager, who ends up chasing people by email and guessing, and the planning meeting becomes a cleanup session instead of a planning one. If your budget follows the calendar year, sign-off is close, so the review has to happen in the next few weeks.
Why the customer has to do the review
The delivery side knows what it has shipped and how much capacity it has, but it can’t see inside the customer’s business. It can’t tell that the person who asked for a request has left, or that a new regulation has suddenly made another one urgent. Only the customer can say how much each request matters to them today, so the review starts with their business priority. Scheduling and capacity stay with the delivery side, and the customer’s priority is something to plan around, not an order.
Where the process usually breaks
The native portal gives customers a requests list they can filter by status and request type, with a small set of predefined columns chosen by the admin. It is built for following up on individual requests, so it doesn’t show SLA status or custom fields next to each one, and customers can’t update anything from it. Forms are the native workaround for changing a submitted request, but they work from inside each request, so a customer with fifty open items would need to open fifty of them.
In practice the list usually leaves Jira altogether. It goes out as an export, comes back by email or in a shared sheet, and someone on the service team re-enters the answers in the days before the meeting, which is rarely the highlight of anyone’s week.
What changes with Advanced Portal Reports
Advanced Portal Reports adds a report view to the portal. With the Standard Edition, customers see all their requests in one place, with the custom fields and SLA status you choose, full-text search, filters and saved views, and admins can publish a Global View with the right filters and columns already set and share it by link.
The Advanced Edition makes that same view editable: an admin chooses which fields portal customers can change directly in the report, and customers don’t need a Jira license to do it.
For this use case, the admin publishes a Global View called something like ‘Planning 2027’, filtered to the open enhancement and change requests, with four columns relevant to the prioritization process: Keep in 2027, Priority, Estimate needed and Estimate (days).
For each request, the customer can:
- Say whether they want to keep it in 2027, with Yes, No or Not sure. A request marked Not sure can still be sent for an estimate, because the cost is often what settles the question.
- Update the Priority, which reflects how much the request matters to their side. The delivery team still decides what to schedule, and the customer’s priority feeds into that conversation.
- Ask for an estimate with a Yes or No when they need a cost to decide. The service team then fills in Estimate (days), a number field, and the customer sees the answer in the same list. Estimate (days) is shown in the report but isn’t enabled for editing, so the customer sees the estimate and only the service team can change it. A rough estimate is enough at this stage, because the aim is to see what fits the budget and not to commit to a delivery plan, and the Yes or No keeps the work limited to the requests the customer still wants priced.
This is meant for requests that live long enough to be planned, such as enhancements, change requests and project demands, and not for incidents. Every change is logged with who, what and when, admins can export the log, and the service team sees each edit as an internal comment on the request in Jira, which stays the system of record.
Before you send the link
The most important preparation is not technical: find out who on the customer side will actually do the prioritization. It is rarely everyone. It is usually one or two people, or a small group, and over a year the people who raised the requests may have changed roles or left the project. So ask the customer who will go through the list and update the fields, and check that they are still the right people.
Once you know, the Jira administrator sets it up in the app’s project configuration. The first step is the same for both editions: add the fields to the report so they show as columns, which here means Keep in 2027, Priority, Estimate needed and Estimate (days). In the Advanced Edition settings, the admin then makes Keep in 2027, Priority and Estimate needed editable, leaves Estimate (days) as display only, and chooses who can edit, either specific people or user groups, and in which statuses. That way only the people the customer named can change anything, and only on the requests that are meant to be planned.
After that, the service delivery manager sends one message with the link to the view and a deadline, for example: ‘Before we plan 2027 together, please go through your requests here by [date].’ The service team closes what is marked No and adds estimates where they were asked for.
What the planning meeting looks like
Both sides sit down with the same list, with the keep decision, priority, owner and estimate already filled in, and the meeting can go straight to the budget conversation, which is a much nicer way to spend it.
Next step
Once customers have confirmed which requests still matter and the delivery team has added the estimates, both sides have a clearer picture of what the start of the year could look like. The next step is to bring priorities, costs and available capacity together to decide what can realistically be delivered within the budget.
If you want to try this before your own planning meeting, you can start a free Advanced Edition trial from the Atlassian Marketplace.
