{"id":3731,"date":"2016-03-28t09:30:03","date_gmt":"2016-03-28t09:30:03","guid":{"rendered":"\/\/www.catharsisit.com\/?p=3731"},"modified":"2016-03-28t09:30:03","modified_gmt":"2016-03-28t09:30:03","slug":"the-uber-of-customer-support","status":"publish","type":"post","link":"\/\/www.catharsisit.com\/blog\/the-uber-of-customer-support\/","title":{"rendered":"the uber of customer support"},"content":{"rendered":"
imagine you have plenty of smart, well-trained customer support agents to keep your ticket queues low and your reply times fast, but you have no control over when they work. you know they will work a certain amount of time each week, but you have no idea when that will be.<\/p>\n
how do you handle this ambiguity and lack of control? as a manager, how do you keep yourself from jumping in and answering tickets when more and more tickets flow into the queue?<\/p>\n
at magoosh, we face this challenge \u2014 all the people and no control over when they work \u2014 but with any good challenge, a creative solution is waiting to be unearthed. instead of looking for a solution among other customer support teams, we adapted an idea popularized by uber and lyft: surge pricing!<\/p>\n
over the past year, we experimented with increasing pay when we were inundated with questions as a way to nudge our test prep experts to jump in and answer questions. i\u2019d like to share the results of this experiment with you. i hope you can learn from our experience. maybe it will inspire you to try something similar with your teams.<\/p>\n
\u201cwait, kevin, why don\u2019t you have control over when your agents work?\u201d you might ask. \u201ccan\u2019t you easily avoid this challenge?\u201d<\/p>\n
yes, we could avoid this scenario. we could hire a full-time staff, or even a larger part-time staff, and schedule their time to handle ticket levels. but that\u2019s not how we\u2019ve approached support at magoosh up to this point.<\/p>\n
we hire teachers and tutors with expertise across multiple tests as independent contractors. our \u201ccustomer support agents\u201d work independently to answer questions about exams: from coordinate geometry on the gre, to critical reasoning on the gmat, to dual reading passages on the sat, to speaking strategies on the toefl. the people with this type of expertise tend to be phd students, classroom teachers, private tutors, or recent graduates, all of whom have fluctuating and dynamic schedules.<\/p>\n
as independent contractors, they set their own schedules, finding time to answer questions in between their other commitments. this flexibility is great for them. they don\u2019t have to tell us when they will work or notify us of changes \u2014 they just work when they can.<\/p>\n
this is great for us too. we don\u2019t have to keep a schedule or approve schedule changes. no one has to worry about shifts or coverage in the traditional sense. all our hires are experts and already know how to teach. we can hire the best people from across the country. <\/p>\n
but it\u2019s not all sugar plums and gumdrops. we\u2019ve traded control for uncertainty, and as such, we\u2019re left to experiment and find solutions to certain challenges \u2014 will all the questions get answered today?<\/p>\n
surge pricing works for companies like uber and lyft, so we wanted to find out if we could make it work in customer support.<\/p>\n
the process was straightforward enough: email everyone on the team at the beginning of the day and tell them that they\u2019ll be paid 25% more for any work they do during a specific time period.<\/p>\n
when we see that our demand (tickets) is rising and our supply (people who can answer questions) is decreasing, we’d send out an email to the team. a situation similar to this contrived example.<\/p>\n
<\/p>\n
if surge pay worked, we\u2019d see this happen:<\/p>\n
<\/p>\n
our supply rushes to meet demand and our students begin to receive answers to their questions. demand begins to drop off as our tutors answer questions, and the incentive of surge pay is no longer needed.<\/p>\n
when we \u201cturned on\u201d surge pay, we sent an email to our team, letting them know that surge pay is in effect for a certain amount of time, usually the rest of the day.<\/p>\n
here\u2019s an example of an email sent to the team:<\/p>\n
<\/p>\n
since june 2015, we\u2019ve had surge pay 26 times. each of these surge pay experiments was different, but not by design. sometimes they were for a full day, sometimes they were across multiple days, and sometimes they would only last an afternoon.<\/p>\n
this variation was not for pure experimental purposes. due to consistent high demand across multiple days, we\u2019d have surge pay across multiple days. or sometimes we waited to see what the morning would be like, to see if people would jump in and answer questions, and then later, send out the surge pay email. other times we\u2019d check the queue in the morning and know that we needed to flip the switch.<\/p>\n
the graphs below show nearly all the surge pay days in 2015. each vertical line represents the day before surge pay. i\u2019ve decided to mark these days because it gives a better picture of what we were looking at when we decided to start surge pay. to understand the results of surge pay, we need to look at what happened the day after the line.<\/p>\n
let\u2019s look at some of these days to evaluate the success of surge pay. on 6\/23\/2015, we had roughly 280 tickets created \u2014 our demand \u2014 but only around 200 tickets updated \u2014 our supply. on 6\/24\/2015, i emailed the team to begin surge pay, and by the end of the day, supply surged to around 300 tickets. in this case, we can tentatively say that surge pay worked. the steep increase in tickets updated from 6\/23 to 6\/24 would indicated that we were able to encourage people to jump in and answer questions.<\/p>\n
now let\u2019s look at another day. on 6\/25\/2015, demand was only slightly above our supply. on 6\/26, i sent out the email to start surge pay, and both supply and demand dropped off with supply never overtaking demand. surge pay didn\u2019t seem to change anything this time.<\/p>\n
<\/p>\n
in august we saw more mixed results. for the first time, we had back-to-back surge pay days. if we look at 8\/10 – 8\/12, we see a big spike at the beginning, but then a drop off in our supply and demand. ticket updates dropped below new tickets created. this might indicate that surge pay is only effective in short bursts. perhaps after the third day of surge pay, the team was less motivated to jump in.<\/p>\n
<\/p>\n
this brings up some points that we need to consider when looking at the results of surge pay. we can\u2019t conclusively say that surge pay worked or not. at this stage, we can only have hunches and draw tentative conclusions because there is already so much variation in how much people work. there\u2019s no way to know if surge pay influenced people to work or if those people already planned to work. take, for example, the steep increases in ticket updates on days without surge pay (6\/15, 6\/21, 6\/27, 8\/30, 9\/8, 9\/24, 9\/26, and 9\/27). when we look at a surge pay day, it\u2019s hard to know for sure if this increase is similar to one of these days or due to an increase in pay. finally, we are implementing surge pay on days where demand is high. supply might naturally surge during these periods without us doing anything. ideally, we would a\/b test surge pay and no surge pay at the same time, but that\u2019s not fair to our test prep experts nor our students waiting for answers.<\/p>\n
september offers us mixed results with surge pay. let\u2019s look at the dates 9\/9 – 9\/13. on 9\/9 there was definitely a gap in supply and demand before we sent out the email about surge pay. by the next day, supply overtook demand as we would expect. <\/p>\n
<\/p>\n
over the next 3 days, both supply and demand fell, but supply stayed above demand, until 9\/12 when supply dropped below demand again. it\u2019s unclear why this happened. maybe the effects of surge pay are not effective over a long period of time. but if we look at the last day of surge pay (9\/13) we see a spike in both supply and demand. during this time, supply does overtake demand. <\/p>\n
what\u2019s interesting is that we see a similar pattern when we look at the string of surge pays days later on from 9\/17 – 9\/20. supply overtakes demand, both drop off in the coming days, supply drops below demand towards the end, and on the final day, it surges. this is a fascinating pattern and we don\u2019t have a good explanation to explain it. <\/p>\n
at this point, we are not ready to draw any strong conclusions about surge pay. as you can see from the results, there are a lot of variables. the natural fluctuations in people working and ticket numbers makes it hard to draw clear correlations with surge pay.<\/p>\n
even so, the preliminary results are positive enough for us to keep trying it. from the perspective of handling a backlog of tickets, surge pay has helped. it does bring down ticket numbers on days of high tickets. we are also expanding our definition of surge pay. it doesn\u2019t have to be based on a percent increase in pay. we are now experimenting with rewards around number of tickets answered in a week, number of hours worked in a week, and first to answer 10 questions.<\/p>\n
1 – photo of uber app courtesy of gongto<\/a> \/ shutterstock.com<\/a>. we experimented with a surge pricing idea popularized by uber and lyft to nudge our test prep experts to jump in and answer questions. here are the results of our experience.<\/p>\n","protected":false},"author":12,"featured_media":3732,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[442,443,288,36,444,445],"ppma_author":[497],"class_list":["post-3731","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-team-news","tag-customer-support","tag-lyft","tag-questions","tag-students","tag-surge-pay","tag-uber"],"acf":[],"yoast_head":"\n
\n<\/i><\/h6>\n","protected":false},"excerpt":{"rendered":"