Project: service request performance dashboard for a customer service team

Monday Morning Standup. Picture a city 311 customer service center on a Monday morning. Twenty agents, a wall screen, and a manager who asks one question at the standup: are we closing requests as fast as we promised residents? Right now the answer takes an analyst an hour and three spreadsheets, and by the time it arrives, the potholes have multiplied. That delay costs trust, because residents who report a broken streetlight and hear nothing for two weeks stop reporting. In this project lesson, you'll pull together everything from this course. You'll use serial charts, a gauge, a list and a table to build one dashboard that answers the manager's question in seconds.

What You Will Learn. By the end of this lesson, you'll be able to do three things in ArcGIS Dashboards, the ArcGIS Online app for building live, one-screen displays. First, turn a manager's plain questions into a layout, choosing the right element for each question. Second, build a gauge, a serial chart, a list and a table on the same service request layer, each configured the way earlier lessons showed. Third, connect those elements with a category selector, so that when someone filters to potholes, every number on screen changes together and nobody sees two answers that disagree.

From Questions to Layout. Start with questions, not widgets. The manager gave us four. Are we on time? That's one number against our ninety percent target, so it's a gauge. Where is the workload? That's a comparison across categories, so it's a serial chart. What is late right now? That's a short action list of individual records, so it's a list element. Which team needs help? That's a summary per team, so it's a grouped table. Notice that all four elements read from a single hosted feature layer of service requests. Keeping one source is the quiet secret that makes everything else in this project easier.

Check the Data First. Before building anything, confirm the layer has what the questions need. Each request needs its type, its status, the days it has been open, and its SLA. SLA stands for service level agreement: the number of days the city promised to fix that kind of problem, like a delivery window for a parcel. Dashboard filters compare a field to a fixed value, never to another field, so we store two helper fields in the layer itself with the field calculator. is_overdue is 1 for an open request whose days open are greater than its SLA days, and met_sla is 1 for a closed request that was fixed within its SLA. Here's a tiny sample in pandas that follows the gauge's rule: only closed requests count toward the on-time rate. Five requests are closed and four met their SLA, so the rate is 80 percent. Two open requests are overdue. If your quick sample check matches what the dashboard shows later, you can trust the configuration.

Gauge: On-Time Rate. The gauge goes top left, where eyes land first. A gauge shows one statistic, so set its value to the count of closed requests this month where met_sla equals 1. Then set the maximum from a statistic too: the count of all closed requests this month. Choose to display the value as a percentage of that maximum. Say that's 408 out of 480, which works out to 85 percent. Add a guide at the 90 percent target, and color the ranges: red below 80, amber from 80 to 90, green at 90 and above. So what does the manager learn at a glance? We're close, but not there yet, and that's exactly the conversation the standup needs.

Serial Chart: Where the Load Is. Next, a serial chart of open requests. Set the category field to request type, the statistic to count, and a filter for status not equal to closed. Here are five request types with their current open counts. Now sort descending by value, so the biggest bar always sits on the left, whatever the numbers are next week. Right away, potholes dominate with 42 open, more than streetlights and graffiti combined. Try adding a split by priority field as well, so each bar shows how much of that load is urgent. A tall bar of low priority work means something very different from a tall bar of emergencies.

List: What Is Late Right Now. The list element is the team's to-do view. Filter it to is_overdue equals 1, the helper field we stored earlier, which marks open requests past their SLA. Sort by created date ascending, so the oldest overdue request sits at the top, because that resident has waited the longest. Set maximum features to 25. A list of 400 rows is a report, not a to-do list. Use advanced formatting with a short Arcade expression. Arcade is the short formula language ArcGIS uses to calculate and format values. Show each row as the request type, the street address, and the days late, days open minus SLA days, in red. Supervisors can now click a row and send someone out.

Table: Which Team Needs Help. The last question is about teams, so use a grouped table instead of a feature table. A feature table shows every record, one row each. A grouped table rolls records up into one row per group, much like a pivot table in a spreadsheet. Filter it to open requests, group by assigned team and add three statistics. Open requests is a count. Overdue requests is the sum of is_overdue, because adding up ones and zeros counts the overdue jobs. The third is average days open. An average is simply the total days open divided by the number of open requests. Sort by overdue count, highest first. Now five rows tell the manager that the East roads crew has nineteen overdue jobs while every other team has fewer than six.

Link Everything With a Selector. Now make the dashboard interactive. Add a category selector in the header, driven by the request type field. In its actions, choose filter, and tick all four targets: the gauge, the chart, the list and the table. Here's the payoff: pick streetlights, and the gauge shows the streetlight on-time rate, the list shows only overdue streetlight jobs, and the table shows which team owns them. One click turns a citywide dashboard into a focused briefing for the lighting supervisor, with no second dashboard to maintain.

Common Mistake: Numbers That Disagree. The most common failure in this project isn't a broken chart, it's two elements that quietly disagree. Someone picks potholes, the chart updates, but the table still shows every type, because it was never ticked as a target of the selector's action. Or the gauge uses this month while the table uses all time. The manager spots the mismatch and stops trusting the whole screen. So test every selector choice and watch every element change. Keep date filters identical, or state the difference plainly in each title, for example, closed this month versus open right now.

Recap. Let's recap. First, design from questions: a target question becomes a gauge, a comparison becomes a serial chart, a to-do list becomes a list element, and a summary per team becomes a grouped table. Second, build every element on the same service request layer and verify one number against a quick sample check, so you know the configuration is right. Third, connect everything with selector actions and test that every element responds, because a dashboard that disagrees with itself loses its audience fast.

Your Exercise. Now it's your turn. Pick a Living Atlas or sample layer in ArcGIS Online with a status or category field, such as service requests, water main breaks or utility outages. Write down three or four questions a manager would ask. Then build a dashboard with a gauge against a target, a serial chart by category, a list of the oldest open items, and a grouped table by team or district. Add one category selector that filters all four elements. Finally, test three different selector choices and note any number that doesn't agree. Bring those notes to the next lesson.