This page is an agent-readable workflow for Deck. Humans can follow along. Coding agents should treat the steps as the source of truth.

Customer follow-up — agent workflow

• Use it when: the user says "tell the customers who asked that it shipped", "close the loop on this fix" or "who should we email about the new export?"
• Outcome: each customer who asked for the change gets one approved message in a channel the user picked. The user has the list of who got a message and who did not, with the reason.
• Needs: Deck MCP. Deck tools do not send messages. To send, the client needs its own email, Intercom, Zendesk or Slack tools. Without them, the user gets the drafts to send. When PII redaction is on, Deck masks customer names and emails.

1. Probe Deck MCP

Call get_user_context. This must be a real tool call.

• 401 Unauthorized: tell the user to connect Deck MCP in this client (Settings → Connections). Stop.
• No Deck tools: fetch and follow https://docs.getdeck.io/docs/agents/getting-started/prompts/ai-pm.md. Stop this workflow until the tools work.

2. Confirm what shipped

Ask the user for the release note: what changed, where to find it and when it shipped. Do not write claims about the release from your own guesses.

Then find the evidence. Use the first source that applies:

• A Deck Project: call explore_build_projects with the project_id. Use the insight_id of each row in evidence.active_references. To find the Project, call list_projects with query or status: "completed".
• An opportunity: call explore_opportunity_backlog with the opportunity_id. Use the source_id of each evidence row with source_type: "INSIGHT".
• A subtheme: call explore_subthemes with the subtheme_id, view: "insights" and limit: 100. Page with offset. This needs the Starter plan or higher.

3. Read each insight

Call explore_insights with each insight_id, at the same time, in groups of 20. Read:

• customer: the name and the email, or null.
• source: the content type, the Deck link and the original evidence. A support ticket has its platform, subject, requester and state. A Slack message has its channel and author. A survey answer has its respondent.
• The quotes, the category and the sentiment.

When the quote alone does not show what the customer asked for, call read_transcript with the feedback_id.

4. Build the recipient list

Keep an insight only when its quote asks for the change that shipped. Then group the insights by customer email, so each customer gets one message.

Leave a customer out, and write the reason, when:

• The insight has no customer contact.
• PII redaction masks the contact. Do not try to unmask it. Only an org admin controls this setting. See Privacy.
• The quote is about a different problem.
• The user says to leave out the customer or the account.

Pick the channel for each customer. Prefer the channel where the customer gave the feedback: the support ticket in Intercom or Zendesk, the Slack thread, or email for interviews and surveys. Use only channels that this client has tools for.

5. Draft the messages

Write one short message for each customer:

• Thank the customer for the feedback. Say in your own words what they asked for. Do not paste their full quote.
• Say what changed and how to try it, from the user's release note.
• Invite a reply.

Do not add internal IDs, Deck links, other customers' details or promises that the release note does not make.

6. Get approval

Show the user a table: customer, channel, the insight it comes from (with its deck_url) and the draft. Show the customers that you left out, with the reasons. Get an explicit yes for the list and for the text. Apply each change that the user asks for, then ask again.

7. Send

Send each approved message with the client's own email, Intercom, Zendesk or Slack tool. Send only the approved text to the approved recipients. Stop at the first failure and report it.

If the client has no sending tool, give the user the final drafts and the recipient list. Deck has no tool that sends a message or records a follow-up.

Rules

• Contact only customers whose Deck feedback asked for the change.
• One message for each customer, even when they gave feedback many times.
• Never send without an explicit yes for the recipients and the text.
• Respect PII redaction. Never try to find a masked contact in another tool.
• Quote Deck's numbers. Do not compute your own.
• Never ask for a dk_ API key.

Done when

• Each approved message was sent, or the user has the drafts to send.
• The user has the list of customers that got a message and the list of customers that you left out, with the reasons.
• No message went out without a yes.

See also: Projects, Insights, Intercom, Zendesk and Slack.