Support Intelligence
A morning read of a support desk for people who don't read tickets.
Support Intelligence is a dashboard that pulls the previous day's helpdesk tickets each morning, computes the counts and resolution times in code, and asks Gemini to name the recurring issues and what they mean for product, sales, marketing and operations.
- Status
- In production
- Written by
- Suraj Malla
- Updated
- Stack
- Next.js · Gemini 2.5 Flash · Redis
Facts
- Client
- The same vendor as the AI support employee
- Source
- Freshdesk REST API v2
- Model
- Gemini 2.5 Flash
- Cache
- Redis Cloud, one TTL per window
- Schedule
- Daily cron at 08:00 Kathmandu
- Size
- One page, one API route, one cron route
The problem
Leadership wanted to know what support was hearing about the product. Reading the tickets is the only reliable way to find out, and nobody had the hours.
Ticket-count reports already existed. They answer a different question.
How it works
browser ──▶ GET /api/analyze?window=24h
│
├─ cached and fresh? ──▶ return it
├─ already in flight? ──▶ join that fetch
▼
helpdesk API open · resolved · closed
│ enrich for resolved_at cap 50 / 20 / 10
│ last customer message cap 50 / 100 / 50
▼
statistics computed in code
│ total · open · unassigned · median hours
▼
Gemini ≤ 200 tickets → clusters, insights
▼
Redis, TTL ──▶ JSON- Fetches open and pending tickets from the list endpoint, and resolved and closed tickets from the search endpoint for the window.
- Enriches resolved tickets with their resolution timestamp, because the search endpoint omits it, under a cap that depends on the window.
- Pulls the last customer message per ticket, open tickets first, under a second cap.
- Detects the product from a custom field with a regex fallback, computes the statistics, and sends up to 200 tickets to Gemini for clusters and insights.
- Caches the report in Redis with a TTL, and a cron at 08:00 Kathmandu warms it before anyone opens the page.
Decisions that mattered
2
What the model is and isn't asked to do
Totals, open counts, unassigned counts and median resolution time are computed in code. The model reads the tickets and names clusters and implications. It is never asked for a number.
A model asked for arithmetic returns a plausible figure that drifts a little each run, and nothing in the output shows which run was wrong.
Keeping the cost flat
Each window caps the expensive steps: 50, 20 and 10 tickets enriched for resolution time across the 24-hour, 7-day and 30-day views; 50, 100 and 50 conversations fetched. Open tickets are fetched first, so the cap cuts the least useful end.
Concurrent requests for the same window join one in-flight fetch. Three people opening the page at 9am cost one fetch.
What isn’t shown
Same client as the AI support employee, not named. The dashboard is internal and isn't linked.