Product designSimplilearn

Making support status visible before learners ask again

A 21,000-ticket audit and 25+ learner calls traced repeat requests to missing status, unclear response times, and a broken resolved-ticket loop. A phased redesign reduced duplicate tickets by about 70% overall and by 100% in targeted LMS sources.

Role
Lead Product Designer
Duration
2 months
Team
Support operations & engineering
Scope
Research, flows & rollout specs

The helpdesk was paying for an invisible status gap

Learners were opening more than one support request for the same issue, adding avoidable volume to the helpdesk. The pattern was concentrated around LMS entry points where people could submit a request but could not easily confirm what happened next.

The work had to fit the existing Help & Support experience and the team’s established ticket-handling workflow. The goal was not a platform rewrite; it was a focused way to close the feedback gap that made repeat submissions feel necessary.

21,000+ tickets revealed the scale and shape of duplication

I analyzed a month of support data, then called learners who had raised parallel requests. The combination separated system-generated duplication from deliberate repeat behavior and exposed the specific moments where the experience stopped communicating.

21,000+
support tickets analyzed
1,400
duplicate tickets in the monthly data
25+
learners called after the data review

What the research changed

Duplicate submissions were treated as a visibility and expectation-setting problem, not simply as careless user behavior. That reframing focused the solution on the moments immediately after submission and when a learner returned for help.

579 · Added information

Learners opened another request because they did not know they could reply to the existing ticket.

238 · No answer yet

Without a visible response expectation, a second ticket felt like the safest way to get attention.

117 · System generated

Connectivity and platform bugs could create multiple requests without deliberate learner action.

330 · Replied to resolved tickets

The resolution loop let learners send a reply without making the ticket’s closed state sufficiently clear.

Audit

Classify same-day duplicates by timing, source, ticket category, and description.

Listen

Call learners who had opened parallel requests to understand the missing feedback.

Trace the flow

Follow ticket creation, email receipt, status checking, resolution, CSAT, and reopening.

The redesign closed four feedback gaps

  1. Surface active requests on the Help page. Learners could see that a ticket existed without starting another submission.
  2. Set an ETA when the ticket is generated. The confirmation state explained when to expect a response and reduced uncertainty immediately.
  3. Make every receipt actionable. Contextual email content included the ticket number, current status, and a direct tracking path.
  4. Repair the resolved-ticket loop. Clear closed states and deliberate follow-up actions prevented replies from silently creating more work.

Three phases turned the redesign into measurable change

The team fixed system defects first, then changed resolved-ticket behavior and introduced the new status loop across LMS surfaces. Email and phone-origin tickets remained under monitoring rather than being folded into a single headline.

~70%
reduction in duplicate tickets overall
100%
reduction in duplicates caused by identified bugs
100%
reduction from targeted LMS sources

The 100% result is deliberately scoped to the LMS, LMS Chat, and mobile-help sources covered by the intervention—not every support channel.

Reflection

The most useful design move was changing the question from “How do we stop people submitting twice?” to “What information would make a second submission unnecessary?” Pairing operational data with interviews made that shift possible. In future measurement, I would instrument repeat-submission rates by entry point from the start so the effect could be compared across every channel.

Original project source

Ticket analysis, learner calls, current-state flow, final designs, and phased impact from the supplied Figma case study.

View in Figma ↗