In many cases, technical solutions alone will not get the job done. A good example from my past experience was a case where are sales agents were not able to answer even half of incoming advertising calls during peak season. This was the case at SelectQuote when I took over the call center programming.
I've covered an interesting part of my technical implementation elsewhere, but this project would not have succeeded on technical merits alone. This serves as a good example of why a good programmer needs to be able to talk to the other areas of the organization in their language, and make suggestions, not just fill requests.
It appeared many agents were sort of cherry picking the calls during high volume. Now this could easily be come a volatile situation, if looked at only from a technical perspective. After all, agents are the ones making money for the organization.
Also, agents are paid on commission, so there is normally a reason they are doing things a certain way. If agents were not answering or spending less time on certain calls, it was a good indication that there was a need to filter calls during a spike. Once this idea is accepted, it can be done in a much more rigorous manner.
So it needs to be understood why the agents can't get to all the calls. There should be some investigation to find out if some of these calls are really not worth an agent's time when the volume is too high. Also thought needs to go into what to do with excess calls. If buying the advertising really is worthwhile, and the problem is a matter of timing. Then the solution needs to include a way to get back to people who couldn't be served during the spike.
The organization didn't want to get a reputation for serving some areas and not others. It was necessary to point out that, chances are, any one person calling SelectQuote back then would not get an agent. We were basically ticking off more than half the people who called in. By emphasizing that a solution is going to improve things for the average caller, and not just predicted high value callers, I was able to frame things in a way that got less resistance.
So it is key for a programmer in this sort of situation, get buy-in from non-technical users. People representing the sales floor, and the people doing reporting and data analysis. That way others have input into how these calls are going to be handled, and what data is used to decide which calls should be overflowed first. Someone outside of engineering is going to have better insight into the data needed for lead scoring anyway.
Sales, accounting, and marketing do not all speak the language of the programmer. So it is very important for the programmer to speak to them on their terms. Solutions to the big problems cannot be solved in any one silo. So to truly affect great change within an organization, there needs to be people within software development that can speak to the other silos.
Many programmers would rather sit back and handle requests from other parts of the organization, but this is tantamount to saying everyone except programmers are capable of vision that can give a company a strategic edge. This is not the attitude of someone at the top of his game, but rather just a cog in the machine cashing his paycheck.
I've covered an interesting part of my technical implementation elsewhere, but this project would not have succeeded on technical merits alone. This serves as a good example of why a good programmer needs to be able to talk to the other areas of the organization in their language, and make suggestions, not just fill requests.
It appeared many agents were sort of cherry picking the calls during high volume. Now this could easily be come a volatile situation, if looked at only from a technical perspective. After all, agents are the ones making money for the organization.
Also, agents are paid on commission, so there is normally a reason they are doing things a certain way. If agents were not answering or spending less time on certain calls, it was a good indication that there was a need to filter calls during a spike. Once this idea is accepted, it can be done in a much more rigorous manner.
So it needs to be understood why the agents can't get to all the calls. There should be some investigation to find out if some of these calls are really not worth an agent's time when the volume is too high. Also thought needs to go into what to do with excess calls. If buying the advertising really is worthwhile, and the problem is a matter of timing. Then the solution needs to include a way to get back to people who couldn't be served during the spike.
The organization didn't want to get a reputation for serving some areas and not others. It was necessary to point out that, chances are, any one person calling SelectQuote back then would not get an agent. We were basically ticking off more than half the people who called in. By emphasizing that a solution is going to improve things for the average caller, and not just predicted high value callers, I was able to frame things in a way that got less resistance.
So it is key for a programmer in this sort of situation, get buy-in from non-technical users. People representing the sales floor, and the people doing reporting and data analysis. That way others have input into how these calls are going to be handled, and what data is used to decide which calls should be overflowed first. Someone outside of engineering is going to have better insight into the data needed for lead scoring anyway.
Sales, accounting, and marketing do not all speak the language of the programmer. So it is very important for the programmer to speak to them on their terms. Solutions to the big problems cannot be solved in any one silo. So to truly affect great change within an organization, there needs to be people within software development that can speak to the other silos.
Many programmers would rather sit back and handle requests from other parts of the organization, but this is tantamount to saying everyone except programmers are capable of vision that can give a company a strategic edge. This is not the attitude of someone at the top of his game, but rather just a cog in the machine cashing his paycheck.
Post a Comment