Support Dashboard Template

This is a layout for a support queue, and there is no file to download. Bring one row per ticket carrying a created date, a channel, a priority, a category, a first-response time, a resolution time, a status and a satisfaction score. Drop it, and the volume, backlog, speed and CSAT panels build themselves. The columns are the template.

Load the template with sample data

The sample is the fastest way to see whether this layout fits before you go and find your own export. Six hundred tickets, already in shape, charted the moment the page loads.

Download the sample CSV

The column contract

Nine columns, and each one earns its place by making a specific panel possible. Match the names and the roles are inferred without you choosing anything. Miss one and the panels that depend on it quietly do not appear, which is better than a broken chart but worse than the dashboard you wanted.

Column	What it holds	Role	Required	What breaks without it
`ticket_id`	The helpdesk reference, like TCK-5000	Identifier	Optional	Nothing visual, but you lose the ability to trace an outlier back to a real ticket, and duplicate rows become invisible.
`created_date`	The day the ticket was raised	Date	Required	Every trend panel disappears. Volume over time, the response-time line and any week-on-week comparison all hang off this one column.
`channel`	email, phone, chat, web and so on	Category	Optional	You cannot see where the load comes from, which is the number that decides staffing for a phone line versus a chat widget.
`priority`	low, normal, high, urgent	Category	Optional	Response times stop being comparable. A four-hour median across a queue containing both password resets and outages tells you nothing about either.
`category`	The reason for contact, like Outage or Billing	Category	Optional	The breakdown panel that tells you what to go and fix is gone. Volume without a reason column is a number you cannot act on.
`first_response_min`	Minutes from creation to the first human reply	Count (duration)	Required	The responsiveness half of the dashboard vanishes, and with it the only metric a customer actually feels in the first hour.
`resolution_min`	Minutes from creation to closure	Count (duration)	Required	No throughput view. You can still see how fast you answer, but not whether anything gets finished.
`status`	solved, pending, open, closed	Category	Required	Backlog becomes uncountable. Without status every panel silently mixes finished work with work still in flight.
`satisfaction`	A 1 to 5 rating left by the requester	Rating	Optional	The CSAT strip and the quality-versus-speed comparison go. Speed alone rewards closing tickets fast and badly.

What you get

Panels, in this order, assembled from the contract above:

A KPI strip. Total tickets, open tickets, median first response, median resolution and average satisfaction. Median rather than mean on both durations, because one ticket that sat over a public holiday will drag a mean somewhere no customer lives.
Ticket volume over time. Created tickets per day, bucketed to weeks or months when the span gets long. This is the panel that shows you a release went out badly.
Volume by channel. A bar per channel, sorted by count. Phone and chat carry different cost per contact, so the mix matters as much as the total.
Volume by category. The reasons people wrote in, largest first, with a tail folded into Other so the axis stays readable.
Status breakdown. Solved against open against pending, which is your backlog stated honestly rather than as a single number in a headline.
Response time by priority. The panel that says whether urgent actually means urgent in practice or only in the dropdown.
Resolution time distribution. A histogram, because support durations are never normal. There is a fat cluster under a day and a long right tail, and the shape of that tail is the real story.
Satisfaction by category. Average rating per reason for contact. Billing questions and outages usually score very differently, and averaging them together hides both.

i. Bring these columns

Start from the table above and rename your export's headers to match. This is nearly always the whole job. A helpdesk export tends to have the right data under names nobody would guess, and the fix is a header row, not a transformation. I usually do it in a text editor on the first line of the file, which takes about a minute and leaves everything else untouched.

The only real work is the durations, and it is worth doing properly. Both time columns must be plain numbers in the same unit, with no 4h 12m strings and no mixed hours and minutes. If your export gives you timestamps, subtract them first.

ii. Drop the file

Open the dashboard view and drop the CSV onto it. Every column is read once, given a role from its values rather than from its name, and matched against the contract. A column of ISO dates becomes the time axis. A column of short repeating words becomes a breakdown. A column of minute counts becomes a duration measure with a median default rather than a sum, because summing response times produces a number with no meaning.

Nothing is uploaded. The parsing and the aggregation happen in the tab, which is the only reason I am comfortable telling anyone to drop a raw ticket export with customer emails in it onto a web page at all.

iii. Adjust what you need

The layout is an opening position, not a verdict. Switch a duration panel from median to the ninety-fifth percentile if your service target is written that way. Change the time grain from days to weeks when a daily line turns into noise. Raise the top-N on the category panel when the tail is genuinely interesting rather than a list of one-off tags.

When it looks right, take each panel as PNG for the weekly review, or export the aggregated numbers as CSV so the chart in the deck and the table in the appendix are the same numbers. That single habit has saved me more arguments than any dashboard feature.

Getting your export into this shape

Helpdesk exports are all recognizably the same file wearing different names. Zendesk gives you a ticket export with Created at, Via, Priority, Group, First reply time in minutes, Full resolution time in minutes, Status and Satisfaction Score. That is the contract already, with spaces in the headers. Freshdesk uses Created time, Source, Type and a Resolution time (in hrs) column. Intercom exports conversations rather than tickets and calls the durations time to first response and time to close, both in seconds. Jira Service Management hides them inside SLA fields that export as strings like 2d 4h 30m.

So the recurring work is units, and it is worth being blunt about it. Pick minutes, convert everything to minutes, and put _min in the header so the next person can see what the numbers are. Freshdesk hours become minutes by multiplying by sixty. Intercom seconds become minutes by dividing by sixty. A Jira 2d 4h 30m string has to be parsed into a number before it is anything but text; the app will do it with a calculated column, or a spreadsheet formula will, but something has to.

