Application and Process Hotspots: Tickets Made by Design

The first Tuesday of September, 08:15, at Larkfield College. Grace runs the four-person desk for a further-education college. The queue already holds thirty-one tickets about the student records system. They say "can't find the student I just enrolled", "enrolment form won't save", "need access to the enrolment screen, starting today", "system slow". By Friday there will be a hundred and forty. The desk calls this enrolment week, braces for it every year, and cancels leave for it. The desk has never once written down how many tickets enrolment week produces, because everyone knows: it produces a lot, and then it stops. Kwame, in his first September, asks the question new people ask. "Is it always like this?" It is. It has been like this for six Septembers. Nobody has ever treated that as information.

An application hotspot is a piece of software that produces tickets out of proportion to how many people use it. A process hotspot is a business routine, such as onboarding, expenses, month-end or enrolment, that produces a burst of tickets every time it runs. The burst has the same shape and comes at the same point in the routine's cycle. The two are treated together because they share a feature the device hotspots in the previous article do not. The fix is almost never a purchase. It is almost always a conversation with someone outside IT who owns the application or the process and has never seen the count. This article is part of our Hotspot Analysis series, and it is about that count and that conversation.

It covers why the two kinds are one conversation, then the application that makes tickets by design and the application that makes tickets by fault. Next come the calendar cut that finds a process hotspot, and the three classic process hotspots. The owner conversation and the fixes that belong to the desk anyway follow. The article ends with a short war story and the process hotspot sheet to copy, in that order.

Two Kinds, One Conversation

Applications and processes are owned by people who are not on the help desk, and that fact decides everything about how their hotspots get fixed. The expenses system belongs to finance; the student records system belongs to the registrar. The onboarding routine belongs to HR, with contributions from facilities, the line manager and the desk. The desk sees every ticket the thing produces and owns none of the decisions that would stop them. The owner makes the decisions and sees none of the tickets, because the tickets go to the desk. A hotspot can run for years in that gap, with the desk resenting the application and the owner believing it works fine. Both are right about what they can see.

The desk's job, therefore, is to carry the count across the gap. Do not carry the complaints, which the owner has heard and discounted, or a request for a new system, which the owner cannot grant. Carry the count, in tickets and hours, per run of the process or per month of the application's life. Include the three commonest symptoms and what each costs. That is the whole of the method. The rest of this article is about getting the count right and delivering it in a way an owner can act on. The device hotspots were about evidence for a purchase. These are about evidence for a decision, and decisions are cheaper than purchases and harder to get.

The Application That Makes Tickets by Design

Some applications produce tickets because they were built to. Every access request routes through IT because the permissions model needs an administrator for each change. Every new report needs a technician to grant a role. Every locked account needs a reset the user cannot do. The error screen says "contact your IT department" for conditions the user could resolve alone if told how. None of these is a fault. Each is a design choice made by a vendor or a project team, often sensibly for an organisation three times the size. Each produces a steady stream of tickets that are quick, identical and endless. Quick and identical is how they escape notice; endless is what they cost.

The question that reveals a by-design hotspot is "should this be a ticket at all?" It is asked of each ticket type the application generates, not of the application as a whole. At Larkfield, the records system produced four kinds of ticket in enrolment week. Access requests for the enrolment screen were a design choice (roles had to be granted one at a time). "Can't find the student" was training (the search needed the student number, not the name, for a new record). "Form won't save" was a fault (a timeout under load). "System slow" was capacity. One application, four ticket types, four different fixes, and only one of them was anything a technician could do. The desk had been doing all four as tickets for six Septembers.

The by-design tickets are the largest share on most desks and the least examined, because each one is five minutes and nobody reviews five-minute tickets. Count them anyway. Forty access requests a month at ten minutes each is nearly seven hours a month, which is a working day, every month. That time is spent granting a role that could have been part of the new starter's standard set. The count turns "it's just access requests" into "we spend a day a month on access requests for this application". The second sentence is one an owner can do something about. The first is weather.

The Application That Makes Tickets by Fault

