Automate First-Pass Customer Support With Claude Code and MCP - SiteSpeakAI

Templates

Pricing

Integrations

Features

AI Training

Customization

Inbox & Live Chat

API & Tools

Lead Capture

Analytics

Languages

Industries

SaaS

Ecommerce

Healthcare

Education

Manufacturing

Finance

Travel & Tourism

Use Cases

Service Businesses

Veterinary

Law Firms

Showit & Photography

Internal Knowledge Base

Blog

20 Jul 2026

9 min read

Table of Contents

For the last ten weeks, a scheduled job on my Mac has run Claude Code at 6am with a single instruction file. It pulls our traffic, new production errors and uptime through MCP servers and emails me one report before I sit down. 67 runs so far. Boring and reliable, which is the point.

This week I extended it to the biggest block of manual work in my morning: the support inbox. The first run processed 5 inbox threads, created 3 reply drafts in my email client, and correctly skipped 2. This post is the full setup, including the instruction file, so you can build the same thing. Nothing in it is specific to SiteSpeak: any support tool that ships an MCP server works.

Why the inbox was the manual part

Our own AI chatbot handles first-line questions on sitespeak.ai. That part has been automated for years. What stayed manual was everything the bot escalates: bug reports, billing questions, and prospects who want to talk to a human. Those land in an inbox, and every morning I would read each conversation, work out which "it's broken" was actually broken, and write replies.

The volume was never the problem. A handful of threads a day does not justify automation on time saved alone. The problem was consistency: a proper reply means checking the error logs, reading the relevant code and verifying the docs before answering, and doing that thoroughly for every thread, every morning, between everything else, is exactly the kind of work an agent with the right tools should be doing for you.

The setup at a glance

Four pieces:

Claude Code , run headless on a schedule: claude -p "/morning-report" from a launchd job (cron works the same on Linux)

Four MCP servers : our support tool's inbox, Sentry, Nightwatch, and my email client

One markdown skill file that describes the workflow, the classification rules, and the hard limits

A JSON state file that records every processed thread so runs are idempotent

There is no glue code. No API integration project. The agent composes the four servers itself into one small agentic workflow, following the instruction file. That is the practical argument for MCP: the integration work you would normally do per-tool disappears, and the "integration" becomes a document a human can read and edit.

What a run actually does

Step by step, from the skill file:

List open inbox threads via the support tool's MCP server and keep the ones with activity since the last run. The state file filters out everything already handled.

Read the visitor's own messages , not just the bot's answers. Classify each thread: urgent (existing customer, something broken, billing, asked for a human), prospect (evaluating, pricing, "can it do X"), or noise (spam, empty sessions, tests).

Investigate before drafting. A bug report gets checked against Sentry and Nightwatch for matching production errors, and against the relevant code in the repo. A how-to question gets verified against the live docs. This is the step that surprised me most in how well it works.

Check email first. Before drafting, the agent searches my email client for an existing thread from that address in the last 30 days. People email support minutes after the chatbot tells them a human will follow up. If the conversation already happened by email, the thread is skipped.

Create the draft in my email client. It is not allowed to send. Every draft waits for me.

Archive the thread and record the visitor id, the action taken and the reason in the state file. Skips get recorded too, otherwise the next run re-reads the same spam.

Report. The support section lands in the same 6am email as errors, traffic and uptime, with one line per thread and links to the drafts.

The whole run is wrapped in a 20 minute timeout, so a hang can never block tomorrow's run.

The two rules that do most of the work

Everything above is plumbing. Two lines in the skill file are what make the output trustworthy.

"Never guess. Every claim in a draft must be verified this session or absent from the draft." An LLM without this rule will happily hallucinate features you don't have, in a confident and friendly tone, to a paying customer. With the rule, a claim either got checked against code, docs or error logs during the run, or it does not appear. Drafts that follow it read like they were written by someone who actually looked into the issue, because something actually did.

"NEVER send. Drafts only." The skill's hard-limits section bans the send tool entirely. The only way a reply reaches a customer is me pressing...