Promotional offer50% off every paid plan, billed monthly.See pricing
Workflows

From a call to a tracked issue

A meeting ends with decisions, bugs, and promises that someone has to write up. Here is how to turn them into reviewed findings and tracked issues without retyping anything, each one linked to the moment it was said.

Updated
8 October 2026
Read
5 min
Needs
A paid plan to push; any plan to review
The workflow

Six steps from a call to a ticket.

  1. Bring the call in

    Upload the recording from New content, or let the meeting assistant capture the meeting for you on a paid plan. Choose the project it belongs to, so questions about that project include it.

  2. Read the recap

    The recording opens on Recap: a TL;DR, then decisions, action items, open questions, and key outcomes. Select an outcome to play the moment behind it.

    The recap of a sprint review. Decisions and action items come from what was said, and each one plays the moment behind it.
  3. Open the findings

    The Artifacts tab lists every finding by type: bugs, requirements, decisions, action items, risks, and questions. Each carries the quote, the speaker, and the time. Open one to see its evidence and a preview of what will be sent.

    One finding with its evidence: the quote, who said it, when, and a preview of the issue that will be created.
  4. Approve what you stand behind

    Approve the findings that are right and reject the rest. From Artifacts in the sidebar, open the recording to review its whole list at once: Approve all clears a long list in one step, and any decision can be reopened later.

    A recording's findings, grouped by type. Approve all clears the review queue; Push sends everything approved.
  5. Push to your tracker

    Choose Push on an approved finding, or Push on the findings page to send every approved one. Pick a connected destination such as Jira or Linear. The issue arrives with the quote, the timestamp, and a link back to the moment.

    Choosing a destination. Only destinations that accept a finding are offered.
  6. Confirm it arrived

    Settings, then Integrations, lists every delivery with its status. A failed delivery names the reason and offers Retry. Pushing the same finding again updates the issue instead of filing a duplicate.

    The delivery record in Settings. Every push is listed with its outcome.
Worked example

A sprint review, end to end.

  1. The meeting assistant records the Checkout 4.12 sprint review and files it in the Checkout redesign project.
  2. The recap lists the rollout decision, the action items with their owners and dates, and the open question about the promo code field.
  3. Artifacts shows a critical bug: the Apple Pay sheet dismisses when the postcode changes. The quote and the speaker are attached.
  4. The product lead approves the bug and the action items, and rejects anything that repeats another finding.
  5. The bug is pushed to Jira. The engineer who picks it up plays the twenty seconds where it was described, instead of asking what it means.
Set up once

Before your first push.

An owner or admin connects each destination once, in Settings under Integrations. Step-by-step setup: Jira, Linear, Notion, Slack, and webhooks.

Common questions

From call to issue, answered.

  • A finding has to be approved before it can be sent. Approve it in its panel or from the findings page, then Push becomes available.

  • Yes. Slack and Notion accept findings, recaps, and transcripts. The push dialog only lists destinations that accept what you are sending, and shows any others as not connected.

  • Reject it. Rejected findings stay with the recording, marked as rejected, so the review is visible to your team, and they are never pushed. Reopen review if you change your mind.

  • Reviewing findings works on every plan. Pushing to Jira, Linear, Notion, Slack, or a webhook, and the meeting assistant, need a paid plan.

Next steps

Go deeper.