30 Claude Prompts for Intercom

You are a conversation designer who builds Fin chatbot flows inside Intercom for a SaaS company. <context> I want the bot to qualify an inbound sales question before it ever reaches a human rep, so reps only see conversations worth their time. </context> <inputs> - Product or service: [PRODUCT NAME] - Qualifying criteria: [CRITERIA LIKE COMPANY SIZE OR BUDGET] - Disqualified path outcome: [WHAT HAPPENS IF THEY DO NOT QUALIFY] - Qualified path outcome: [ROUTE TO REP OR BOOKING LINK] </inputs> <task> Write the full bot conversation flow as a script, including every question the bot asks and every branch based on the answer. </task> <constraints> Ask no more than four questions before branching. Keep bot messages under two sentences each. Never make the visitor feel interrogated, phrase questions like a helpful person, not a form. </constraints> <format> Return the flow as a numbered sequence of bot messages, with each branch point labeled If yes and If no, ending in the final action for each path. </format>

You are a support automation specialist designing Intercom bot flows for billing related questions. <context> Billing questions make up a large share of our conversation volume and most of them follow a small number of predictable patterns. </context> <inputs> - Common billing questions: [LIST OF QUESTION TYPES] - Self-serve actions available: [WHAT THE CUSTOMER CAN DO THEMSELVES] - Cases that must go to a human: [ESCALATION TRIGGERS] </inputs> <task> Build a decision tree bot flow that routes each billing question type to either a self-serve answer or a human handoff. </task> <constraints> Every self-serve branch must end in a concrete action the customer can take immediately, not just information. List escalation triggers explicitly so the bot never guesses. Avoid vague phrases like contact support, name the exact next step. </constraints> <format> Return a tree structure using indentation, starting from the opening bot question down through each branch to its final resolution or handoff. </format>

You are a support operations lead writing the handoff messages between the Fin bot and human agents in Intercom. <context> Our bot to human handoffs feel abrupt, customers repeat information they already gave the bot and get frustrated. </context> <inputs> - Handoff trigger: [WHAT CAUSES THE HANDOFF] - Information the bot already collected: [FIELDS COLLECTED] - Expected wait context: [BUSINESS HOURS OR QUEUE LENGTH] </inputs> <task> Write the exact bot message that hands the conversation to a human, plus the note the agent sees summarizing what already happened. </task> <constraints> The customer facing message must not repeat questions the bot already asked. Set an honest expectation about wait time instead of a generic we will be right with you. Keep the customer message to two sentences. </constraints> <format> Return two labeled sections: Customer sees, with the exact handoff message, and Agent sees, with a short summary note including the collected fields. </format>

You are a support automation designer building a self-serve bot flow in Intercom for account access issues. <context> Password and login problems are high volume, low complexity, and almost always solvable without a human agent. </context> <inputs> - Login system: [SSO, EMAIL LOGIN, OR BOTH] - Self-serve reset link: [RESET URL OR LOCATION] - Common failure reasons: [REASONS RESET FAILS] </inputs> <task> Write a bot flow that resolves the most common login issues without agent involvement, only escalating true edge cases. </task> <constraints> Cover at least three distinct failure reasons with separate branches, not one generic reset link for everyone. Escalate to a human only after self-serve steps are confirmed exhausted. Keep each bot message short and action oriented. </constraints> <format> Return the flow as branches labeled by failure reason, each ending in either a resolved step or a clearly marked escalation to a human agent. </format>

You are a revenue operations specialist designing an Intercom bot flow that converts website visitors into booked demo calls. <context> Visitors ask sales questions in chat and I want the bot to move qualified ones straight to a booked call instead of a back and forth email thread. </context> <inputs> - Product or service: [PRODUCT NAME] - Booking link: [CALENDAR LINK] - Qualifying question: [ONE KEY QUALIFYING QUESTION] - Fallback for unqualified visitors: [WHAT THEY GET INSTEAD] </inputs> <task> Write a bot flow that asks the qualifying question, then either offers the booking link or routes to the fallback path. </task> <constraints> The booking offer must appear within two bot messages of the visitor's first message, do not delay it. Keep the tone conversational, not like a scripted sales pitch. Give the unqualified path a genuinely useful fallback, not a dead end. </constraints> <format> Return the flow as a short numbered script of bot messages with the two branch outcomes clearly labeled at the end. </format>

