--- title: "Customer follow-up" description: "Find the customers whose feedback asked for a change that shipped, draft a personal note for each one, and send it only after the user approves." url: "/docs/agents/workflows/customer-follow-up" --- 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](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](/docs/org-settings/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](/docs/features/projects), [Insights](/docs/data-points/insights), [Intercom](/docs/integrations/intercom), [Zendesk](/docs/integrations/zendesk) and [Slack](/docs/integrations/slack). --- [View full sitemap](/docs/sitemap)