Overview

Follett Help Desk was envisioned as a full-featured support platform for education technology teams. The goal was to help schools manage requests, schedules, priorities, assignments, escalations, documentation, and asset-related support workflows from a single product experience.

The effort became more attractive after Follett was acquired by Francisco Partners and later acquired Master Library, which already had help desk functionality that could be leveraged and expanded.

The business opportunity was clear: many Follett customers already needed help desk functionality that worked alongside educational research, title procurement, content management, and resource management workflows.

Challenge & Opportunity

The help desk market already included mature competitors such as Zendesk, Freshdesk, Jira, and ServiceNow. To compete meaningfully, Follett needed to offer more than basic ticket management.

For schools and districts, the deeper problem involved educational technology assets. IT directors needed to know where devices were located, what condition they were in, whether they were usable, whether they were nearing the end of their projected lifespan, and how those realities affected budget planning.

The opportunity was to design a platform that supported both day-to-day help desk activity and longer-term operational planning.

User Groups

The platform needed to support multiple user groups with different priorities and responsibilities.

• Admins and IT Directors: Needed visibility into asset status, planning, reporting, and budget implications.
• IT Managers and Help Desk Technicians: Needed tools for assigning, tracking, escalating, resolving, and documenting tickets.
• Students and Educators: Needed a straightforward way to request help, report issues, and understand support status.

Research & Competitive Analysis

Competitive research played an important role in shaping the product direction. I evaluated Zendesk, Jira, ServiceNow, and Freshdesk, documenting their strengths, weaknesses, workflows, and solution patterns.

I also created competitive analyses and user journey maps, then participated in and facilitated customer interviews to better understand how users felt about existing help desk products.

Those conversations helped compare competitor experiences against Follett’s proposed working prototypes during discovery, roadmapping, and development.

My Contribution

I contributed to the UX research, competitive evaluation, journey mapping, workflow design, and prototype validation of the Follett Help Desk platform.

• Evaluated competing help desk platforms
• Created competitive analysis documentation
• Mapped user journeys for multiple user groups
• Participated in and facilitated customer interviews
• Supported discovery, roadmapping, and product development
• Designed and refined screens for support and asset-management workflows
• Helped translate customer feedback into actionable product direction

Key Design Decision

One of the most important decisions was recognizing that the platform should not be limited to traditional ticketing workflows.

Requests, scheduling, prioritizing, assigning, escalating, tracking, and archiving were necessary baseline functions. But the more meaningful design opportunity lived in asset management: helping schools understand the status, location, prognosis, and lifecycle of the devices they depended on.

That shift moved the product from a reactive support tool toward a more strategic operational planning platform.

Product Features

The initial design included baseline functionality expected from a modern help desk platform while also supporting education-specific operational needs.

• Help desk requests
• Ticket scheduling
• Priority assignment
• Status tracking
• Ticket assignment and ownership
• Escalation workflows
• Archiving and associated documentation
• Asset status visibility
• Device lifecycle and replacement planning
• Budget planning support for IT leadership

Delivery Pressure

The project faced significant schedule pressure when customer interviews and feedback sessions were delayed. Because that feedback was essential to shaping the final product direction, the design timeline compressed dramatically.

To keep the project moving, I completed a major screen delivery push under intense time pressure, including an all-night effort to ensure final assets and screens were delivered on schedule.

Despite the stress and compressed timeline, the team delivered the required materials on time.

Outcome

Follett Help Desk became a robust product concept rooted in real user needs, competitive analysis, customer interviews, journey mapping, and working prototypes.

The project helped clarify that school IT teams needed more than ticket routing. They needed operational visibility into the assets, devices, and infrastructure that supported learning environments.

Reflection

Looking back, the strongest lesson from this project was that help desk products are rarely just about help desks.

For education technology teams, every support request can connect to a larger operational question: where is the asset, what condition is it in, how long will it remain useful, and what will it cost to replace?

Designing for that broader context helped reframe the platform as a tool for both immediate support and long-term planning.

The most valuable help desk systems don’t simply resolve problems. They help organizations anticipate them.