You are a support team lead writing standardized macros for Intercom to keep refund responses consistent across the team. <context> Different agents word refund replies differently and some promise things our refund policy does not actually cover. </context> <inputs> - Refund policy summary: [POLICY SUMMARY] - Refund window: [NUMBER OF DAYS] - Approved refund reasons: [LIST OF REASONS] </inputs> <task> Write a macro template for approving a refund and a separate macro for declining one, both fillable with the customer's specific details. </task> <constraints> The decline macro must state the reason clearly without sounding accusatory. Do not promise exceptions the policy does not allow. Keep both under 100 words. Use a placeholder for the customer's first name and order or account details. </constraints> <format> Return two labeled macros, Approved and Declined, each with placeholder fields marked in brackets for the agent to fill in before sending. </format>

You are a customer support manager writing a saved reply for Intercom to use when a conversation sat unanswered too long. <context> We had a queue backlog and several customers waited far longer than our stated response time before an agent replied. </context> <inputs> - Actual wait time: [HOURS OR DAYS WAITED] - Reason for the delay, if shareable: [REASON OR INTERNAL ONLY] - What changes going forward: [FIX OR STAFFING CHANGE] </inputs> <task> Write a saved reply that opens the delayed conversation, acknowledges the wait honestly, and gets straight to solving the original issue. </task> <constraints> Do not over-apologize with more than one sentence of apology, then move to solving the problem. Do not blame the customer for following up. Keep total length under 80 words. </constraints> <format> Return a single saved reply block with a bracketed placeholder for the customer's name and one for the original issue reference. </format>

You are a support enablement specialist writing an Intercom macro for agents to use when customers ask about a recent price increase. <context> We raised prices last quarter and the same three objections keep coming up in chat. </context> <inputs> - Price change details: [OLD PRICE TO NEW PRICE] - Reason for the change: [REASON, EG NEW FEATURES OR COSTS] - Retention offer available: [DISCOUNT OR GRANDFATHER TERMS IF ANY] </inputs> <task> Write a macro that explains the pricing change clearly and, where applicable, offers the retention option without sounding scripted. </task> <constraints> State the reason for the increase in one plain sentence, do not hide behind vague language like value alignment. Only mention the retention offer if the customer pushes back, structure the macro with that as an optional second paragraph. Keep the main paragraph under 60 words. </constraints> <format> Return two paragraphs labeled Primary response and Optional retention follow-up, each ready to send as separate macro messages. </format>

You are a customer support agent handling feature request conversations inside Intercom without overpromising a roadmap. <context> Customers regularly ask for features that are not planned or not confirmed, and I need a reply that takes the request seriously without committing to a timeline. </context> <inputs> - Feature requested: [FEATURE DESCRIPTION] - Current roadmap status: [NOT PLANNED, UNDER REVIEW, OR PLANNED] - Internal tracking method: [WHERE THE REQUEST GETS LOGGED] </inputs> <task> Write a saved reply that thanks the customer, confirms the request is logged, and sets an honest expectation based on the roadmap status. </task> <constraints> Never imply a release date that has not been confirmed. Do not use the phrase no plans at this time without also saying what happens to the feedback. Keep it under 70 words. </constraints> <format> Return a single saved reply with a bracketed placeholder for the feature name and the internal tracking reference. </format>

You are a support operations specialist writing an Intercom macro to close conversations that have gone quiet after a resolution was offered. <context> Many conversations sit open for weeks because the customer never confirmed the fix worked, and it is inflating our open ticket count. </context> <inputs> - Days since last customer reply: [NUMBER OF DAYS] - Resolution offered: [WHAT WAS SUGGESTED] - Reopen method: [HOW THE CUSTOMER CAN REOPEN] </inputs> <task> Write a macro that checks in once more, then explains the conversation will close automatically if there is no response, and how to reopen it later. </task> <constraints> Do not sound like an automated bot even though this may be sent by one. Make the reopen path explicit and easy, not buried at the end. Keep it under 60 words. </constraints> <format> Return a single macro message with a bracketed placeholder for the customer's name and the specific resolution that was offered. </format>

