Video: Augusta University Online Case Study: Help Desk Software for Universities That Scales Without the Chaos
Augusta University Online (AUO) launched and grew fast, with more programs, more students, more faculty needs, and a rising volume of support requests. Early on, AUO handled support the way many university teams do: email threads, spreadsheets, and manual follow-ups. It worked until growth made it fragile.
This case study is told through the lens of Jessica Driver, AUO's former Instructional Technology Coordinator, who led the implementation of Mojo Helpdesk for the online division. With nearly two decades of experience in education across K–12 and higher ed, Jessica has led many system rollouts. Still, she called this one of her favorites because it was practical, streamlined, and immediately functional for the people working in it every day.
Here's what AUO built with Mojo Helpdesk as help desk software for universities and university IT help desk software:
- A clear intake experience for students and faculty
- A higher ed ticketing system that people actually use
- Help desk automation (starting with automated ticket routing)
- Self-service knowledge base designed to reduce repeat requests.
We were having a mix of answering emails and trying to track everything in an Excel spreadsheet.
That becomes overwhelming really quickly.
The "before" state: why universities outgrow email and spreadsheets
Jessica described AUO's early workflow with a visual: Post-it notes everywhere. Requests came in via email, and the team tried to track everything in Excel, which worked at low volume but was not sustainable as programs and support volume increased.
The turning point wasn't theoretical. A team transition revealed how much the process depended on people remembering things and manually keeping the spreadsheet "true."
We had a transition in our student success team… [leadership] recognized that as the perfect time to rethink how we were tracking student issues.
What AUO needed from help desk software for universities
Augusta University Online's "must-haves" were practical, and that's why they worked:
- Easy to set up (no heavyweight rollout)
- Easy to use (students and faculty shouldn't need training)
- Able to grow over time (more programs, more volume)
- Cost-effective (budgets are real)
We needed something that was easy to set up, easy to use, and something that would grow with us over time. And… it had to be cost-effective.
Why Mojo stood out for university support teams
AUO didn't want a complex system that creates more work. They needed a platform that would let a small team stay organized as programs expanded without forcing students and faculty to learn a "system" just to ask for help.
A lot of these systems are very, very heavy and overly complex, but Mojo let us build out something that fit exactly what we need.
What stood out about Mojo Helpdesk for AUO wasn't a long feature checklist. It was the combination of:
- Flexibility to mirror how AUO already categorized requests (so the team didn't have to reinvent processes from scratch)
- A clean end-user experience that kept intake simple for students and faculty
- The ability to layer in automation over time (instead of doing a massive, fragile setup on day one)
In other words, Mojo made it realistic to build a higher ed ticketing system that could grow with AUO, without the "heavy" setup and ongoing admin burden that often comes with more complex platforms. That matters in universities where support teams are lean, stakeholders are busy, and adoption lives or dies on how easy the process feels for the person submitting the request.
For university stakeholders who want to see how Mojo supports service desk workflows, read more about our IT service desk for higher education.
University ticketing setup: one door, then branching
AUO avoided the classic mistake of launching a maze of ticket forms. Instead, they created two clear starting points – one for students and one for faculty, and used branching questions to collect the correct details without overwhelming users.
We ultimately decided to create one ticket for our students and one ticket for our faculty. From there, the ticket branches out based on the category they choose…
In practice:
- The student intake operated like a student support ticketing system: clear, simple, and designed to reduce back-and-forth.
- The faculty intake acted as a lightweight faculty support portal: a predictable place to request help without digging through inbox threads.
This is what "simple helpdesk" should actually mean: clear entry, smarter follow-ups, fewer clarifying emails.
Help desk automation: routing first, then reporting-ready data
AUO treated automation like a foundation, not a bonus feature. They started with the one thing that protects a small team at scale: automated ticket routing, getting requests to the right owner immediately through automatic ticket assignment. That single change eliminates the most common bottleneck in university support: manual triage and inbox forwarding. When the right person receives the ticket first, resolution starts faster and fewer tickets stall because someone "didn't see it."
The first thing I focused on was making sure that the tickets were being routed to the correct agent.
From there, AUO built automation that made the system easier to manage over time. They automated tagging and classification (program and category), so tickets stayed consistently organized without extra manual steps from staff. That consistency matters for two reasons:
- It reduces day-to-day mess
- It makes reporting trustworthy
When categories are applied the same way every time, you can actually see patterns – what students ask most, where faculty get stuck, which programs generate the most requests, and where self-service content could prevent repeat tickets.
In short, routing handled the "now" problem (speed and ownership), and tagging dealt with the "next" problem (visibility and decision-making).
Rollout strategy: students first, then faculty
AUO rolled out the new workflow to students first because timing and priorities demanded it. New students adopted it quickly because it was simply "how support works."
The students adopted it quickly… it was the only system that our new students ever knew.
Two rollout moves that consistently work in universities:
- Put the support link where users already work (for AUO: directly inside courses)
- Add an auto-reply on the old support inbox that redirects people to the new process
Testing: "try to break the system" before going live
Before launch, Jessica asked the internal team to submit tickets across categories to validate branching logic, automation behavior, and correct routing.
I sent it out to our team and asked them to submit tickets… I wanted to make sure branching and automations… were routed to the correct agent.
This kind of testing catches the problems that are hardest to recover from after go-live:
- Misrouted tickets
- Missing follow-up questions
- Automations that don't fire when they should
It also gives the team confidence in the workflow before students ever touch it, reducing resistance and preventing the "we should just go back to email" backlash. Universities don't need "perfect." They need "predictable." This step is how you get there.
Knowledge base: structured self-service for two audiences
AUO didn't treat documentation as a side quest. They built a self-service knowledge base from existing materials, then structured it for two distinct audiences so articles stayed relevant and easy to find.
We… created two separate topics, one for students and one for faculty.
That decision sounds simple, but it prevents a common university problem: students wading through faculty-only guidance (and vice versa), which drives unnecessary tickets. It also makes it easier to keep content current, because each audience has a tighter set of "most asked" topics to maintain. Over time, this becomes one of the most effective ways to reduce repeat requests, especially during predictable moments such as term starts, orientations, and course launches.
Results: faster turnaround and satisfaction that boosted the team
Jessica called out two immediate signals that the system was doing what AUO needed:
- Faster handling and turnaround
- Satisfaction ratings that validated the change and boosted morale
The turnaround time improved almost immediately…
Whenever I got a five-star rating… it was like this little boost of dopamine.
Those early wins matter in a university environment because they create momentum, and staff buy in faster when they can feel the improvement in their day-to-day workload. And once users see quicker responses, they're more likely to keep using the system rather than fall back on email or one-off workarounds.
Lessons learned for universities implementing a help desk
Jessica's advice is implementation truth, not theory:
- Build a strong foundation and know your end goal.
- Use clear system naming, primarily when automation relies on it.
- Identify your key players early and involve them in the build.
- Create a real implementation plan (build → test → launch → iterate).
Have a strong foundation from the very beginning [and] know your key players.
See Mojo Helpdesk in action for your university
If you're evaluating help desk software for universities (or help desk software for colleges), AUO's playbook is clear: keep intake simple, route correctly from day one, automate repeat work, and publish a knowledge base that prevents the same tickets from returning.
The next step is to see whether that workflow fits your environment.
- Book a demo to walk through your student and faculty intake, routing rules, and reporting needs.
- If you're already building a shortlist and need to confirm budget alignment, review our education helpdesk pricing.
- And if you're comparing tools side-by-side, these competitor comparisons show how Mojo stacks up in common evaluation scenarios:
