Build an AI Email Triage System for University Admissions Step-by-Step Guide

2. System Architecture

Five components, each replaceable. Built for self-hosted n8n so a university IT department can audit every byte that touches student data.

The stack

Cost estimate (10,000 emails/month)

n8n’s built-in Gmail Trigger fires on every new inbound message in a watched label. For Outlook, use the Microsoft Outlook node with OAuth2. For institutions on legacy mail servers, IMAP IDLE works but adds 5–15s latency.

OAuth setup (Gmail example)

1. In Google Cloud Console: create OAuth client (web app), add n8n callback URL.
2. Enable Gmail API for the project.
3. In n8n: Credentials → Gmail OAuth2 → connect, sign in as the shared admissions inbox account.
4. Set scopes: gmail.modify (read + label, no delete).

Filter rules (skip the noise)

Roughly 30% of inbox traffic is automated: bounce notifications, calendar invites, newsletter replies. Filter at the trigger to save API spend.

label:inbox -from:noreply -from:no-reply -subject:"Out of Office"
-subject:"Auto-Reply" -filename:ics newer_than:1d

Every email gets one Haiku call: classify into one of seven categories, output a confidence score. Haiku handles 10k/day at ~$0.80 cost — essentially free at this volume. The same classification pattern powers our automated FAQ systems for SaaS support inboxes.

The 7 categories

Classification system prompt

Copy-paste ready. Tested at ~94% accuracy on a 500-email validation set.

You are an admissions email classifier for a university.

Read the email below. Output ONLY valid JSON, no prose.

Schema:
{
  "category": "application_status" | "document_question" |
              "deadline_inquiry" | "program_specific" |
              "financial_aid" | "decision_appeal" | "complaint_or_legal",
  "confidence": 0.0 to 1.0,
  "language": "en" | "he" | "es" | "zh" | "other",
  "applicant_id_mentioned": null | "string",
  "urgency": "low" | "normal" | "high",
  "reasoning": "one short sentence"
}

Rules:
- decision_appeal and complaint_or_legal: confidence is irrelevant,
  these always escalate.
- If the email contains words like "lawyer", "attorney", "discrimination",
  "complaint", "ombudsman" — classify as complaint_or_legal.
- If unclear between two categories, pick the safer one (more human review).
- Detect language from the body, not the signature.

n8n HTTP Request node

{
  "method": "POST",
  "url": "https://api.anthropic.com/v1/messages",
  "headers": {
    "x-api-key": "{{ $credentials.anthropic.apiKey }}",
    "anthropic-version": "2023-06-01",
    "content-type": "application/json"
  },
  "body": {
    "model": "claude-haiku-4-5",
    "max_tokens": 200,
    "system": "{{ $json.classifierSystemPrompt }}",
    "messages": [
      {
        "role": "user",
        "content": "Subject: {{ $json.subject }}nnBody:n{{ $json.body }}"
      }
    ]
  }
}

An n8n Switch node sends each email down one of three paths based on category and confidence score.

Decision rules

The 0.85 threshold isn’t magic — tune it to your historical false-positive tolerance. Lower threshold = more auto-replies, more risk. Start at 0.9 for the first month, then drop to 0.85 once you’ve reviewed the auto-reply error rate.

For medium-confidence categories, Claude Sonnet writes a full reply with the applicant’s actual context — name, application status, missing documents, program staff name. Staff review and click send.

Context injection (RAG-lite)

Before calling Sonnet, n8n queries Postgres with the sender’s email to fetch the applicant context. The Postgres mirror is populated nightly via the same pattern we describe in automated CRM management:

• Applicant ID, name, program, application status
• Documents received vs. missing
• Assigned admissions counselor name + email
• Last 3 emails in this thread (if exists)

Draft generation prompt

You write reply drafts for the admissions office at {{university_name}}.

INPUT: an inbound email + applicant context (JSON).
OUTPUT: a complete reply ready for a staff member to send.

Tone:
- Warm but professional. American university register.
- Use the applicant's first name once, in the opening.
- Sign off with the assigned counselor's name. Not "The Admissions Team".

Hard rules — NEVER do these:
1. NEVER state a tuition figure unless it's in the context JSON.
2. NEVER predict an admissions decision.
3. NEVER promise a deadline extension.
4. NEVER mention financial aid amounts.
5. If the answer requires info not in context, say so and offer
   to connect them with the counselor.

Format:
- Plain text, no markdown.
- 80-150 words.
- One paragraph + signature.

Where the draft lands

The n8n workflow creates the reply as a Gmail draft in the same thread, applies a label like ai-draft-pending, and posts a Slack notification to the admissions channel. Staff opens the thread, reviews, edits if needed, sends — all in their normal Gmail UI.