You are a lifecycle marketing specialist writing Intercom proactive messages for a free trial software product. <context> Our trial users convert much more often if they take a specific key action, and I want to prompt the ones who have not taken it before the trial ends. </context> <inputs> - Product name: [PRODUCT NAME] - Days left in trial: [DAYS REMAINING] - Key action not yet taken: [ACTION NAME] - Link or in-app path to that action: [LINK OR LOCATION] </inputs> <task> Write a proactive in-app message that nudges the user toward the key action with a clear reason tied to their remaining trial time. </task> <constraints> Do not use urgency language that feels manipulative, state the days remaining as a fact, not a threat. Keep it to two sentences plus one button label. Focus on the value of the action, not the risk of losing access. </constraints> <format> Return the message text and a separate button label, formatted as they would appear in Intercom's proactive message editor. </format>

You are a customer communications lead writing an Intercom banner message for a planned maintenance window. <context> We have scheduled downtime coming up and I need to notify active users inside the product before it happens. </context> <inputs> - Maintenance window: [DATE AND TIME RANGE WITH TIMEZONE] - Expected impact: [WHAT WILL BE UNAVAILABLE] - Status page link: [LINK TO STATUS PAGE] </inputs> <task> Write a short banner message announcing the maintenance window and what to expect during it. </task> <constraints> State the exact time range with timezone, do not use vague terms like later tonight. Keep the entire message under 30 words including the link mention. Do not apologize excessively, one brief acknowledgment is enough. </constraints> <format> Return the banner text as a single line ready to paste into Intercom, with the status page link marked as [STATUS PAGE LINK]. </format>

You are a customer success specialist using Intercom outbound messages to drive adoption of an underused feature. <context> We shipped a feature months ago that solves a real problem, but usage data shows most customers have never tried it. </context> <inputs> - Feature name: [FEATURE NAME] - Problem it solves: [PROBLEM DESCRIPTION] - Segment to target: [CUSTOMER SEGMENT, EG PLAN OR USAGE PATTERN] - Link to try it: [IN-APP LINK] </inputs> <task> Write an outbound message that connects the feature directly to a problem this segment likely already has, then invites them to try it. </task> <constraints> Open with the problem, not the feature name, people respond to relevance before novelty. Keep it under three sentences. Avoid generic phrases like check out our new feature. </constraints> <format> Return the message text and a single call to action button label, formatted for Intercom's outbound message editor. </format>

You are a customer experience specialist writing an Intercom proactive message sent shortly after a purchase or upgrade. <context> We want to catch confusion or buyer's remorse early after checkout, before it turns into a support ticket or cancellation. </context> <inputs> - What was purchased: [PLAN OR PRODUCT NAME] - Timing after purchase: [HOURS OR DAYS AFTER] - Common early confusion point: [WHAT NEW BUYERS OFTEN MISUNDERSTAND] </inputs> <task> Write a short check-in message that opens a low-pressure channel for questions and proactively addresses the common confusion point. </task> <constraints> Do not ask a generic how is everything going, reference the specific confusion point directly. Keep it to two sentences. Make replying feel effortless, not like filling out a survey. </constraints> <format> Return the message text as it would appear in Intercom, with a bracketed placeholder for the customer's first name. </format>

You are a retention marketing specialist writing an Intercom outbound message aimed at customers who canceled recently. <context> We want to reach out to recently churned customers once, without being pushy, in case their situation has changed. </context> <inputs> - Product name: [PRODUCT NAME] - Time since cancellation: [WEEKS OR MONTHS] - Known cancellation reason if available: [REASON OR UNKNOWN] - Incentive to return, if any: [DISCOUNT OR NONE] </inputs> <task> Write a single win-back message that acknowledges they left, addresses the known reason if there is one, and makes returning easy. </task> <constraints> Do not sound desperate or guilt the customer for leaving. If the cancellation reason is unknown, ask one direct question instead of guessing. Keep the message under 50 words. </constraints> <format> Return the message text with a bracketed placeholder for the customer's first name and the incentive detail if one applies. </format>

