Jira + Koji: Customer Research That Turns Into Shipped Tickets

Answer first: Jira is where engineering work lives. Koji is where the customer-research signal that should drive that work lives. The integration pattern is bidirectional: (1) every Koji interview theme that crosses a configurable severity/sentiment threshold creates a Jira ticket pre-populated with the theme description, three representative customer quotes, sentiment, quality score, and a link back to the source transcript — and (2) when the Jira ticket is resolved, the participants whose interviews surfaced that theme can be notified automatically, closing the loop on the feedback they gave you. End-to-end this takes about 45 minutes to wire up via Koji webhooks + Jira REST API, or about 30 minutes with no code via Zapier. With tools like Koji, the gap between "customers keep complaining about onboarding step 4" and "PROD-2812 is in the next sprint with five customer quotes attached" closes inside the same tools your engineers already use.

If your engineering team won't look at a research report but does live in Jira, this is the integration that brings the research to them in the format they already prioritize from.

Why combine Jira and Koji

Most product organizations have a fundamental impedance mismatch between research and engineering:

• Research outputs sit in slide decks and Notion pages. They get presented in a meeting, then never re-opened. The ticket backlog goes on as if the research never happened.
• Engineers prioritize from Jira. A ticket with a clear acceptance criterion, a screenshot, and a sprint label gets done. A reference to "the Q2 research findings" does not.
• The closing-the-loop step is missing. Even when research-driven work ships, the customers who reported the issue almost never hear back. So the next round of research starts from zero trust.

The Koji + Jira integration fixes all three. Every theme that meets your threshold lands in Jira as a ticket the eng team can actually triage. The original transcripts are one click away. And when the ticket moves to Done, an outbound message goes back to the customers who flagged it — turning research into a visible feedback loop instead of a one-way report.

What flows in each direction

Koji → Jira (auto-file tickets from research themes)

• An interview reaches analysis_ready in Koji.
• The webhook payload includes themes (with severity and sentiment), customer quotes, quality score, and a transcript URL.
• The forwarder checks each theme against your routing rules — for example: "create a Jira ticket for any theme tagged as a bug with sentiment ≤ -0.4 and quality ≥ 3."
• Matching themes become Jira issues via POST /rest/api/3/issue with: title (theme name), description (theme summary + 2-3 customer quotes + transcript link), labels (koji-research, theme tags), and (optionally) component, priority, and assignee.
• Subsequent interviews that surface the same theme don't create new tickets — they comment on the existing one with the new quote, so the ticket's evidence accumulates rather than fragmenting.

Jira → Koji (close the loop when fixes ship)

When a Jira ticket created from Koji moves to a configurable status (Done, Released, or a custom Shipped to customers status), a webhook fires back to your forwarder. The forwarder:

• Looks up the participants whose interviews originally surfaced the theme.
• Sends them a personalized thank-you message via Koji's personalized interview links — "You told us in your interview last month that X was broken. We shipped a fix this week. Here's what changed."
• Optionally triggers a short Koji follow-up study asking the same participants whether the fix actually solved their problem.

The second loop is the rare research practice. It's also the one that turns participants into long-term advocates, because they see their feedback turn into a shipped change with their name attached.

Step 1 — Decide which themes graduate to Jira tickets

Not every theme deserves a ticket. The most useful filters are:

• Severity. Themes tagged bug or blocker create tickets immediately. Themes tagged preference or nice-to-have accumulate in Koji and get reviewed weekly.
• Sentiment. Themes with negative sentiment below a threshold (e.g., -0.4 on a -1 to +1 scale) graduate to tickets. Positive themes go to a separate "wins" board, not Jira.
• Quality. Only quality 3+ interviews (understanding quality scores) generate tickets. Low-quality conversations are excluded to keep ticket noise down.
• Volume. A theme that appears in only one interview becomes a candidate ticket on a watch list. A theme that appears across three or more interviews creates the ticket immediately.

The understanding themes and patterns doc explains how Koji generates themes; the activating research insights doc covers the broader "insight → action" pattern.

Step 2 — Build the forwarder (Koji → Jira)

Subscribe to Koji's interview.analysis_ready event (full reference in webhook setup). Your forwarder:

1. Verifies the Koji HMAC signature.
2. For each theme in the payload, runs your routing rules.
3. For each theme that passes, calls Jira:
   • First, query existing issues with label koji-theme-{theme_id} — if one exists, post a comment with the new quote and exit.
   • If not, create a new issue via POST /rest/api/3/issue with:
     • Summary: the theme name, prefixed with [Research] so eng triage can spot it.
     • Description: the theme summary, 2-3 representative quotes from the transcript, the quality score, and a deep link to the Koji study/report.
     • Labels: koji-research, koji-theme-{theme_id}, plus any theme tags from Koji.
     • Priority: mapped from sentiment (very negative → High; moderately negative → Medium; preference → Low).
     • Component or Epic: routed from theme tags via your config (auth themes → Auth component, billing themes → Billing component, etc.).
4. Stores the Jira issue key in a local table keyed on koji_theme_id so future interviews surfacing the same theme can find and comment on the existing issue.

For any path, the user research API guide and API authentication doc cover the Koji side; Atlassian's Jira REST API docs cover the destination.

Path A: Zapier or Make (no code, ~30 minutes)

For teams that don't want to run a forwarder:

