A support team wants feedback on their public help docs — not tickets, just "was this page useful?" from anyone who lands on the site. Someone spins up a Typeform, embeds it at the bottom of the docs page, and responses start trickling in. Three months later, nobody on the team can say how many responses came in, what the trend looks like, or which comments pointed at an actual documentation gap that never got fixed. The form works. The feedback loop doesn't.
This is the default outcome for feedback collected outside Jira. It's not that the collection tool is bad — Typeform, Google Forms, and their competitors are perfectly good at capturing a rating and a comment. The problem is what happens after: the data lands in a dashboard your support and product teams don't check, with no path from "someone said this" to "someone did something about it."
Why Feedback Tools That Live Outside Jira Quietly Fail
JSM teams run their actual work — tickets, backlog, escalations — inside Jira. When feedback collection happens in a separate tool, three things go wrong, and they compound:
Nobody looks at it. A dashboard in a third-party survey tool competes for attention with the tools people already have open all day. If checking feedback requires switching context to a system with its own login, it gets checked rarely, and usually only after something has already gone wrong.
There's no link back to work. A comment like "the setup guide skipped a step" is only useful if it turns into a fix. In a standalone survey tool, that means someone has to read the comment, manually open Jira, and create a ticket by hand — an extra step that gets skipped often enough that most of this feedback just evaporates.
You're paying for and maintaining a second system. A separate survey tool means a separate subscription, a separate admin, and a separate place for data to live — data that's arguably more useful sitting next to the tickets it relates to than isolated in its own silo.
None of this is really about the survey tool being wrong for the job. It's about where the resulting data ends up relative to the team that's supposed to act on it.
What a Jira-Connected Public Survey Actually Gives You
The fix isn't "embed a nicer-looking form." It's collecting the feedback somewhere that's already wired into the same system your team resolves work in.
Myra's Public scope survey type exists for exactly this case: feedback collected from a location that isn't tied to a specific ticket or even to your JSM portal — a documentation page, a marketing site, a status page, anywhere you can drop a widget. Feedback submitted through a Public-scope survey lands in the same Reports tab as your ticket-level CSAT and NPS data, which means it's one click away from becoming an actual Jira issue instead of a line in a spreadsheet.
A few things worth knowing before you set one up:
You choose how the response is captured. When you create a new Feedback Survey, you pick a Field Type — a star-based Rating, a 0–10 Number Pick, or None if you only want an open comment box. For a "was this page helpful" widget, Rating is usually the simplest fit; if you want something closer to NPS-style loyalty tracking on the site itself, Number Pick with the NPS calculation strategy gets you there.
Public-scope surveys have a narrower set of Collection Rules than ticket-based ones. Public scope supports Date Range, Day of Week, and Always Allow — it doesn't support the rules that depend on a specific request or reporter, like Last Resolved or Reporter Only, since a public widget isn't tied to an individual customer's ticket history. In practice, most teams just leave Always Allow in place so the widget is live continuously.
The name, scope, and calculation strategy are locked in once you save. Survey names must be lowercase letters, numbers, and hyphens, and csat / nps are reserved for Myra's built-in surveys. Pick these carefully — Myra won't let you change them later, which is a sane trade-off for keeping your historical reporting consistent, but it does mean it's worth deciding on the calculation strategy (Average, Sum, Mode, NPS, Count, or None) before you go live rather than after you've collected a month of data under the wrong one.
Setting It Up
- Create the survey. From Myra's Settings tab, click + New, give it a name, and set its scope to Public. Choose the Field Type and Calculation Strategy that match what you actually want to measure — Rating + Average for a simple satisfaction pulse, Number Pick + NPS if you want a loyalty-style score out of the widget.
- Turn on collection. Toggling Enable Collection on a Public-scope survey generates a standalone Public Survey Link — a URL that collects responses from anyone, no Jira login required. This is what actually goes on your external page.
- Set your Collection Rule. Add an Always Allow rule (or a Date Range / Day of Week rule if you want the widget live only during specific windows) so the survey actually triggers. A survey with collection enabled but no active rule won't appear at all.
- Drop it on the page. Place the link or widget wherever the feedback question makes sense — the bottom of a docs article, a support page, a post-interaction confirmation screen.
- Watch the Reports tab, not a separate inbox. Every response — score and comment — shows up next to your other Myra surveys, with a rolling average graph and a volume-by-rating breakdown so you're not exporting anything to see a trend.
- Turn comments into work from the same screen. Use the Actions menu on any response to create a new linked Jira issue or attach it to one that already exists. A documentation complaint becomes a ticket in the same click it took to read it — no copy-pasting a quote from one tool into another.
The Takeaway
The question isn't whether your team should collect feedback outside a support ticket — sites, docs, and portals all generate feedback worth having. The question is whether that feedback lands somewhere your team will actually see and act on it. A Public-scope survey that reports into the same place as your ticket-level CSAT means the docs comment and the support ticket end up in the same Reports tab, with the same one-click path to becoming real work — instead of living in a dashboard nobody opens until someone asks for a number in a meeting.