Why this matters more than it sounds: the dashboard compares first response and resolution directly. If one is in hours and the other in minutes, the panel will cheerfully report that your team resolves tickets in less time than it takes to reply to them, and it will look plausible enough that somebody will put it in a slide. There is no unit metadata in a CSV to catch this. The header name is the only defense.

Two other habits worth forming. First, decide on calendar time or business time and stay there. An export that mixes them across rows, which happens when a helpdesk changes its SLA calendar mid-quarter, produces a distribution with two humps and no explanation. Second, watch the unresolved rows. Tickets still open have an empty resolution_min, and empty is correct: it is excluded from the median rather than counted as zero. If your export writes zero instead, replace those zeros with blanks before you drop the file, or your resolution time will look wonderful and be fiction.

Finally, strip what you do not need. Ticket subjects, requester emails, internal notes and full conversation bodies bloat the file and add nothing to any panel here. A ninety-day export of a busy queue drops from two hundred megabytes to under one when the free text goes.

What this template will not do

It is not live. The dashboard reflects the file you dropped and nothing else. There is no connection to your helpdesk, no refresh, no scheduled pull. Re-export and drop again when you want new numbers.
It does not compute SLA compliance. Compliance needs a target per priority and a business calendar, neither of which is in the file. You can see the distribution and judge it; the dashboard will not put a pass or fail on it.
It does not do agent-level performance. Deliberately. A file with an assignee column will get a breakdown panel like any other category, but the layout is built around the queue rather than around ranking people, and I am not going to pretend a median resolution time is a fair way to compare two agents with different ticket mixes.
It cannot see reopened tickets. One row per ticket means one status and one resolution. A ticket closed and reopened three times looks the same as one closed cleanly, unless your export carries a reopen count as its own column.
It does not model backlog over time. The status panel is a snapshot as of the export. Showing backlog properly needs both a created and a resolved date on every row and a running balance, which is a different chart than this layout builds.
It will not repair inconsistent categories. If half your rows say Billing and half say billing issue, you get two bars. Clean the values in the app first, then come back.

Frequently Asked Questions

Is there a file for me to download and fill in?

No, and that is the point. This template is a column contract rather than a workbook. The dashboard is a set of rules that fire when it sees columns named created_date, channel, priority, category, first_response_min, resolution_min, status and satisfaction. You bring the rows; the layout is what arrives. Nothing is filled in by hand, so there is no copy of the template to keep in sync when your helpdesk adds a queue.

What is the smallest set of columns that still produces a dashboard?

created_date and one of the two duration columns. With just those you get ticket volume over time and a response or resolution trend, which is already more than most weekly reports contain. Everything else deepens it: channel and category give you the breakdowns, priority gives you the urgency split, satisfaction gives you the CSAT strip, and status gives you the open backlog rather than a count of everything that ever existed.

Why must first_response_min and resolution_min be in the same unit?

Because the panels compare them and the file carries no unit anywhere. A column called first_response holding 45 and a column called resolution_time holding 8.5 will be read as 45 and 8.5, and the dashboard will report that resolution is faster than first response. Helpdesk exports are inconsistent here: Zendesk gives reply time in minutes and full resolution in hours in the same CSV. Convert both to minutes, name them with the _min suffix, and the arithmetic stops lying.

My export has a resolved_at timestamp instead of a duration. What do I do?

Subtract created_at from it and write the result into a minutes column before you drop the file. Open the export in the app, add a calculated column with the date difference, set the output to minutes, then rename it resolution_min. Timestamps on their own cannot fill a duration panel, because the dashboard has no way of knowing which pair of timestamps you meant to subtract when an export carries five of them.

Should I use business hours or calendar hours for the durations?

Whichever one your team is measured on, and only one of them in the file. Calendar minutes make every ticket raised at 5pm on a Friday look like a failure. Business minutes hide genuine weekend outages. Most helpdesks can export both; pick the one your service target is written against, and put the other in a separate file if you want to compare. Mixing them across rows produces a median that describes nothing real.

Does the satisfaction column have to be a 1 to 5 score?

It has to be numeric and it has to be consistent. The sample uses 1 to 5, which reads as a rating and renders as a small distribution plus an average. A 0 to 100 CSAT percentage works too, as long as every row uses it. What does not work is a mix of good and bad text values with numbers underneath them, or a blank meaning neutral. Leave unrated tickets empty and they are excluded from the average rather than counted as zero, which is the behavior you want.

Can I use this for a queue that spans several products?

Yes, by putting the product in the category column, or by adding a product column and letting the dashboard add a breakdown panel for it. The layout does not cap you at the nine contract columns; extra columns with recognizable roles get their own panels. What it will not do is nest one breakdown inside another automatically. For product by category at once, build a pivot or a heatmap after the dashboard has loaded.

How much history should I export?

Enough that the time axis has a shape. A single week of tickets produces a chart with seven points and no trend to see. Ninety days is usually the sweet spot for a support queue: long enough that seasonality in ticket volume shows, short enough that the categories have not been renamed halfway through. If you export a full year, expect the time grain to bucket into months, and expect some old category values that no longer exist.

Do my ticket subjects and customer names go anywhere?

Nowhere. The file is parsed and aggregated inside your browser tab and no request carrying its contents leaves the page. That matters more for a support export than for most files, because ticket exports routinely carry customer emails, account IDs and free-text complaints. If you would rather they were not in the file at all, drop the free-text columns before exporting; the dashboard does not use them.

See the layout before you find your export

Six hundred sample tickets, already in contract shape. Two seconds to know whether this is the dashboard you wanted.