You are a support operations manager building a triage rubric for a team handling a shared Intercom inbox. <context> New conversations sit unsorted and agents pick them up in whatever order they open the inbox, not by urgency. </context> <inputs> - Conversation categories: [LIST OF COMMON TYPES] - Response time targets: [SLA BY CATEGORY] - Signals of urgency: [WORDS OR ACCOUNT TRAITS THAT MEAN URGENT] </inputs> <task> Write a triage rubric that assigns each conversation category a priority level and lists the signals that should bump it up. </task> <constraints> Use no more than four priority levels. Base each level on a clear, checkable signal, not a judgment call like seems upset. Keep the whole rubric to one page. </constraints> <format> Return a table-style list with columns for category, default priority, and escalation signal, followed by a one line summary of how to apply it in the inbox. </format>

You are a senior support agent in Intercom handling a conversation that has escalated in tone. <context> The customer is clearly frustrated after multiple back and forth messages and I need to de-escalate before continuing to troubleshoot. </context> <inputs> - What the customer is frustrated about: [ISSUE SUMMARY] - Number of prior attempts to fix it: [NUMBER OF ATTEMPTS] - What you can actually do next: [NEXT CONCRETE STEP] </inputs> <task> Write a reply that acknowledges the frustration specifically, takes ownership without over-apologizing, and states the next concrete step. </task> <constraints> Do not use the word understand more than once, it reads as hollow when repeated. Do not promise an outcome you cannot guarantee. Keep it under 90 words. </constraints> <format> Return a single reply message with a bracketed placeholder for the customer's name and the specific next step. </format>

You are a technical support agent in Intercom responding to a customer who reported a bug. <context> I need a consistent way to acknowledge bug reports, gather the information engineering actually needs, and set expectations on the fix. </context> <inputs> - Bug description as reported: [PASTE CUSTOMER DESCRIPTION] - Information needed to reproduce: [LIST, EG BROWSER, STEPS, SCREENSHOT] - Bug tracking reference format: [HOW BUGS ARE TRACKED INTERNALLY] </inputs> <task> Write a reply that thanks the customer, asks for the specific missing reproduction details, and explains what happens after they provide them. </task> <constraints> Ask for no more than three pieces of missing information at once. Do not promise a fix timeline, only confirm the report is logged. Keep the tone appreciative, bug reports are free QA. </constraints> <format> Return a single reply with the information requests as a short bulleted list and a bracketed placeholder for the tracking reference. </format>

You are a support team trainer writing a de-escalation script for agents to use during a live Intercom chat with an angry customer. <context> New agents freeze or get defensive when a customer is openly angry in chat, and I want a script they can adapt in the moment. </context> <inputs> - Typical trigger situations: [WHAT USUALLY CAUSES THE ANGER] - Company tone guidelines: [FORMAL OR CASUAL] - Authority the agent has: [WHAT THEY CAN OFFER OR DECIDE] </inputs> <task> Write a three step de-escalation script covering the opening acknowledgment, the clarifying question, and the resolution offer. </task> <constraints> Each step should be one or two sentences the agent can say almost word for word. Do not include corporate phrases like your business is important to us. Match the specified tone exactly. </constraints> <format> Return the script as three labeled steps, Acknowledge, Clarify, and Resolve, each with example wording the agent can adapt. </format>

You are a support agent in Intercom handing off a complicated, multi-message case to another team member or shift. <context> This conversation has gone back and forth for days across multiple issues and whoever picks it up next needs to get up to speed fast. </context> <inputs> - Full conversation history or key excerpts: [PASTE CONVERSATION OR SUMMARY] - Issues still unresolved: [LIST OF OPEN ITEMS] - Anything promised to the customer: [COMMITMENTS MADE] </inputs> <task> Write an internal note that summarizes what has happened, what is still open, and any commitments made to the customer. </task> <constraints> Order items by what is most urgent to act on first. Flag any commitment that has a deadline attached. Keep it scannable, use short bullet points, not narrative paragraphs. </constraints> <format> Return three sections: Summary, Still open, and Commitments made, each as a short bulleted list. </format>

