Skip to content
Tulina
Book a demo
← Processes

Call feedback becomes tickets and docs

Every call recorded in the day is distilled overnight, with bugs and feature requests routed to the right team as tickets and docs, plus a Friday digest.

Book a demo
Granola→Linear→Notion→Slack
Starts
Nightly schedule
Steps
5
Checks and gates
0
A person decides
Never, runs alone

Trigger · Schedule

Nightly schedule

The run opens overnight, once the day's calls have finished recording and transcribing.

Claude runs the rest autonomously

  1. 1

    AI gathers the day's customer calls.

    Granola

    Granola

    Every call recorded in the last twenty-four hours arrives with its transcript, participants and account.

  2. 2

    AI lists bugs, requests and doc gaps.

    Each bug, feature request and documentation gap is kept with the customer's own quote, and everything else is discarded.

  3. 3

    AI adds repeats to existing issues.

    Linear

    Linear

    An item that is already an open issue becomes a comment on it with the new quote and account, rather than a duplicate ticket.

  4. 4

    AI creates tickets for new issues.

    Linear

    Linear

    Each new ticket lands on the owning board with the quote, the account and a link back to the call, and documentation gaps go elsewhere as page stubs.

    Notion

    Notion

  5. 5

    AI posts the Friday digest.

    Slack

    Slack

    One weekly summary lists new tickets, how many customers now report each known issue, and the items that did not meet the bar.

Every product team has the same leak. A customer describes a bug on a call, the person on the call makes a mental note, and the note does not survive the afternoon. The transcript exists, complete and searchable, and nobody re-reads a transcript. The bug gets reported again by someone else four months later and is treated as new.

Both ends of the fix already exist. Calls are transcribed automatically, and the tracker is where work is decided. What is missing is the pass over the transcripts, which is genuinely tedious and genuinely mechanical right up until the moment somebody has to decide whether a complaint is a ticket.

What you get

Bugs and feature requests raised on calls arrive as tickets on the right board with the customer's own words attached, instead of staying in a transcript nobody re-reads.

What AI pulls out of a customer call

The run opens overnight, once the day's calls have finished recording and transcribing. It fetches every call recorded in the last twenty-four hours from Granola, with transcript, participants, account and date. Internal-only calls are skipped unless the team wants them included, since most of what makes a good ticket comes from a customer saying it.

Each transcript is read for three kinds of item, and nothing else:

  • A bug. Something behaved wrongly. It needs a described symptom, not just dissatisfaction.
  • A feature request. Something they want that does not exist. It needs a stated need, not a hypothetical.
  • A documentation gap. They could not find out how to do something that already works.

Praise, pricing talk, scheduling and general grumbling are discarded. Every item keeps the customer's own words as a quote, with the call date and who said it. One more filter applies before anything is created: would a person reading only this item know what to do next? If not, it goes into the weekly digest as an unclear signal.

From call feedback to tickets

Before creating anything, the agent searches Linear for each item and matches on substance rather than wording. A customer describing "it logs me out when I switch tabs" and an open issue titled "session dropped on visibility change" are the same bug. When the issue already exists, the quote and the account name go onto it as a comment.

A new item becomes a ticket on the board that owns that area, with a title describing the symptom rather than a guessed cause, the customer quote, the account, the call date, and a link back to the recording. Severity comes from what was actually said: a customer describing a workaround they now perform daily is high, a passing mention is not. Documentation gaps go to Notion as a page stub instead, so they do not compete with engineering work in the same queue and they reach the person who can close them.

What makes call-to-ticket automation hold up

Comment on the existing issue instead of filing a new one, and this stops being a transcription tool and starts being a prioritisation tool. Filed as duplicates, one bug reported by six customers looks like six small issues nobody has time for. Collapsed onto one issue with six quotes attached, it looks like what it is. The corroboration count is the output that changes what gets built, and it only appears if the deduplication happens before the create.

Keeping the customer's exact words is not a nicety. An engineer reading "user reports session instability" has been told nothing; reading "it logs me out every time I switch tabs, so I keep a second browser open just for this" has been told the symptom, the frequency and the workaround. The paraphrase is where all three go missing, and it happens by default because summarising feels like the useful thing to do.

The bar for creating anything at all is the part most worth defending. A transcript pass with a low threshold generates plausible tickets for every offhand remark, and the tracker becomes a place where real issues are buried under speculative ones. Sending everything below the bar into the digest instead means nothing is lost, but nothing unclear reaches the board either.

The Friday digest

Once a week, a summary goes to Slack instead of a nightly stream: new tickets by area, existing issues that gained corroboration and how many customers have now reported each, the documentation gaps opened, and the unclear signals that did not meet the bar. The corroboration count is the most useful number in it. One customer mentioning something is an anecdote; the same issue reported by six accounts in a fortnight is a priority, and that is only visible because the reports sit as comments on one issue.