The other application hotspot is the one with a defect, a capacity problem or an integration that drops records. It shows in the tickets as a cluster of symptoms with error messages in them, rising over time or spiking under load. This is where hotspot analysis hands over to problem management, because a fault that repeats is a problem. The chase for the vendor's fix is the business of Getting the Permanent Fix Done. The hotspot hunt's contribution is to have noticed that the application is producing tickets at three times the rate of its peers. That way, the fault is treated as a source worth a problem record rather than as a run of unlucky tickets.

Separate the fault tickets from the design tickets on the same application before anyone acts. The two have different owners, and a mixed count persuades neither. Larkfield's "form won't save" was a fault, and fixing it was a conversation with the vendor about a timeout under load. The access requests were a design choice, and fixing them was a conversation with the registrar about a standard role. Both were presented as "a hundred and forty tickets about the records system". That made the vendor say the access requests were not their problem and the registrar say the timeouts were not hers. Both were right. Presented as two counts, each went to its owner, and each owner had nowhere to point.

Finding the Process Hotspot: The Calendar Cut

A process hotspot does not live in a column, because a process is a pattern in time. It is found by adding time to the cuts from Finding Hotspots in the Ticket Data. Add two columns to the export: the day of the month each ticket was opened, and the working day of the month. The latter is the count of working days from the first of the month to that day. So the first Monday is working day one whether it falls on the first or the third. Pivot the tickets by working day of month, across all the months in the export, and read the result as a profile. A desk with no process hotspot shows a flat profile with a bump on Mondays. A desk with one shows a hill on the same working days every month.

Then cross the hill with the application and group cuts to name it. Larkfield's profile had its hill in the first four working days of September. Crossing those days with the application column named the records system. Crossing with the department column named the admissions team and the curriculum staff doing the enrolling. The same method on the monthly profile showed a smaller hill on the last two working days of each month and the first of the next. It crossed to the finance system and the budget holders: month-end. A third, almost invisible from the queue, was every Monday after a timetable change, crossing to the timetabling system and the teaching staff. It meant six to ten tickets, every time, for years. Three processes, three hills, three owners, found in one afternoon from one export.

Measure a process hotspot per run rather than per month, because that is the unit the owner thinks in. Enrolment produced about a hundred and forty tickets per run, once a year. Month-end produced twenty to thirty per run, twelve times a year. The timetable change produced six to ten per run, perhaps thirty times a year. Per year, the three were roughly comparable, which surprised the desk, which had experienced enrolment as a crisis and the timetable tickets as nothing. The small process that runs often is the one the desk never sees as a hotspot and the owner never hears about. It is also, usually, the easiest to fix. A fix that saves eight tickets a time is a small ask of an owner who makes the change thirty times a year.

The Three Classic Process Hotspots

Onboarding produces tickets because the new starter arrives before the things they need do. The tickets are the gap made visible: "account not working", "no laptop", "can't get into the shared drive", "needs access to the system". They are raised on day one by the manager, by the starter, and by whoever is sitting next to them. The cause is almost never the desk. It is a process with no lead time. The desk hears about the starter on the Friday before the Monday, or hears from three different people with three different lists. The fix is a single onboarding request raised by HR with a fixed lead time and a fixed set of fields. That way, the account, the kit and the access are one job done on time rather than five tickets done late. The form design for that is the business of A Request Form People Will Finish. That request is the single most common process fix a desk ever makes.

Expenses produce tickets at the deadline, because that is when everyone uses the system at once and discovers what they forgot since last month. That includes how to attach a receipt, why the upload fails for a photo over a certain size, and who their approver is. It includes why the approver cannot see the claim. Half the tickets are "how do I", a quarter are access, and the rest are the system under load. The owner is finance, and the fixes are theirs to make. They include a one-page guide linked from the expenses screen, and a deadline that is not the same day as payroll's. They include an approver mapping that is maintained when people move, and a quiet word with the vendor about the upload limit. The desk's part is the count per run and the top three symptoms. The rest is a finance decision wearing an IT costume.

