University of Larkspur: A Portal Nobody Uses
University of Larkspur's central IT has 60 staff supporting 18,000 users. Six months ago it launched a self-service portal with 45 request types. Adoption is 27% of requests; 61% still arrive by email to a shared mailbox and 12% by phone. Agents copy email requests into the portal to keep the portal numbers up. Training was one 45-minute webinar at launch, with no refreshers. The service desk manager was excluded from the design team and tells staff the portal 'doesn't work'. The CIO sponsors the programme but has attended one steering meeting. A staff survey found 44% do not know which channel to use and 58% fear that logging a request will slow it down. The university wants 70% adoption in 12 months and fewer walk-ups to the service desk.
1. Diagnose the adoption failure. Which organizational change and stakeholder issues explain the gap, and why is more training unlikely to fix it?
Read the worked answer
The 27% adoption figure is itself unreliable because agents copy email requests into the portal. That inflates adoption while hiding the real channel mix. The underlying problem is not a single training gap; it is a change programme with weak sponsorship, no communication, and a design process that excluded the people who influence use.
The service desk manager is a high-influence stakeholder with a negative view, and their opinion shapes agent behaviour. Exclusion from design created ownership resistance: people resist a process they had no part in shaping, especially when it changes their work. The CIO sponsor is nominal; one steering meeting signals low priority, so middle managers do not commit.
Users face channel confusion (44% do not know where to go) and a fear of delay (58%). That fear is rational if the portal does not show status or if email gets faster informal help. The portal has 45 request types, which may be too many for users to navigate. Agents copying emails suggests the portal does not fit the real demand or the service desk is measured on portal volume rather than resolution.
More training addresses knowledge, but the barriers are motivation, trust, process fit, and social influence. Training without sponsor visibility, manager endorsement, simpler design, and a reason to change will not move adoption.
2. Design a 12-month adoption and capability plan with phases, milestones, roles, and measures. How would you handle the service desk manager's resistance and the copied-email practice?
Read the worked answer
Months 0–1: reset and baseline. Appoint a change lead and a service desk champion. Interview users and agents; measure real channel mix by removing the copy-to-portal practice from the adoption metric. Confirm the CIO's role: a monthly steering meeting, a visible message, and a named business sponsor in each faculty. Set the target as 70% of eligible standard requests through the portal, not 70% of all contacts.
Months 1–3: simplify and co-design. Reduce 45 request types to the top 12 plus a clear 'something else' route. Put the service desk manager on the design group and give them a defined role in decisions. Fix status visibility and confirmation messages. Agree that agents may assist users to log requests, but assisted logging is tagged separately and not counted as self-service adoption.
Months 3–6: communicate and enable. Run role-based briefings, faculty drop-ins, and short videos. Publish 'what changes, why, and what to do'. Train agents as advisers who can demonstrate the portal. Start a champion network. Milestone: 40% adoption and improved channel awareness.
Months 6–9: embed and reinforce. Move standard requests to the portal as the default, with email auto-response guiding users to the portal but not blocking urgent contact. Recognize teams that improve. Milestone: 55% adoption, reduced email share, stable CSAT.
Months 9–12: optimize and sustain. Review demand, retire low-value request types, and publish results. Milestone: 70% adoption, fewer walk-ups, and no decline in resolution time.
Handle resistance directly: give the service desk manager co-ownership, listen to specific concerns, and fix what is genuinely broken. Stop counting copied emails as adoption; to do otherwise is a data-quality problem. Replace volume targets with adoption plus outcome measures.
3. What competencies do service desk agents need in this model, and how should the university develop and measure them?
Read the worked answer
Agents move from taking requests to guiding users through a digital service. Competencies include: digital navigation of the portal and catalog; request triage and classification, including knowing when a request is an incident; knowledge management, so answers are reused and accurate; customer advisory skills, including explaining channel choice and setting expectations; data quality, so tickets are not duplicated or mislogged; service mindset, focused on the user's outcome rather than ticket volume; and resilience and adaptability during the transition.
Develop these through a structured pathway, not a single webinar. Start with role-based training on the top 12 request types. Add sandbox practice and peer coaching. Create certification gates for independent handling. Give team leaders coaching questions and observation checklists. Use short refreshers after launch and when the portal changes. Recognize good advisory behaviour publicly.
Measure capability with: time to independent handling, first-time-right, reopen rate, portal-assisted resolution quality, knowledge article contribution and accuracy, and user feedback on agent help. Track confidence with a short pulse survey before and after training. Do not measure success by portal clicks per agent; that encourages forced logging.
For copied emails, distinguish legitimate assisted logging from metric manipulation. Allow assisted logging with a tag, audit a sample, and explain why honest channel data helps fix the portal. If agents copy emails to protect a target, remove the target. Address the manager's resistance through co-design and evidence, not discipline. The goal is a service desk that helps users choose the right channel and resolves the request, not one that defends a channel.