Occasionally, our customers ask us to add a feature to our help desk software that allows multiple people to be assigned a help desk ticket. We always politely refuse.
It’s not because we’re stubborn or because we ignore user feedback. Quite the contrary, our development calendar is typically full of new features originally suggested by customers.
So why do we take such a firm stance here? Why does our software mandate that ONLY ONE PERSON be assigned a help desk ticket?
The answer is two-fold and is based partly on social psychology experiments and partly on our own workplace experience.
Let’s first talk about the science.
Three *Scientific* Reasons Why Help Desk Tickets Should be Assigned to Only One Person
There are three interrelated social phenomenon that support our stance that help desk tickets should be assigned to only one person.
Bystander effect refers to instances when the presence of others (i.e. a group of bystanders) lessens the possibility that any individual in the group offers assistance. Research into bystander effect was prompted by news reports on the attack of Kitty Genovese in 1964.Ms. Genovese was walking to the door of her NYC apartment when a man attacked her. News reports suggested that as many as 38 witnesses heard her cries but did nothing to help or call the authorities. These news reports prompted research by John Darley, Bibb Latané, and Judith Rodin who found scientific proof for bystander effect.In one experiment, Latane and Rodin found that 70 percent of people offered assistance when they were the ONLY person asked to help, but when multiple people were asked to help, only 40 percent offered assistance.
Bystander effect refers to instances when the presence of others (i.e. a group of bystanders) lessens the possibility that any individual in the group offers assistance. Research into bystander effect was prompted by news reports on the attack of Kitty Genovese in 1964.Ms. Genovese was walking to the door of her NYC apartment when a man attacked her. News reports suggested that as many as 38 witnesses heard her cries but did nothing to help or call the authorities. These news reports prompted research by John Darley, Bibb Latané, and Judith Rodin who found scientific proof for bystander effect.In one experiment, Latane and Rodin found that 70 percent of people offered assistance when they were the ONLY person asked to help, but when multiple people were asked to help, only 40 percent offered assistance.
- Possible explanations for bystander effect:
- ambiguity – people in group are unsure if their help is really needed.
- competency concerns – people in group are unsure if they have the best skills to help when compared to others in group.
- consequences – people in group are concerned about the risks associated with offering assistance poorly or inadequately.
- How it relates to help desk tickets – if you assign multiple people to a ticket, it can lead to ambiguity (who is supposed to do what?) and competency concerns (should I let the other assignees handle this task because they have more expertise?).
Diffusion of responsibility is a concept that evolved from bystander effect and is based on research that suggests a person is less likely to take responsibility for a task when others are present. Diffusion of responsibility typically occurs because an individual assumes that others are responsible for completing the task or have already completed it.
- Possible explanations for diffusion of responsibility:
- See all explanations under bystander effect, plus…
- anonymity – individuals do not feel individually accountable for the task when it is not assigned solely to them.
- How it relates to help desk tickets – if you assign a ticket to multiple people, each individual’s feeling of responsibility diminishes. They also feel that they won’t be held individually accountable for completing the ticket since blame and/or praise will be dispersed among the group.
Social loafing is a social phenomena where individuals working on a group task exert less effort than if they were working alone. The causes of social loafing are mostly tied to the feeling that an individual’s effort will not matter to the group and will not be noticed. Social loafing is one of the main reasons why group work is often counter-productive.
Social loafing was first discovered in 1913 by Max Ringelmann who conducted rope pulling experiments (tug-of-war contests), and found that individuals tended to exert less effort when pulling a rope as part of a group than did individuals pulling a rope alone. His results have been reproduced in more modern studies as well.
- Possible explanations for social loafing:
- Sucker effect – no one wants to be the “sucker” who puts in all the effort while others in the group slack off, so everyone waits to see how much effort the others will put forth.
- Contribution concerns – when there are multiple group members working on a project, individual group members may believe that they’re contribution is insignificant to the outcome.
- How it relates to help desk tickets – if a complicated and time consuming ticket is assigned to a group, the assignees may all wait to see who is going take charge thus delaying progress on the ticket. Similarly if the group is large enough, the assignees may all assume that they can loaf on the ticket because so many people are assigned to the ticket that it HAS to get done because SOME OTHER “SUCKER” will surely work hard on it.
Beyond these psychological factors, we also considered our own workplace experiences both as managers and as customers / end users.
The Manager Perspective
Based on our own workplace experience, several problems can arise when a manager or supervisor assigns a ticket to multiple technicians.
- No single point-of-contact – If you assign a ticket to multiple people, then who do you call when there’s a problem or you need a quick update?
- Hurt feelings – Sometimes employees are offended when managers suggest they are not solely capable of completing a tacking. Other times managers can hurt someone’s feelings if they assign a ticket to multiple people but then only communicate with a single point-of-contact. Those who work on the ticket but do not communicate with the manager end up feeling overlooked and often accuse the manager of playing favorites or indulging in office politics.
- No direct accountability – Will the assignees try to blame each other if the ticket is managed poorly? Will they jostle to claim credit if the ticket is solved wonderfully?
The End User / Customer Perspective
Customer’s also suffer when tickets are assigned to multiple people.
While in theory, they may like the idea of an army of people working to solve their problems, in actuality, the quality of service they receive is likely to suffer (due to the social psychological factors discussed above) if their ticket isn’t assigned to one person who’s held ultimately responsible.
Beyond the quality of service they receive, they’ll also experience similar frustrations as managers with regards to not knowing who their single point of contact is and who to hold accountable for solving their issue.
But what about team work and collaboration…?
There’s a misconception that assigning a ticket to one person prevents teamwork or collaboration. We believe in the power of team work and have built features into our software to enable collaboration.
For example, when a manager assigns a ticket, he can CC any topic area experts who might be able to help the ticket owner.
The help desk technician who is assigned can then use private comments on the ticket to request help from other help desk employees if needed.
Further, we have a built-in queue system that can automatically send notifications to subject matter experts when a ticket arrives.
Inherent in all of these features is that one person holds ultimate responsibility for the ticket and is empowered to reach out to topic area experts and request assistance as needed.
Wrap Up
Our inclination as a software development company is to add every feature our users request because we want them to be the happiest customers on earth. We want them to have every option and every customization possible to make their lives easier.
But we must draw the occasional line in the sand and take a stance, lest our software become spineless, unwieldy, and undifferentiated. I hope this blog post has been helpful in showing one example of how me make decisions about some features in our app.
If you enjoyed this blog, please check out our current topics here.