The prompt

The real prompt behind the steps above, detailed enough that an agent with the same tools can run it as written. The Run buttons copy the full version, which also carries the steps for connecting those tools.

# Turn recorded calls into tickets

You have access to a call-recording tool, an issue tracker, a
documentation tool, and a messaging tool. Run this nightly over
**[yesterday's recorded calls]**.


## 1. Gather the day's customer calls

Fetch every call recorded in the last 24 hours, with transcript,
participants, account, and date. Skip internal-only calls unless the
team explicitly wants them included; most of what makes a good ticket
comes from a customer saying it.

## 2. List bugs, requests and doc gaps

Go through each transcript and pull out items in three categories:

- **A bug.** Something behaved wrongly. Requires a described symptom,
  not just dissatisfaction.
- **A feature request.** Something they want that does not exist.
  Requires a stated need, not a hypothetical.
- **A documentation gap.** They could not find out how to do
  something that already works.

Everything else is discarded. Praise, pricing talk, scheduling and
general grumbling are not tickets.

Keep the customer's own words as a quote for each item, with the call
date and who said it. That quote is the payload; a ticket paraphrased
into internal vocabulary loses the specificity that made it worth
filing.

Apply one filter before anything is created: would a person reading
only this item know what to do next? If not, it goes into the digest
as an unclear signal rather than into the tracker as a ticket.

## 3. Add repeats to existing issues

Search the tracker for each item before creating anything. Match on
substance, not wording: a customer describing "it logs me out when I
switch tabs" and an open issue titled "session dropped on visibility
change" are the same bug.

When it already exists, do not create a duplicate. Add the quote and
the account name as a comment on the existing issue, which is how a
team learns that one bug has now been reported by five customers.

## 4. Create tickets for new issues

Create the ticket on the board that owns that area, with:

- A title describing the symptom, not the guessed cause.
- The customer quote, the account, and the call date.
- A link back to the recording.
- Severity from what was actually said. A customer describing a
  workaround they now perform daily is high; a passing mention is not.

Documentation gaps go to the documentation tool as a page stub rather
than to the tracker, so they do not compete with engineering work in
the same queue.

## 5. Post the Friday digest

Once a week, post a summary rather than a nightly stream: new tickets
by area, existing issues that gained corroboration and how many
customers have now reported them, documentation gaps opened, and the
unclear signals that did not meet the bar.

The corroboration count is the most useful number in the digest. One
customer mentioning something is an anecdote; the same issue reported
by six accounts in a fortnight is a priority, and that only becomes
visible when comments are attached to one issue rather than spread
across six duplicates.

## Output

Report: calls processed, items extracted by category, items matched to
existing issues, new tickets created by board, documentation stubs
opened, and items held back as unclear.

Why run it with Tulina

A prompt helps one person. A process moves a team.

Pasted into a chat, the prompt above works once, for whoever pasted it. In Tulina, "Call feedback becomes tickets and docs" becomes a process the team shares, that keeps its history, runs on its own, and stays inside the same security perimeter as the tools it calls.

  • The whole team works on the same one

    PersonalTeamOrganisation

    A process lives where it belongs: yours, your team's or the whole organisation's. Whoever runs it can improve it, and everyone starts from the best version instead of explaining the job again.

  • Every edit is a version

    v1v2v3

    Each change is a new version with the previous one kept, so a bad edit is undone by restoring an earlier one. Every run records the version it followed, and what a run teaches goes back into the process.

  • It runs without you

    schedulewebhookon demand

    A hosted agent runs the process on Tulina's own infrastructure, on a schedule or when an event arrives, and keeps going when you close the chat. Nothing to host. Every run is tracked to its outcome.

  • Inside the same security perimeter

    vaultrolesrun log

    Credentials stay in the vault, never in the prompt. Roles decide who may run what, every call is logged, and a step a person has to approve waits for that person.

Questions about turning call feedback into tickets

Yes. An agent reading each day's transcripts can pull out bugs, feature requests and documentation gaps, keep the customer's own words for each, and file them on the board that owns that area with a link back to the recording.

Two filters. An item has to fall into bug, feature request or documentation gap with a described symptom or stated need, and it has to pass the test of whether someone reading only that item would know what to do next. Anything else goes into the digest as an unclear signal instead.

The second report is added as a comment on the existing issue rather than filed as a new ticket, carrying the new customer's quote and account. That turns repeated reports into a corroboration count, which is what makes prioritisation possible.

No. The first step needs a transcript, participants, an account and a date, which every recording tool exposes, and everything after that operates on the transcript rather than on the tool it came from.

Also on Linear

Other processes that run mainly on Linear. The tools they share with this one are lit.

See Tulina in a 30-minute demo.

Book a demo