Your support inbox is the best customer-research dataset you have. The questions customers actually ask, the things that confuse them, the parts of your docs that don't land. All of it sits in Intercom in the form of conversation threads. Nobody on the content team reads them. They don't have the time, and even if they did, "the top eight questions over the last six months" is not a report Intercom hands you.
Meanwhile, your blog has 40 posts. Half of them have FAQ sections that haven't changed in 18 months. The FAQs answer the questions the original author imagined a reader would have, not the questions readers actually have when they land on the post. You know there's drift. You don't know what to write to close it.
Scratch puts the two sources in one folder. Pull a window of Intercom conversations as local files. Pull your blog as local files. Hand the AI both. The AI groups the conversations into a few top themes, finds the blog post each theme best maps to, and drafts the FAQ entries that would answer the most-asked questions. You review every change as a word-level diff before anything ships.
The prompt
Three prerequisites:
- Connect both Intercom and your blog source (Webflow, WordPress, or whichever CMS holds your posts) in Scratch.
- Pull a six-month window of Intercom conversations. Long enough for stable patterns, short enough to keep context manageable. Pull the FAQ-bearing blog posts you want to update; if you're unsure which, pull the whole blog (assuming it's under 100 posts).
- PII is in the conversation files. The prompt below tells the AI to strip names, emails, account IDs, and any other personal detail from the FAQ wording it drafts. Verify in review.
You are running over two folders in a Scratch project:
- A folder of Intercom conversations from the last 6 months, one
JSON file per conversation. Each file has the full thread plus
metadata.
- A folder of blog posts from my CMS, one file per post. Each post
has a body field and (often) an FAQ section near the end.
Your job is to read the conversations, find the recurring
questions customers ask, and add answers to the FAQ sections of
the right blog posts. The edits land on disk; a human reviews each
one as a diff in Scratch before anything ships.
Edit only the body field of blog post files. Do not edit
conversation files. Do not change blog post titles, slugs, SEO
meta, or any other field.
Phase 1: read the conversations.
1. Read every conversation file. Group the customer-asked
questions into themes. Before naming a theme, strip customer
names, emails, account IDs, organization names, and any other
personal detail. Themes should be generalizable: "how do I
filter records before sync", not "Sarah at Acme asked about
filtering".
2. For each theme, count how many distinct conversations touched
on it. Discard themes with fewer than 3 conversations; those
are one-offs, not patterns.
3. For each surviving theme, draft one question and one answer in
FAQ shape. The question should be the way a customer would
phrase it, not how an internal person would. The answer should
be 2 to 4 sentences, concrete, no marketing tone.
Phase 2: map themes to posts.
4. For each theme, find the single blog post that is the best
home for that question. Match on topic, not on title. If no
post is a good fit, set that theme aside; you will not edit
any post for it.
5. Show me the proposed mapping (theme -> blog post -> question +
answer draft) before editing anything. I will approve, reject,
or reassign each one.
Phase 3: edit.
6. For each approved mapping, open the blog post file and add the
FAQ entry to the existing FAQ section. If the post has no FAQ
section, add one in standard shape: a heading, then question /
answer pairs.
7. Do not edit any other prose in the post. Do not touch posts
that were not in the approved mapping.
When you finish, print one line: count of posts edited, count of
themes skipped (with reason), then "READY · review diff in
Scratch". Edits on disk are the deliverable. Do not dump rewrites
to chat.
The prompt is longer than most because it does three real things in sequence: pattern-finding across the inbox, mapping themes to posts, and editing. The human checkpoint in the middle (phase 2, step 5) is the safety. You see and approve every theme-to-post pairing before the AI touches a blog file.
What the FAQ-update actually looks like
This is the loop Scratch runs for every task. Here is what each step looks like for an Intercom-to-blog pass.
1. Pull
Scratch pulls two folders into your local project: scratch/intercom/conversations/ with one JSON per thread, and scratch/<your-blog>/posts/ with one file per post. The conversations include the full thread, the participants, and the metadata. The posts include the body, the FAQ section (if any), and the rest of the record. Nothing on the live blog has changed.
2. AI edits
Open Claude Code at your Scratch project root and paste the prompt above. The AI reads every conversation and groups the questions into themes (with PII stripped). It maps each theme to the best-fit blog post. It shows you the mapping. After you approve, it edits each post's FAQ section in place. Scratch keeps the original alongside the edit so it can diff them later.
3. Review
Open the Scratch desktop app. Every blog post the AI edited shows up as a row in the review table, the old FAQ section on the left, the new one on the right, additions highlighted in line. Skim the diff. New entries that read like a real customer would ask the question get a one-click approve. Entries where the AI smushed two themes together or invented a detail get rejected. Entries where the wording is close get edited in place.
4. Ship
Hit publish in Scratch. The approved FAQ updates write back through your CMS API, one post at a time. Rejected and unedited posts stay where they were. Roll back any row after publish by rejecting it; the original body returns.
Why not just read Intercom yourself
The hard part of FAQ work is not the writing. The hard part is reading 600 conversation threads and seeing the pattern. The AI is good at the reading-and-grouping part. The writing part is straightforward once you know what the top eight questions are. The Scratch path keeps the human in the loop at the two moments that need judgment: which theme belongs on which post, and whether each draft answer is accurate.
When not to use this skill
- You don't have enough conversations. Pattern-finding needs volume. If your Intercom has fewer than 200 conversations in the last six months, the themes will not be reliable. Use the inbox you have to inform a manual FAQ pass instead.
- Your blog has no FAQ sections and you don't want any. This skill adds FAQ entries to existing FAQ sections (or creates them if missing). If your editorial style avoids FAQs entirely, this isn't the right shape. Consider rewriting body prose to answer the questions instead.
- You haven't audited the conversation set for sensitive content. Some support threads include billing disputes, security incidents, or escalations that should never inform public copy. The PII rule in the prompt strips names and emails; it doesn't filter for "this conversation shouldn't have informed anything". Skim the conversation folder before running.
- The blog and the inbox serve different audiences. If your Intercom is enterprise customers and your blog is for SMB prospects, the questions won't transfer. Verify the audience overlap before running.
The shape is simple: the AI finds the patterns, you keep the veto on both the mapping and the wording. Six months of customer questions become eight specific FAQ updates, and not one ships without you reading it.
Related
- Scratch for Intercom covers every other field Scratch can edit on an Intercom workspace.
- Scratch for Webflow covers blog and FAQ editing in detail.
- Bulk-add outbound links to a Webflow blog with AI pairs well. Run linking first, then this pass to fill in answers.
- Make the agent define done before it starts pairs well with this prompt on long sessions.