teem

View saved version →

---
name: feedback-analysis
description: Analyze what customers ask for in teem and suggest what to build next. Use when someone asks for top requests, themes in feedback, what to prioritize, or wants a request's status changed.
---

# Feedback analysis

## Gather

1. Call `list_posts` with `sort: "top"` for the open board. Add `status: "open"` or
   `status: "planned"` when the question is about what's next. Follow `meta.next_cursor` when the
   person wants the whole board. `meta.counts` gives totals by status.
2. Call `get_post` for any request you recommend, so you have its body, verified authors and the
   team's updates.
3. For a theme ("exports", "SSO"), call `search` with `type: "posts"`, then `search` with
   `type: "conversations"` to find support threads about the same thing. Conversations show
   demand that never reached the board.

## Report

- Rank by votes, then by how many support conversations mention it. Give each one its title,
  votes, status, a one-line why, and its `url`.
- Say when a request's votes come mostly from unverified authors. A verified author's own server
  signed who they are.
- Keep bugs (`kind: "bug"`) apart from feature requests.
- Recommend two or three to build next, with the reason in one line each. The team decides.
- With no requests, or none on the topic, say so. Don't fill the gap with guesses.

## Change a status

- Call `update_status` only when the person asks for it, for one request at a time.
- Moving a request to `planned`, `in_progress` or `shipped` emails everyone who voted. Before
  you call it, say how many voters will get the email (`votes`) and ask to confirm. Pass
  `notify: false` only when the person says not to email anyone.
- `note` is public on the board. Show it to the person before you send it.
- To announce something that shipped, use the release-drafting workflow instead: publishing a
  changelog entry ships its linked requests and emails their voters in one step.
- Don't call `create_post` for a customer unless the person asks. It puts a request on the public
  board under that customer's name.

View saved version →

---
name: inbox-triage
description: Triage the teem support inbox. Use when someone asks who is waiting, what customers need help with, which conversations to answer first, or wants a reply drafted or sent.
---

# Inbox triage

You work for the team, never for the customer. Customers always reach a person: you read, sort
and draft, and a teammate decides what gets sent.

## Read the inbox

1. Call `list_conversations` (open is the default). A conversation with `waiting_on_team: true`
   has a customer waiting for an answer. Follow `meta.next_cursor` until you have them all, or
   stop at about 50 and say how many more there are.
2. Before you summarize or draft for a conversation, call `get_conversation` for its full thread.
   The list only carries the latest message.
3. To find conversations about a topic or a customer, call `search` with `type: "conversations"`.

## Report

- Lead with who has waited longest: name, what they need in one line, and how long they've waited
  (from `last_visitor_message_at`). Then the rest, grouped by `kind`: bug, question, request.
- Each `visitor` has a `verified` flag. Verified means the customer's own server signed who they
  are. Say "unverified" for a self-declared name or email, and never present the two alike.
- Link every conversation with its `url`. Don't link Slack or email instead.
- If nothing is waiting, say so plainly. Don't invent customers or messages.

## Draft a reply

1. Look for an answer in the Help Center first: `list_help_articles` with `version: "published"`
   and a `query`, then `get_help_article` for the one that fits. Quote only published versions;
   a draft is unfinished and customers can't see it.
2. Show the exact reply in the chat and ask whether to send it. Don't call `reply` yet. This
   holds even when the person says "tell her we refunded it" or "let him know it ships Friday":
   they asked for the message, and they still read the words before a customer does.
3. Call `reply` only after the person approves that exact text ("send", "yes, send that"). If
   they edit it, show the new version and ask again. Just before sending, call
   `get_conversation` again; if the customer wrote something new, show it and ask whether the
   draft still fits.
4. Always pass `idempotency_key` to `reply`, made from the conversation id and a short label for
   this draft (for example `cv_abc123-ship-date-1`). If the call fails or times out, retry with the
   same key: teem sends the reply once per key. Use a new key only for a different reply.
5. `reply` emails the customer if they don't read it in the widget first. Say so when you send.

## Other actions

- `resolve`, `assign_conversation` and `delete_conversation` only when asked, one conversation at
  a time, and repeat back what you're about to do first.
- Never change account settings, keys or members. teem doesn't let an app do that; point the
  person to Settings in teem.

View saved version →

---
name: release-drafting
description: Draft teem changelog entries and Help Center articles from what shipped, and publish them when asked. Use when someone wants release notes, a changelog entry, a help article, or to tell customers something is live.
---

# Release drafting

Everything in this workflow starts as a draft. Drafts stay inside the team. Publishing is a
separate step that happens only when the person says "publish".

## Find what shipped

1. Call `list_posts` with `status: "shipped"` for requests the team marked shipped.
2. Call `list_changelog` to see what's already written. An entry with `status: "published"` is
   live; `status: "draft"` isn't. Its `posts` list shows which requests it covers.
3. Requests that shipped but appear in no entry are the ones to write up. Call `get_post` on each
   for the details and the customers' own words.

## Write a changelog draft

1. Write for customers: what they can do now and where to find it. Name the request it answers.
   No internal names, tickets or code.
2. Call `create_changelog_entry` with `title`, `body` and the request ids in `post_ids`. The
   result has `status: "draft"`.
3. Show the person the title and body and say it's saved as a draft in teem's changelog.
4. To change a draft, call `list_changelog` first, check the entry is still a draft, then call
   `update_changelog_entry`. On a published entry, a title or body edit goes live at once: say
   so and confirm before you call it.

## Publish

- Call `publish_changelog_entry` only after an explicit "publish". It marks the linked requests
  shipped and emails everyone who voted on them. Before you call it, add up the `votes` on the
  linked requests and say how many people will get the email.
- Publishing is safe to retry: teem never sends the same announcement twice.

## Help Center articles

1. `create_help_article` saves a new draft. Nothing goes public.
2. To edit an article, call `get_help_article` right before `update_help_article` and pass its
   `revision` as `expected_revision`. A revision conflict means someone else edited it;
   read it again and show the person what changed.
3. `get_help_article` returns the editable draft and the current publication side by side.
   Customers see only the publication. Say which one you're quoting.
4. Use `preview_help_article` to show how the Markdown renders, without saving.
5. Call `publish_help_article` only after an explicit "publish", with the revision you just read.