Month-end produces tickets because the finance team, and anyone who feeds it, does a month's worth of reporting in two days. Everything needs to work at once: the finance system, the reporting tool, the shared drive where the spreadsheets live, the printer that does the board pack. Tickets at month-end are urgent in a way tickets on the ninth are not, and a desk that treats them as ordinary will meet the finance director. The fix is partly capacity (no changes to the finance system in the last three working days, a technician free on those days). It is partly design (a report that runs itself, a role that includes what the role needs). The owner is the finance manager, and the conversation is usually the easiest of the three, because finance managers understand a count.

The Owner Conversation

The conversation has one purpose: show the owner a count they have never seen and ask for one change. It should take twenty minutes. Open with the count, not the complaint: "Every enrolment week the desk handles about a hundred and forty tickets about the records system. That is roughly fifty hours of our time and a lot more of your team's. Seventy of the tickets are requests for the enrolment role, one at a time." Then the ask, which is one thing, specific and small enough to say yes to: "Could the enrolment role be part of the standard set for admissions and curriculum staff from August, so those seventy do not happen?" Then the offer, because an owner who hears a problem and a request will look for the catch: "We will count again next September and send you the result either way." That is the entire meeting. Bring the sheet and leave it with them.

Owners resist for three reasons, and each has an answer that is not an argument. "It works fine" means the owner has never seen a count, and the answer is the count, per run, with three example tickets attached. "That's an IT problem" means the ticket type looks technical from where they sit. The answer is to show which tickets are faults, which the desk is already chasing. Show which are design, which only the owner can change. "We can't change the system" is usually true of the software and untrue of the process around it. The answer is to ask for the process change instead: a standard role, a lead time, a guide, a different deadline. The desk is not asking anyone to be wrong. It is asking for one setting.

Two things go wrong in this conversation, and both are the desk's fault. The first is fixing the process from the desk alone, with a knowledge base article and a canned response and a heroic September. That works, is invisible to the owner, and guarantees the hotspot survives. The owner's view of the process is now that it runs smoothly. The second is blaming the owner's team, in the meeting or in the ticket notes, for not reading the guide. That ends the conversation and teaches the owner that the desk is a complaints department. The count is neutral. Keep the conversation on the count and off the people, and the people will usually help, because they are the ones raising the tickets.

The Fixes That Belong to the Desk Anyway

While the owner decides, and sometimes instead of the owner deciding, there are fixes the desk can make alone. They are worth making because a hotspot the desk has halved is easier to get removed than one it is merely complaining about. A knowledge base article for the top symptom, published and linked from the auto-reply a week before the run, takes an afternoon and typically removes the "how do I" share. A message to the people who run the process, sent before the run rather than after the tickets, is the pre-emptive move described in Telling Users Before They Notice. For a known hill in the calendar, that message is the cheapest fix there is. A request form for the process, with the fields the process needs marked required, turns five tickets into one. If you run QuerySolv, a department with its own form and fields is the natural home for the onboarding request. That way, the starter's name, start date, manager and role arrive filled in rather than in a chain of replies.

Staffing is a fix too, and the least glamorous. A process hotspot with a known calendar can be met with a technician kept free on those days. Leave can be kept off those days, and the week's other work moved. That way, the burst is handled at ordinary speed rather than at crisis speed. This removes no tickets and it removes most of the pain. That buys the desk the standing to have the owner conversation calmly instead of in the middle of the burst. Larkfield's desk had done this for six Septembers and thought of it as the fix. It was the splint.

Scripted fixes and self-service have a place for the by-design tickets that the owner will not remove. They include a self-service reset for an application with its own accounts, and a one-click role grant that an approver can trigger. They include a form that creates the access ticket pre-approved. These are investments, and they belong in the source-fix plan the next article describes, with the hours counted on both sides. The rule is that they come after the owner conversation, not instead of it. An automated version of a ticket that should not exist is still a ticket that should not exist, running faster.

A Short War Story: The Rota Application at Oakhurst Care Homes