1. Trigger: Koji → Interview Analysis Ready (via Koji's Zapier app).
2. Filter: by sentiment and quality (Zapier filter step).
3. Search: Jira → Find Issue by label koji-theme-{id} (Zapier action).
4. Action: Jira → Create Issue (if none found) or Add Comment (if one exists).

This path skips the deduplication elegance of a custom forwarder, but it's a 30-minute setup and works for low-volume research programs.

Step 3 — Close the loop (Jira → Koji)

In Jira, configure a webhook that fires on issue status change. When an issue labeled koji-research moves to Done (or your custom Shipped status):

1. The Jira webhook calls your forwarder with the issue key and new status.
2. The forwarder looks up the koji_theme_id from the issue labels.
3. The forwarder queries Koji for the list of respondents whose interviews surfaced that theme.
4. The forwarder sends each respondent a thank-you message — either via your email tool or via Koji's personalized interview links with a short follow-up study attached.

This is the step almost no research team executes today. It's also the highest-leverage one. A customer who flags a problem, then hears back when it's fixed, doubles their willingness to participate next time and becomes a vocal advocate. The CS team will tell you they've never had an easier renewal conversation than the one that includes "you told us about X, we fixed it, here's the changelog."

What you can build in Jira once the data lands

• A research-backed backlog. Filter Jira on label koji-research to see every ticket that came from customer interviews, sortable by sentiment, theme volume, or quality.
• Sprint review with customer quotes. Every research-tagged ticket carries 2-3 customer quotes in its description, so engineers and PMs ship work without losing the "why."
• Theme-to-epic mapping. Group tickets by theme tag into epics that reflect customer-defined problem areas, not internal architecture.
• A "voice of customer" dashboard. A Jira filter view of all koji-research-labelled issues by status answers "how much customer-driven work are we actually shipping?" — a question most product orgs cannot answer today.
• Re-prioritization on theme volume. When the same theme accumulates 10+ quotes across two months, that's evidence to bump priority. The ticket already has the quotes attached.

Comparison: Koji → Jira vs. ad-hoc research-to-engineering handoff

• Manual transcription. A PM reads a research report, writes a Jira ticket, and pastes one or two quotes. Most quotes are forgotten; tickets carry minimal qualitative weight. The Koji integration carries the actual customer language into the ticket automatically.
• "Reference the Notion page." A Jira ticket whose acceptance criterion is "see Q2 research synthesis" never gets implemented faithfully. Tickets need self-contained context. Koji puts that context in the ticket body.
• No closing the loop. Without an integration, customers never hear back when their feedback ships. The Jira → Koji direction fixes this with one webhook.
• No deduplication. A research-driven backlog written by hand fragments — "onboarding step 4 is confusing" becomes five different tickets. The Koji forwarder's theme-keyed deduplication keeps everything related to one root issue in one place.

Plan requirements and cost

Webhooks and the headless API are included on the Interviews plan (€79/month, 79 credits) and Enterprise. The Insights plan (€29/month) doesn't include webhooks — for that tier, the Zapier path works on any plan. Text interviews cost 1 credit, voice interviews cost 3, and only conversations scoring 3 or higher on Koji's quality gate consume credits. See plan comparison guide.

Jira pricing is independent — Standard, Premium, and Enterprise plans all support the REST API, webhooks, and custom labels needed here. The integration works equally on Jira Software, Jira Service Management, and Jira Product Discovery.

Identity, attribution, and the privacy default

For product research, the participant identity does not need to flow to Jira. The ticket carries the theme, the quotes, the quality score, and a link to the Koji study — but the participant's email never appears in the issue. This keeps Jira out of scope for any privacy regime that classifies participant identity as sensitive while still giving engineering everything they need to ship the fix.

For the closing-the-loop direction, identity lives only in your forwarder's lookup table (mapping theme → respondent list), not in Jira. Anonymous-mode studies cannot close the loop by definition — there's no respondent to notify — but the inbound Koji → Jira direction still works fully for anonymous research.

For regulated industries, see GDPR-compliant AI user research and HIPAA-compliant AI user research.

A 45-minute first run

The fastest end-to-end test:

1. In Koji, pick a recent study that surfaced a clear bug or friction theme.
2. In Jira, create a label koji-research and a filter view that pins all such issues.
3. Manually create a ticket from the theme: paste the theme summary, three quotes, the transcript link, and label koji-research.
4. Run a sprint review with that ticket in the room. Watch how the customer quotes change the conversation about priority.
5. If the eng team responds to the format, wire up the webhook → Jira forwarder so the next 20 themes graduate to tickets automatically.

The manual first run is the cheapest way to learn whether your eng team will actually engage with research-tagged tickets — almost always yes, but worth confirming before you invest in the automation.

Related Resources

• Structured Questions Guide — the six question types whose answers become evidence in every Jira ticket.
• Linear Research Integration — sister guide for teams using Linear instead of Jira.
• Notion Research Integration — build a self-updating research repository in Notion alongside the Jira backlog.
• Slack Research Insights Integration — pipe theme alerts to Slack channels in real time.
• Webhook Setup — full reference for Koji webhook events and HMAC signature verification.
• Research Automation Webhooks — idempotency, retries, and replay patterns for production forwarders.
• Activating Research Insights — the broader "insight → action" methodology this integration operationalizes.
• Understanding Themes and Patterns — how Koji generates the themes that become Jira tickets.