You are a support analyst turning raw Intercom conversation data into a readable weekly summary. <context> I have a week's worth of conversation tags and volume numbers exported from Intercom and I need a summary I can share without anyone digging through the raw export. </context> <inputs> - Conversation volume by tag: [PASTE TAG COUNTS] - Total conversations and average response time: [TOTALS] - Anything unusual this week: [SPIKE, OUTAGE, OR NONE] </inputs> <task> Write a short summary that highlights the biggest volume drivers, the response time trend, and anything unusual worth flagging. </task> <constraints> Lead with the single most notable number, not a list of every metric. Do not editorialize about causes you cannot confirm from the data given. Keep it under 200 words. </constraints> <format> Return a short paragraph summary followed by three bullet points of supporting numbers. </format>

You are a customer support lead reporting weekly trends to company leadership who do not work in Intercom directly. <context> Leadership wants to know what customers are struggling with, not raw ticket counts, and I need to translate support data into business language. </context> <inputs> - Top recurring issues this week: [LIST OF ISSUES] - Volume change versus last week: [PERCENT OR NUMBER CHANGE] - Any issue tied to a specific feature or release: [FEATURE OR RELEASE NAME] </inputs> <task> Write a leadership-facing summary that connects support trends to product or business impact, not just support team metrics. </task> <constraints> Avoid support jargon like ticket, macro, or SLA, translate into plain business terms. Keep it to one short paragraph plus a short recommendation. Do not recommend action outside the support team's authority. </constraints> <format> Return a paragraph summary followed by one labeled Recommendation line. </format>

You are a support team lead writing an onboarding guide for a new hire who will work inside Intercom from day one. <context> We just hired a new support agent and I want a single document that gets them productive in Intercom within their first week. </context> <inputs> - Team's Intercom setup: [INBOXES, TAGS, OR TEAMS USED] - Tools used alongside Intercom: [OTHER TOOLS, EG CRM OR DOCS] - First week milestones: [WHAT THEY SHOULD BE ABLE TO DO BY DAY FIVE] </inputs> <task> Write a day by day onboarding guide covering Intercom navigation, key macros and tags, and the milestones for the first week. </task> <constraints> Break it into no more than five days, each with two or three concrete tasks. Do not assume prior Intercom experience, explain terms like inbox and macro on first use. Keep each day's section under 100 words. </constraints> <format> Return five sections labeled Day 1 through Day 5, each with a short task list. </format>

You are a support quality assurance lead building a checklist to review Intercom conversation quality across the team. <context> We want to review agent replies consistently instead of spot checking based on gut feel, and I need a checklist reviewers can apply quickly. </context> <inputs> - Tone standards: [BRAND VOICE GUIDELINES] - Common quality issues seen so far: [LIST OF ISSUES] - Review frequency: [HOW OFTEN CONVERSATIONS ARE REVIEWED] </inputs> <task> Write a quality review checklist covering tone, accuracy, and resolution quality that a reviewer can apply to any closed conversation in a few minutes. </task> <constraints> Use yes or no checkable items, not open ended questions. Limit the checklist to ten items total. Include at least one item targeting each common issue listed. </constraints> <format> Return a numbered checklist of ten items grouped under three headers: Tone, Accuracy, and Resolution. </format>

You are a support operations lead writing an internal postmortem after a support related incident, like a bot misfire or a tagging error that caused missed escalations. <context> Something went wrong in our Intercom setup that affected customers, and I need to document what happened and what we are changing so it does not repeat. </context> <inputs> - What happened: [INCIDENT DESCRIPTION] - How many customers or conversations affected: [NUMBER OR ESTIMATE] - Root cause, if known: [ROOT CAUSE OR STILL INVESTIGATING] - Fix already made or planned: [FIX DESCRIPTION] </inputs> <task> Write an internal postmortem that explains the timeline, the impact, the root cause, and the concrete fix, without assigning individual blame. </task> <constraints> Focus on the process or system gap, not on which person made a mistake. State the impact in concrete numbers, not vague terms like several customers. Keep it under 300 words. </constraints> <format> Return four sections: What happened, Impact, Root cause, and What changes, each as a short paragraph or bullet list. </format>