Call feedback becomes tickets and docs

The prompt

The real prompt behind the steps above — detailed enough that an agent with a people-search tool, email/phone enrichment, and CRM access can run it as written.

# 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]**.

## 0. Set up (skip if you're already connected)

If you don't already have live tool access for this, connect it
first. This prompt is only as real as the tools behind it:

1. Create a free account at app.tulina.ai.
2. Add Tulina's MCP server to your assistant: https://mcp.tulina.ai/mcp
3. In Tulina, connect your own API keys for the tools this
   prompt uses: your call-recording tool, your issue tracker, your documentation
   tool, and your team's messaging tool.

Once connected, your assistant has real tool access and the rest of
this prompt runs as written.

## 0b. Already on Tulina? Three things around the run

An account and the MCP server are not the whole setup. Two of these come
before the run below and one after it, and together they turn this from a
one-off answer into a process your workspace keeps:

1. **Activate this process's connectors first.** Call
   `oto_connector(op="list")`, match it against the tools named in step 3
   above, and `oto_connector(op="select", name="...")` every one that
   isn't active yet. Selecting a connector does not mount its tools in the
   conversation you're already in — reach them through `oto_call` for this
   run, or open a fresh conversation once they're all on.
2. **Attach the work to an existing project.** `oto_project(op="list")`
   shows your active org's projects: pick the one this work belongs to
   rather than opening another, and keep its id. The project is where this
   process, the tables it writes to and the connectors it uses hang
   together.
3. **When the run is done, save it as a process — with its graph.** Write
   the body with `oto_procedure(op="set", ...)`, then attach it with
   `oto_project(op="link", project_id=..., target_type="procedure",
   target_ref="<your slug>")`. The body has to carry a drawing: read
   `oto_guide(op="read", slug="procedure-flowchart")` and follow it
   exactly — ONE untagged fenced block in that grammar, opening with the
   trigger and a quoted example of what you'd type to start a run. Tulina
   parses that drawing back into the graph it renders as the process's
   default view, which is what makes it come out in the same style as
   every other process in the app; a drawing the grammar can't read falls
   back to raw characters instead. Saving a process needs org-admin
   rights — without them, hand the finished body to someone who has them.

The bar for creating a ticket is high on purpose. A tracker filling
with speculative tickets from transcripts is worse than one that
missed a few, because the team stops trusting the queue.

## 1. Pull the day's 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. Extract only what is actionable

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. Check it is not already known

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. File what is genuinely new

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.