Blueprints
AI & LLM Routing
Classify inbound support email by intent and urgency, draft a reply for the common cases, and escalate the rest with a summary attached.
Make.com · Claude · Gmail · Slack · Airtable
1-Click Clone Scenario: Opens Make.com. The free tier covers 1,000 operations a month, which is enough to run this against a real inbox for a fortnight.
Download the Blueprint JSON: The exported scenario, the classification prompt, and the Airtable schema.
Support mail arrives in one inbox and a person reads every message to decide who it belongs to. Most of them are the same six questions. The triage itself is not hard, it is just constant, and it happens before anyone has done any actual support.
Everything this blueprint calls. Check you have them before you start - the usual reason a build stalls halfway is a key that takes a day to get approved.
Runs the scenario. At roughly 6 operations per email, 1,000 free operations handles about 160 messages a month.
Free tier: 1,000 operations a month, no card
Does the classification. Around $0.002 per message on the cheapest model, which is the entire AI cost of this blueprint.
Free tier: Pay as you go, no minimum
Holds the decision log so you can audit what was routed where and tune the prompt against real misses.
Free tier: 1,000 records per base
The trigger watches a shared support address. Any IMAP mailbox works with one module swapped.
Some links above are partner links and we earn a commission if you sign up through them. It costs you nothing extra, and it does not decide what goes in a blueprint - the self-hosted option is recommended wherever it is genuinely the better call.
Monthly, at the volumes this blueprint was tested against. Worth comparing against what the manual version of this work costs you in hours.
| Component | Cost | At what volume |
|---|---|---|
| Make.com | $0 - $10.59/mo | Free to 1,000 ops, then Core at 10,000 ops |
| Claude API | ~$2.00/mo | At 1,000 messages, Haiku, short prompts |
| Airtable | $0 | Well inside the free record limit |
The files
The exported Make scenario imports straight into your account. The prompt is the part that took longest to get right, and it is included as written rather than paraphrased.
support-triage.blueprint.json - the full Make scenario
The classification prompt, with the confidence threshold we settled on
Airtable base schema as a CSV you can import
A test set of 40 anonymised support emails to benchmark against
The decisions that matter, in the order you will meet them. Everything here is a thing that broke in testing before it was a rule.
Trigger on new mail in the shared address rather than on a Gmail label. Label-based triggers fire again every time a rule touches the message, and you end up classifying the same email four times and paying for all four.
The classifier returns JSON and nothing else. Free-text answers parse fine in testing and then one reply opens with "Certainly!" and the router breaks. Constrain the shape and validate it before branching on it.
{
"intent": "billing | technical | sales | spam",
"urgency": "low | normal | high",
"confidence": 0.0,
"summary": "one sentence, under 160 characters",
"suggested_reply": "empty string when intent is sales or spam"
}Below 0.75 the message goes to a human regardless of what the model decided. This single rule is the difference between a router your support lead trusts and one they quietly turn off in week three.
For routine intents the scenario writes a Gmail draft and notifies the owner. Sending autonomously is a much larger decision than it looks, and drafts capture most of the time saved at none of the risk.
Each run appends the message id, the model output, the branch taken, and the final action to Airtable. Without that row you cannot tell whether a complaint about routing is a prompt problem or a one-off, and you have nothing to tune against.
The difference between a demo and something you can leave running is entirely in this table. Every row is a failure the blueprint handles explicitly rather than hoping about.
| Failure | What happens |
|---|---|
| Anthropic returns a 429 | Make retries three times with backoff, then routes the message to the human queue untouched. |
| Model output fails JSON parse | Caught by the validator, logged with the raw text, message escalated rather than dropped. |
| Airtable write fails | Non-blocking. The routing action still completes and the row is queued for the next run. |
| Same email triggers twice | Message id checked against the log before classifying, so a replay costs one lookup rather than one model call. |
What the classifier returns for a real message.
{
"intent": "billing",
"urgency": "high",
"confidence": 0.91,
"summary": "Customer charged twice for the October invoice, asking for a refund.",
"suggested_reply": "Thanks for flagging this - I can see two charges on 3 October..."
}Done-For-You
The blueprint handles a clean inbox. Yours has fifteen years of aliases, a legacy ticketing system, and rules nobody remembers writing.
A TechZapp sprint is a fixed-scope, fixed-price week. A senior engineer builds it in your environment, hands over the repository and the runbook, and you own every part of it afterwards. No platform of ours to keep paying for.
Prompt tuned against your last 500 real messages, with measured accuracy per intent
Connected to your helpdesk rather than to a Gmail draft
Confidence thresholds set per intent and a review queue your team actually uses
Sprint pricing
One sprint, typically 5 working days
Fixed scope agreed before we start
Built in your environment, not ours
Repository, infrastructure, and runbook handed over
Two weeks of support after handover included
Scope This SprintTell us what you are integrating with. We reply within one business day, and we will say plainly if the blueprint above already covers it.
We design, build, and run the internal systems that move your business - workflow automation, custom software, and the integrations that hold them together.
Prestige Tech Park, Outer Ring Rd, Marathalli, Kadubeesanahalli, Bengaluru, Karnataka 560103