Agentic AI Service Desk Dashboard

Deskline, AI agents that summarise service desk operations, answer questions about ticket data and automate team updates.

n8nGeminiSupabase Google SheetsAI agentsOrchestration

Try the live demo

Live and interactive. Built with n8n for orchestration, Gemini for the language, Supabase for ticket data and Google Sheets for the team roster.

My contribution.

I designed and built this end to end, covering the interaction design, the front end and the workflow architecture behind it. That included deciding where AI belonged and, more importantly, where it did not: which numbers the model is allowed to touch, how a question becomes a tool call, and what gets cached so the interface stays quick. The n8n workflows, the agent boundaries and the guardrails are mine as much as the interface is.

The work.

Service desk leads spend the start of every day assembling a picture that nobody owns: export the tickets, pivot them in a spreadsheet, cross-check the roster, work out who is overloaded, then write the stand-up summary by hand. The data already exists. The work is the assembly. Deskline is an attempt to remove that step entirely. You open it with your name or employee ID and the picture is already made.

n8n is the entire backend. There is no application server and no bespoke API layer. Each screen calls an n8n webhook, and the workflow behind it does the querying, the joining, the reasoning and the writing before it responds. Postgres holds the tickets, Google Sheets holds the team roster, Gemini supplies the language. n8n is what connects them. The team view is the clearest example: it reads the roster from a spreadsheet, counts live open tickets per person in the database, and joins the two on every request. That join is a reconciliation task nobody has to do any more.

Behind the scenes panel showing the n8n workflow nodes and per-node timings for a dashboard refresh and an AI brief — Every action exposes the n8n workflow that served it, node by node with real timings: webhook, filters, two Postgres queries, the Gemini brief agent at 1.3 seconds, then respond. Showing the machinery was a design decision: an agentic system you cannot audit is one nobody trusts.

Three agents, each with one job. A router agent decides whether a question is worth passing on. An analyst agent chooses a query tool, runs it against the real ticket table, and only then writes an answer from the rows that came back. That round trip is the difference between an agent and a chatbot. A brief agent turns the day's aggregates into three plain sentences. The restraint matters more than the capability: the model never counts anything. Every number on the dashboard comes from SQL, and the agents only turn those numbers into language. An LLM asked to tally rows will eventually be confidently wrong, and a wrong SLA count is worse than no brief at all.

The analyst agent answering a question about which ticket category is slowest, with the AI operations brief above it — Ask “which category is slowing us down?” and the analyst agent picks a tool, queries the tickets and answers from the result, naming Hardware at 5.1 days and suggesting why. Above it, the brief agent's three-sentence summary of the same data.

What makes it feel fast is mostly caching and guardrails. Briefs are stored for an hour, so changing a filter costs a database read rather than a model call. A cached brief returns in milliseconds against roughly a second and a half to generate one. Question length and a per-visitor limit are checked in a plain code node, ahead of anything billable. Every agent run is logged with its tool choice and timing, because a system you cannot measure afterwards is one you cannot improve.

Deskline team view listing agents with employee IDs, roles, teams and current open ticket counts — The roster lives in Google Sheets, the workload lives in Postgres, and n8n joins them on every request. Adding a member validates the details, assigns the next free employee ID, appends the row and returns a link to the sheet, one form instead of four follow-up messages.

What is real, and what is next. The demo above is a front-end preview running on sample data. The interaction design, the workflow architecture and the agent boundaries are designed and documented, and everything shown under Behind the scenes is the real intended workflow: the node sequence, the tool calls and the timings a live run would produce. The backend is not connected yet, so responses are simulated against a fixed dataset. The next build swaps the simulation for the webhooks and leaves the interface untouched.

Try the live demo All work