appscript.dev
Blog Gmail Sheets

How I built a lightweight help desk in Gmail and Sheets

Tickets, SLAs, and reporting for Northwind — no Zendesk, no monthly fee.

By Awadesh Madhogaria · Published Sep 14, 2025

Northwind’s support volume is modest — a handful of tickets a day. But a shared inbox with no structure still goes wrong, and [email protected] worked fine until it didn’t. With three of us reading it, the failure modes were predictable: two people would reply to the same ticket while nobody replied to the next one, “old” tickets were whatever felt old because there was no actual measure, and we had no idea of our response time, so we could not promise one.

We did not have a support problem. We had a support visibility problem. A full help-desk product would have fixed that — and it would also have cost us $1,800 a year for features we would never touch. So I built the small version instead: Gmail plus one sheet, with no new app to log into and no UI to learn.

How it works

The whole thing is the existing shared inbox, unchanged, plus a Tickets sheet with id, subject, submitter, status, openedAt, firstResponseAt, and closedAt. Gmail stays the place we do support; the sheet becomes the place we measure it. The lifecycle runs like this:

  1. A new email to the inbox creates a ticket row with openedAt set.
  2. We work tickets in Gmail using labels — in-progress, closed, and so on.
  3. A trigger watches for label changes and stamps the matching sheet row: firstResponseAt on first reply, closedAt when we close it.
  4. A daily script counts SLA breaches and posts the tally to Slack — see Build a help-desk SLA timer from Gmail.

The result is that every ticket has a clean, honest lifecycle, and the team sees the breach count each morning without anyone running a report. The one fiddly part is the label-change triggers. Apps Script does not fire an event the instant a label moves, so the trigger polls, which means timestamps can lag a few minutes behind the real action. For SLA tracking measured in hours that drift is irrelevant — but it is worth knowing before you trust the numbers to the second.

What I gave up, and what I got

Going lightweight meant being honest about what we would not have. We gave up the pretty UI, but Gmail is the UI and everyone already knows it. We gave up knowledge-base integration, but we did not have a knowledge base to integrate. We gave up macros, but plain Gmail templates cover our canned replies. None of those gaps has hurt us — they were features we were paying for, not features we were using.

What we got in return is straightforward. We replaced a $1,800/year tool with about 200 lines of script — that is $50/seat/month across three seats saved, every year, forever. And we finally have real SLA numbers, so we can promise a response time and actually keep it.

The takeaway

Before you buy a category of software, check which features you would truly use. Often it is two: a queue and a clock. Both fit comfortably inside tools you already pay for.