Client Support Desk
How a SaaS company cut response times from 4 hours to 12 minutes by routing support queries through local AI.
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:
- Password resets and login issues — 30% of tickets, 30 seconds to solve, but they queue behind everything else
- "How do I do X in the software?" questions — 40% of tickets, 2-5 minutes to answer, same answer every time
- Bug reports — 15% of tickets, need investigation and routing to engineering
- Account changes — 10% of tickets, need admin access and verification
- Genuine complex issues — 5% of tickets, need a senior support engineer
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:
- Average response time: 4-6 hours for routine tickets
- Customer satisfaction score: 68% — clients are paying for support that feels absent
- Two support agents spend their entire day on password resets and "how to" questions
- The senior engineer spends 2 hours/day triaging tickets instead of fixing bugs
- Three enterprise contracts include SLAs requiring 1-hour response times — they're missing them
The MD, Tom, tried the obvious fixes:
- Hired two more support agents. Helped for two months, then volume grew again.
- Built a help centre. Usage is 12%. People email instead of searching.
- Used Intercom's AI bot. It answered basic questions but sent sensitive account data through OpenAI's API. Their housing association clients — who manage tenant data subject to GDPR and housing regulations — weren't happy. One procurement team flagged it as a data processing risk.
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:
- Foundry reads it. It understands what the customer is asking, not just keywords.
- It checks the knowledge base. Has this question been answered before? Is there a help article?
- 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.
- For account-specific actions, it verifies the customer's identity and account status before drafting.
- For bug reports, it reproduces the issue description, captures system info, and routes to engineering with a structured summary.
- 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:
- 7 password resets → auto-resolved with reset links, awaiting agent approval (green)
- 4 "how to export" questions → drafted responses with screenshots, awaiting approval (green)
- 3 "how to add a user" → drafted responses (green)
- 2 billing questions → drafted with account info (yellow — needs admin verification)
- 5 bug reports → summarised and routed to engineering (blue)
- 2 complex integration issues → passed to senior engineer with context summary (red)
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
| Metric | Before | After | Change |
|---|---|---|---|
| Average response time (routine) | 4-6 hours | 12-15 minutes | 95% faster |
| Average response time (complex) | 6-8 hours | 2-3 hours | 60% faster |
| Tickets resolved per agent per day | 25-30 | 60-80 | 2-2.5x |
| Customer satisfaction score | 68% | 91% | +23 points |
| SLA breaches (1-hour response) | 4-6/month | 0/month | Eliminated |
| Senior engineer time on triage | 2 hours/day | 20 mins/day | 80% reduction |
| Support staff cost | 6 FTE | 5 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
- Email delivery (tickets arrive via email, processed locally)
- The help centre articles (still hosted online)
- Engineering tools (Jira, GitHub — Foundry doesn't touch these)
- Video call support (still uses Zoom/Teams)
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
- Does not send responses without human approval. Every reply is a draft until an agent clicks "send."
- Does not access or modify customer accounts. It can verify identity and status, but account changes need an admin.
- Does not replace the support team. It handles the first draft and the routine cases. Complex issues, angry customers, relationship management — that's still very much human work.
- Does not learn from customer data in ways that leak between clients. The model runs locally. Northstar's data stays on Northstar's hardware.
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:
- Software/SaaS companies with 50+ support tickets per day
- B2B companies with data-sensitive clients who restrict cloud AI usage
- Teams where routine tickets block complex issue resolution
- Companies that already have or can accommodate a Mac Studio
Not a fit if you:
- Have very low ticket volume (<30/day) — human-only is fine at that scale
- Need sub-second real-time chat (Foundry processes in seconds, not milliseconds)
- Have no technical person to review the initial setup
- Want a fully cloud-hosted solution
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.