A new starter opens your JSM portal on day one, needing a laptop and VPN access. They can't tell whether "Hardware request" or "New joiner setup" is the right form, so they pick the wrong one, it gets bounced between queues for two days, and eventually someone resolves it. Your CSAT survey fires on resolution. They give it a 3.
That 3 goes into your average next to "agent was slow." It wasn't the agent. It was the portal: confusing request types, a knowledge base article that's two years out of date, a search that returned nothing useful. Your ticket survey has no way to tell you that, because it only ever asks about the ticket.
The problem: ticket CSAT only hears from ticket raisers
Standard JSM CSAT is transactional. It's attached to a request and asked once that request is done. That's the right design for measuring how a specific resolution went — but it leaves some large gaps when you're trying to work out whether the portal itself is doing its job.
You never hear from people who gave up. Someone searches your help center, doesn't find the answer, and emails a colleague instead, or just lives with the problem. No request was created, so there's nothing to survey. These are exactly the users whose experience you most need to understand, and your data has none of them.
You never hear from people who succeeded. Plenty of people land on a knowledge base article, fix their own problem, and leave. That's the portal working well. It also generates zero feedback, so self-service wins are invisible when you're trying to justify the time spent maintaining articles.
Portal problems get blamed on agents. When the only question you ask is "how satisfied were you with this request?", every bit of friction along the way — the wrong form, the confusing field, the unanswered search — gets rolled into one number that looks like an agent performance score. Nobody can act on that. The agent didn't write the form.
"Feedback" ends up in the wrong place. With no dedicated channel, people with portal feedback raise it as a request: "the VPN article is wrong," "can you add a category for X." Now it's sitting in the same queue as outages and access requests, competing for triage time.
The underlying issue is that you're asking one question in one place and expecting it to cover two different things: how did this request go and how is the portal working for you.
The fix: separate request feedback from portal feedback
The practical answer isn't a bigger ticket survey. It's a second, separate feedback channel that sits at the portal level and isn't tied to any request's lifecycle. Keep your ticket CSAT exactly as it is — it measures something useful — and add a portal-level survey alongside it.
Here's how to set that up without muddying your existing numbers.
1. Decide what you're actually asking
Portal feedback works best with one narrow question. "How easy was it to find what you needed today?" tells you something specific about navigation and self-service. "How satisfied are you with IT?" tells you almost nothing, and overlaps with the relational question NPS already covers.
Pick the question first, then pick the input to match. An effort-style question suits a 0–10 scale; a quick "was this helpful" check suits a star rating; and if what you really want is suggestions ("what's missing from this portal?"), a comment-only survey with no score avoids forcing people to put a number on an open question.
2. Use a project-level survey, not a request-level one
In Myra, every Feedback Survey has a scope, and this is the decision that matters most here:
- Request scope ties feedback to individual requests. It's collected in the context of a specific ticket — this is what the built-in CSAT survey uses.
- Project scope collects feedback directly on the portal page and is linked to the project the survey was created in.
- Public scope lets you collect feedback anywhere you embed Myra as a widget.
For portal feedback, Project scope is the one you want. People can leave a rating on the portal itself without having raised a ticket, and the responses still land in Jira against your service project.
To create it, go to the Settings tab and click + New. You'll set a name (lowercase letters, numbers and hyphens — csat and nps are reserved), the display text, the question, the field type (Rating, Number Pick or None), the scope and the calculation strategy. Take a minute on the last few: the name, scope and calculation strategy can't be changed after the survey is created. For a portal survey, Average is usually the sensible calculation strategy for a rating or 0–10 score; None fits a comment-only survey.
3. Turn on comments
A portal rating of 2 out of 5 tells you something is wrong. It doesn't tell you what. Toggle Comments on in the survey's configuration so people get an optional text box to explain. On a portal survey, comments are where you'll find the concrete fixes — the broken link, the missing request type, the article that needs rewriting.
4. Set collection rules deliberately
Enable collection, then review the survey's Collection Rules. New surveys start with an Always Allow rule. Myra also offers rules such as Date Range, Day of Week and Last Submission, which is useful if you want to run portal feedback as a time-boxed exercise ("the two weeks after we restructure request types") rather than permanently. Not every rule applies to every scope, so check the rule and scope compatibility before relying on one. Also note that a survey with collection turned on but no active rules won't appear at all.
For people who never visit the portal, enabling collection on a Project-scoped survey also generates a Public Survey Link. You can drop it into an onboarding email or an internal newsletter, and responses route back to the same survey in Jira without the respondent needing Jira access.
5. Read it separately, and act on it
Open the Reports tab and select the portal survey. You'll get total responses, the feedback score, a rolling average graph and a breakdown of feedback volume by rating. Crucially, it's a separate report from your ticket CSAT, so a messy portal no longer drags down what looks like your agents' score.
When a comment points to something fixable, use the Actions menu on that feedback item to Create a linked issue or Link to an existing issue. "The VPN article is wrong" becomes a tracked task for whoever owns the knowledge base, with the original feedback attached, instead of an ad-hoc request in the main queue.
The takeaway
If your only feedback question is attached to resolved tickets, you're measuring agents and calling it portal experience. This week, create one Project-scoped survey with a single, specific question about the portal, turn comments on, and let it run for a month next to your existing CSAT. Then compare the two reports. If they disagree — good ticket scores, poor portal scores — you've found work that no amount of faster ticket handling was ever going to fix.