Oakhurst Care Homes ran eleven homes and a desk of two. For as long as anyone on the desk could remember, Monday mornings brought twenty to thirty tickets saying "can't see my shifts". They came from carers across all eleven homes. Each was resolved in about ten minutes by re-adding the carer to their home's team in the rota application. The desk lead, Femi, had a canned response, a knowledge base article for home managers, and a standing joke about Mondays. The desk resolved around nine hundred of these tickets a year, roughly a hundred and fifty hours, with a first-contact resolution rate it was quietly proud of. A new operations director, Hilde, asked in her second month why the rota system was the top application in the desk's quarterly report. Femi explained the Monday ritual. Hilde asked whether the application had to drop people from teams when a rota was republished. Nobody knew, because nobody had ever asked the application's owner. That was the previous operations director, who had never seen the count. The setting was in the vendor's own documentation. It took the vendor's support line twenty minutes to change. The Monday tickets stopped the following week. Nine hundred tickets a year had been generated by design, resolved with pride, and removed by one question from someone who read the report. A ticket made by design is removed by a decision, and the decision belongs to whoever has never seen the count.

The Process Hotspot Sheet

The sheet below is one page per process or application. It is written to be left on the owner's desk at the end of the conversation. Section A names the process and its owner and describes the cycle. An owner who sees "the first four working days of September" written down understands the shape immediately. Section B is the count per run, split by ticket type and marked fault or design. That is the part that stops the owner and the vendor from pointing at each other. Section C is the one change requested and how the desk will measure it. Section D is what the desk will do regardless, so that the owner sees the desk is carrying its share. Fill in the hours as ranges, and never a currency figure.

PROCESS HOTSPOT SHEET — ONE PROCESS OR APPLICATION, ONE PAGE
Process or application: ______________________________   Sheet ID: ________
Prepared by: ______________   Date: ____________   Period counted: ____________

A. THE CYCLE AND THE OWNER
   Business owner (name, role): __________________________________________
   Runs:  [ ] daily  [ ] weekly  [ ] monthly  [ ] yearly  [ ] on an event: ______________
   When in the cycle the tickets land (working days, weekday, hour): _______________
   Who raises them (group or role): ______________________   How many people: ______

B. THE COUNT PER RUN
   Runs in the period: ______   Tickets in the period: ______   Tickets per run: ______
   Hands-on time per ticket (sample of ten): ______ to ______ minutes
   Desk hours per run: ______ to ______      Desk hours per year: ______ to ______
   Ticket types, largest first:
     1. ______________________________  ______ per run   [ ] fault  [ ] design  [ ] training
     2. ______________________________  ______ per run   [ ] fault  [ ] design  [ ] training
     3. ______________________________  ______ per run   [ ] fault  [ ] design  [ ] training
     4. ______________________________  ______ per run   [ ] fault  [ ] design  [ ] training
   Three example tickets attached: ______ / ______ / ______

C. THE ONE CHANGE REQUESTED
   Change: _________________________________________________________________
   Ticket types it would remove (from B): ______________________
   Expected tickets per run after the change: ______
   Decided by: ______________   Asked on: ____________   Answer: ______________________
   Measured at the next run on: ____________   Result: ______ tickets

D. WHAT THE DESK WILL DO REGARDLESS
   [ ] Article for ticket type ______ published and linked from the auto-reply by: ________
   [ ] Pre-run message to the people who run the process, sent ______ days before each run
   [ ] Request form with required fields for this process, live by: ________
   [ ] Technician kept free on the run days: ______________________
   [ ] Fault tickets (type ______) handed to problem management as: ______________

Status: [ ] counted  [ ] owner conversation held  [ ] change agreed  [ ] measured, cooled  [ ] measured, still hot

Grace took the sheet to the registrar on the second Thursday of September. The hundred and forty tickets were split four ways, and the seventy role requests were circled. Grace asked for the enrolment role to be standard for admissions and curriculum staff from August. The registrar had been told for six years that enrolment week was "a nightmare for IT" and had never been told why. The registrar agreed in the meeting. The following September the desk handled fifty-eight records-system tickets in enrolment week, most of them "form won't save". That was the vendor's, and it was the next sheet. Kwame, in his second September, asked whether it was always like this. Grace said it used to be worse, and showed him the count.

Frequently Asked Questions