How We Built Our LRC Appointment Dashboard with Claude Code

Every term, someone asks the same questions: which courses are students coming in for, how many appointments are we actually holding, and how is the Learning Resource Center doing? The data to answer them was always in TracCloud.

The problem was the reports. TracCloud's built-in reports are fine for what they're designed to do, but they didn't answer our questions the way we needed them answered. We kept exporting data and rebuilding the same views in Excel to fill the gaps.

So we built our own dashboard. And we didn't need a developer to do it.

What the dashboard does

The LRC Appointment Dashboard gives our staff a clear picture of what's happening in the center:

• The big numbers. How many courses we're supporting, how many appointments are on the books, and how many end in misses or cancellations.
• Demand by course and subject. Which courses and subjects are driving appointments, so we can see where coverage is thin before students feel it.
• Closure impact. If we have to close for a day because of weather, the dashboard shows how many appointments that would affect. That turns a tough call into an informed one, and tells us how many students we need to reach.
• Numbers for reporting up. The summary figures leadership asks for, without rebuilding anything.

Our LRC staff and graduate assistants use it to make day-to-day calls about where tutoring hours should go.

How we built it

1. Start with the question

Before touching any tool, we wrote down what we wanted to know. Not "make a dashboard," but "show me appointment demand by course so I can spot gaps, track misses and cancellations, and give me the totals I report each term." That sentence did more work than anything else in the project. AI tools are good at building things. They're much less good at guessing what you need.

2. Get the right data out of TracCloud

The data comes from TracCloud's Student Visits/Appointments by ?? report (yes, the question marks are part of the name), exported as a CSV.

One rule we don't bend on: student data stays protected. When you're building, give the AI tool a sample export with names, emails, and student IDs removed, or swapped for dummy IDs. Follow your campus's data policy here, not your gut.

3. Hand it to Claude Code

Claude Code is an AI assistant that works directly with files on your computer. You describe what you want in plain English, and it reads your data, writes the code, runs it, and shows you the result. You don't have to know how to code. You do have to know what you're asking for, which is why step 1 matters.

Our first request was close to this:

Here's a TracCloud appointment export. Build a dashboard that shows appointment demand by course and subject, misses and cancellations, and summary totals I can use in a term report. Keep it simple enough for student staff to use.

From there it was a conversation. Claude Code asked about columns it didn't understand, built a first version, and we reacted to it.

4. Iterate like you're coaching

The first version was close but not right, and that's normal. We'd look at it and give specific feedback: combine these two course codes, sort by volume, make this label clearer, add a view for weather closures. Small, concrete requests worked much better than "make it better." It took a couple of hours of tweaking to get it where we wanted.

If you've ever coached a student through revising a paper, you already know how to do this part.

5. Automate the data feed

A dashboard is only useful if the data is current, and nobody wants to export a report every morning. So we took people out of that step:

• TracCloud emails the Student Visits/Appointments by ?? report daily as a CSV.
• A Microsoft Power Automate flow picks up that email and saves the CSV into a Box.com folder.
• When someone opens the dashboard, it automatically pulls in the file from that folder.

The result: staff open the dashboard and see current numbers. No exports, no copying files around.

6. Keep it local

The dashboard runs locally on our own computers. It isn't hosted on a website or a cloud dashboard service. That was a deliberate choice. Student appointment data isn't sitting on a public server or in another vendor's platform, and access stays with the people who already have access to the Box folder.

What I'd tell another center

Know what your built-in reports can't do. Our reason for building wasn't that TracCloud was bad. It was that the questions we cared about weren't the ones its reports were designed to answer. Write those questions down first.

Check the numbers against the source. Before we trusted anything, we compared the dashboard's totals to what TracCloud reported directly. AI-written code can be confidently wrong. A quick spot check catches it.

Think about where the data lives. Decide early whether your dashboard needs to be online at all. Keeping ours local made the privacy conversation much simpler.

Keep people on interpretation. The dashboard shows where demand is. Deciding what to do about it, whether that's hiring, moving hours, or reaching out to faculty, is still a staff conversation.

You don't need a BI license or a developer. If you can describe the question clearly and you're willing to give feedback, you can build something useful in an afternoon.

The bigger point

Most learning centers are sitting on more data than they use. The barrier usually isn't the data itself. It's that canned reports don't ask your questions, and building your own used to take skills most of us don't have. Tools like Claude Code shrink that gap enough that a busy center can actually close it.

If you build something similar, I'd love to hear what questions you're asking of your data.