Case Studies › Client Support

Client Support Desk

How a SaaS company cut response times from 4 hours to 12 minutes by routing support queries through local AI.

Northstar Housing | 200 employees, 800+ customers | Mac Studio M3 Ultra 512GB

The company

Northstar Housing provides property management software to housing associations and local authorities. 200 employees, 800+ customers, and a support desk that handles 150-250 tickets per day.

Their support team is six people. They're good at their jobs. They're also drowning.

The problem

Northstar's support inbox gets a mix of:

The problem isn't volume. It's that the 70% of routine tickets block the 30% that actually need a human.

A housing officer emails at 9 AM: "I can't log in." That sits in the queue behind three bug reports and a billing question. By the time someone responds at 1 PM, the housing officer has been locked out for four hours and their own residents are complaining.

The cost:

The MD, Tom, tried the obvious fixes:

What Foundry does

Foundry runs on a Mac Studio that Northstar already had in their office for video production. It sits on the desk like a normal computer. It's quiet.

It acts as a first-responder for support tickets.

When a ticket arrives:

  1. Foundry reads it. It understands what the customer is asking, not just keywords.
  2. It checks the knowledge base. Has this question been answered before? Is there a help article?
  3. It drafts a response. For routine questions — password resets, "how do I export a report," "how do I add a user" — it writes a complete, accurate response with step-by-step instructions.
  4. For account-specific actions, it verifies the customer's identity and account status before drafting.
  5. For bug reports, it reproduces the issue description, captures system info, and routes to engineering with a structured summary.
  6. For anything genuinely complex, it passes straight to a human with a summary of what was tried.

Every response is a draft. A support agent sees the draft, confirms it's right, and clicks send. For routine tickets, that takes 10-15 seconds of reading — not 5 minutes of typing.

Over time, Foundry learns from the agent's edits. If the agent corrects the same thing three times, Foundry starts drafting it that way.

What it looks like day to day

9:00 AM — inbox check

The support dashboard shows 23 new tickets overnight:

9:15 AM — agent approves 16 routine responses

Two support agents work through the queue. Each draft takes 10-15 seconds to read and approve. They're done in 20 minutes.

9:35 AM — complex tickets picked up

The senior engineer reviews the two complex issues. Foundry has already pulled relevant previous tickets, attached error logs, and written a summary of what the customer is trying to achieve. She starts troubleshooting immediately instead of spending 15 minutes reading email chains.

3:00 PM — new ticket arrives

A housing officer reports that a tenant's data isn't displaying correctly. Foundry reads the ticket, identifies it as a data display issue (not a security issue), checks for similar past tickets, finds two, drafts a response with the previous resolution steps, and queues it. Response sent at 3:04 PM.

Without Foundry, that ticket would have been answered at 5:30 PM.

The numbers

MetricBeforeAfterChange
Average response time (routine)4-6 hours12-15 minutes95% faster
Average response time (complex)6-8 hours2-3 hours60% faster
Tickets resolved per agent per day25-3060-802-2.5x
Customer satisfaction score68%91%+23 points
SLA breaches (1-hour response)4-6/month0/monthEliminated
Senior engineer time on triage2 hours/day20 mins/day80% reduction
Support staff cost6 FTE5 FTE (redeployed 1)1 FTE freed
Monthly AI API cost£450 (Intercom bot)£0 (local)£5,400/year saved

Annual impact: £35,000-45,000 in freed staff time + £5,400 in API savings + retained enterprise contracts worth £120,000/year that were at risk due to SLA breaches.

Foundry cost: £999 setup + £99/month = £2,187 first year.

What stayed cloud

What moved local: the AI that reads tickets and drafts responses. That's the part that was sending sensitive data through OpenAI's API.

What it doesn't do

What the team says

"The first morning after we turned it on, I came in to 23 tickets and thought 'here we go.' Twenty minutes later I was getting a coffee. It's a different job now." Support agent
"I was skeptical. I thought it would send something stupid to a client and we'd lose a contract. But nothing goes out without my say-so. The drafts are good — usually 90-95% right. I just tidy and send." Senior support engineer
"Our enterprise clients asked us last year to stop using OpenAI for ticket processing. We couldn't find an alternative. Foundry was the answer — it's local, we own it, and their procurement teams are satisfied." Tom, MD

Is this right for you?

This setup works for:

Not a fit if you:

Want to see it triage a sample support inbox? Book a Foundry Fit Review →

Technical details

Hardware
Mac Studio M3 Ultra, 512GB unified memory
Model
Qwen3-Coder-30B (Q5_K_M) via llama.cpp, or comparable model suited to instruction-following
Pipeline
Email/CRM intake → classify → knowledge base lookup → draft response → queue for human review → agent approves/edits → send
Integration
Connects to existing help desk (Zendesk, Intercom, Freshdesk, or custom) via API or email forwarding
Learning
Agent edits are fed back to improve future drafts. No raw customer data leaves the local machine for training.
Observability
llm_stats dashboard showing ticket volume, draft accuracy, approval rates, and model health
No-cloud posture
All ticket reading and response drafting happens locally. Only the final approved email uses the normal email server.
Throughput
3-8 seconds per ticket to classify and draft. Handles 500+ tickets/day without queueing.

← Back to all case studies | Next: Knowledge Search →