For high-confidence FAQ-class categories, the system replies in seconds. Personalized with applicant context, signed by their assigned counselor, sent from the admissions inbox. For real-time channels like WhatsApp the same pipeline drives our WhatsApp AI agent.

Safe to auto-send

• application_status — “We received your application on March 12. We’re currently reviewing all materials. You’ll hear from us by April 15.”
• document_question — “We’ve received your transcript and recommendation letters. We’re still waiting on your financial documents.”
• deadline_inquiry — “The deadline for the BSc Computer Science program is May 1, 2026 (early decision: February 1).”

Never auto-send

• Admissions decisions (accept/reject/waitlist)
• Financial aid figures or scholarship awards
• Anything mentioning legal terms, complaints, or appeals
• First-time applicant onboarding (give a human first impression)

The personalization loop

Auto-reply isn’t a templated form letter. The Sonnet draft prompt runs identically — same context injection, same tone rules — then n8n sends it directly via Gmail API instead of saving as draft. The applicant sees a reply with their name, their program, their counselor’s signature.

Every classification, draft, and send writes to a Postgres table. After 30 days you have data to find the system’s blind spots.

Logging schema

CREATE TABLE admissions_email_log (
  id              uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  received_at     timestamptz NOT NULL,
  thread_id       text NOT NULL,
  sender_email    text NOT NULL,
  applicant_id    text,
  category        text NOT NULL,
  confidence      numeric(3,2) NOT NULL,
  language        text NOT NULL,
  routing         text NOT NULL,  -- auto / draft / escalate
  draft_body      text,
  sent_at         timestamptz,
  human_edited    boolean DEFAULT false,
  edit_distance   integer,
  reviewer_email  text
);

CREATE INDEX idx_log_received ON admissions_email_log(received_at DESC);
CREATE INDEX idx_log_category ON admissions_email_log(category);

Weekly improvement query

Find the categories where humans rewrite drafts heavily. Those are your prompt-tuning targets.

SELECT
  category,
  count(*) as total,
  avg(edit_distance) as avg_edits,
  count(*) FILTER (WHERE human_edited) as edited_count
FROM admissions_email_log
WHERE received_at > now() - interval '7 days'
  AND routing = 'draft'
GROUP BY category
ORDER BY avg_edits DESC;

Common Failures & Fixes

Three failure modes show up in every implementation. Plan for them on day one, not after the first incident.

Failure 1: Hallucinated tuition figures

Symptom: Draft says “Tuition is $54,000/year” — the actual figure is $48,500.

Fix: Never let the model generate numbers. Inject the current figure via context. If the context doesn’t have it, the prompt forces “I’ll connect you with your counselor for the exact figure” — never an invented one.

Failure 2: Wrong-language replies

Symptom: Chinese applicant writes in English (signature still in Chinese), Sonnet replies in Chinese.

Fix: The classifier prompt explicitly says “Detect language from the body, not the signature.” Pass the detected language to the draft prompt as a constraint: “Reply in: en”.

Failure 3: Over-confident classifier on edge cases

Symptom: Email says “I’d like to know about your scholarship for international students” — classifier picks deadline_inquiry with 0.92 confidence and auto-replies with a generic deadline answer.

Fix: Add a keyword overlay that downgrades confidence to 0.5 if the email contains specific terms (scholarship, aid, financial) regardless of the model’s category pick. Crude but effective — the cost of wrong auto-reply on financial topics is high. We document the same defensive layering for high-stakes domains in our non-profit automation guide.

Privacy: FERPA & GDPR

University admissions data is regulated. FERPA in the US, GDPR in the EU, and many countries have similar rules. The system must be auditable.

What Claude sees (and doesn’t)

• Sees: Email body, subject, applicant first name, application status (pending/under review/decided), program name.
• Doesn’t see: SSN, date of birth, financial documents, transcripts, GPA, test scores, decision rationale.

The Postgres applicant lookup table is a deliberately reduced mirror of the CRM — only the fields needed for replies. No PII beyond name and email.

Data residency

Anthropic offers Claude API in multiple regions. For GDPR compliance, route requests through the EU endpoint. For FERPA, sign Anthropic’s BAA-equivalent agreement (commercial agreement covering education data).

Audit trail

Every API call is logged with: timestamp, prompt hash, model used, response, human reviewer (if applicable). FERPA-aligned 7-year retention by default.

Measured Results — 90 Days In

Numbers from a real implementation at a private university (12,000 students, 4-person admissions team) after the first admissions cycle.

The auto-reply rate of 54% means human staff handled 46% — but the 46% they handled got their full attention, with AI-generated drafts as a starting point. Edit distance averaged 38 characters per draft (mostly tone tweaks, not factual corrections).

Implementation Timeline & Cost

FAQ