Of late, we’ve been having a lot of conversations with prospects about their call center. If you’re anything like them:
- You’re selling products to consumers
- Your deal-sizes are in the low hundreds of dollars
- You have a definite repeat-purchase expectation
- You know that the products you sell are not what wins customer hearts: it’s the service you provide that does
- You see that your customers have a number of vendors as choices, so “churn” is an important issue.
So you really want to know your customers, beginning with name, email ID, phone number and address, all the way to maybe where they go to dinner on a Saturday night. And you’ve probably invested a fair bit into systems that do various things. But, when one of your customers calls you, your agent responds with the generic “How can I help you?” – no “Thank you for calling, Ms. <whoever>” or “Hello, Mr. <whoever>”. So with all your systems in place, the one point that regularly come into contact with your customers is the one point that had no knowledge about them!
You’re probably thinking “Yes, I know all that, but how can I fix that?” Well, I could tell you that you should just buy Impel and all will be well, but I must admit that that’s a simplistic answer. I’ll get into some of the gory details of call pop-up here, in a two-part blog post. In Part 1 (this one), I’ll cover two critical issues: the “app” that the agent uses and the pop-up screen in it. In the second part (next week!), I’ll cover the intricacies of phone-system integration and the possibilities of outbound calling.
Bear with me – there’s a lot of interesting possibilities out there!
Like I said, you probably have multiple systems in place already. There’s definitely one that handles your sales, maybe one that handles inventory, possibly even one that tracks customer-reported issues. And, I’m sure, there are a number of Excel files floating around. The first thing you should do is to tie them all together in some way, so agents can access data from multiple systems seamlessly. This means at least the following things:
- Sign in once. Make sure agents need to sign in ONLY ONCE, to access all the systems they need access to. IMHO, this is critical: signing into – and being signed out of – multiple systems is a significant point of frustration, both for the agent and for the caller.
- Keep it all together. For agents to be able to handle the 80-to-120 calls a day, they need to spend as little time as possible LOOKING for data. The thing is, in most cases, the data they need is a fairly short list – name, email ID, phone number, address, recent conversations, recent transactions, maybe recent tickets. Make sure all that’s available on one single page, maybe as tabs or as a long, scrollable page.
- Give them buttons to push. Customers – not cuss-tomers! – mostly call to get issues resolved, hopefully to order new stuff. Give your agents ways to do the related things – add a new ticket, add a new order, etc. – all from that one single page, via buttons. If possible, make those functions pop up in separate in-browser “windows” that close when the agent is done with them. My own preference is to not use separate browser windows but use “virtual” windows within the browser, allowing the user to minimize them when not in use, but you may find the other model more effective.
- Keep it simple. You probably have anything from 5 to 25 “processes” that you’ve organized, triggered from the call center. That’s good, but I’ll bet all those processes can be combined into, say, half a dozen fields on screen and 4 buttons that agents would use. Keep the agent’s life simple – let the system do all the heavy lifting. For example, if the agent has to process a refund but needs someone’s approval, set a workflow rule that’ll let that someone know, so that the agent can key in the data and then forget about it.
Pop it up
If you have at least some limited integration in place, or if you just have one system (the “app”, as I will call it hereon) that agents will need, you can make that one screen pop up fairly quickly, with most PBX systems. Of course, if you’ve got one of those fancy Avaya or Siemens systems in place, you’re in for some serious money to integrate the phone line and the network connection, but that apart, you’ll still need ways to do two things in parallel:
Route the call to a specific agent. This is easy - that’s what the phone system does anyway.
Send a request to that agent’s desktop to show that specific page in your app. Now, this is where things get hairy. First of all, getting this done depends on what your agents use to for taking calls, meaning, do they use their desktop with VoIP or do they use regular phones?
With a VoIP-based call center, you will have software on the desktop, called the “VoIP client”, that fields the routed call and makes it possible for the agent to answer and talk. That software, in most cases, can be configured to not just field the call but also get a “URL” (i.e. the address of a page in your app or on the web) to open on the desktop. And that URL can include the caller’s phone number. So when the agent accepts the call, the VoIP client also makes sure that the caller’s record in your app is shown on screen. So your inbound-call pop-up works right away. The problem, though, is that each time a new call comes in, a new page pops up. So the agent needs to close the popped-up page every time s/he finishes a conversation – not the best of solutions.
There is an alternative to this mechanism. If you have a VoIP-based PBX (IP-PBX,as it is called), your agents probably log into it using a web page. Your PBX vendor will tell you that they can set up things such that a part of that web page shows the page from your app, with the details of the caller. That’s good – for some things. The multiple-page issue goes away. And the agent sees a consistent page (the PBX’s web page) all the time. The problem is, the way these pages are usually laid out, nearly a fourth of the page will be taken by the PBX’s “call controls” – buttons for Hang Up, Forward and so on. Packing customer-related information in the rest of the screen-space is a challenge. Also, depending on where the PBX is hosted, your app response may seem a lot slower than it really is, since it will be “i-framed” in the PBX’s page. So the agent is left really focusing on the call, not on the customer. Not a great alternative, but possibly the better one, under the circumstances.
Using a regular phone
If your call center uses regular phones without VoIP, possibly with Cloud-based phone systems like Knowlarity, you’ll need to roll out some additional tech. Two things need to happen here:
- When a call is routed to an agent, the phone system needs to tell your app about that agent and about the calling number.
- Your app now needs to automatically take the relevant agent to the page with the caller’s details.
Most phone systems worth their money can do do item 1 with a few hours of work (although, with the older or or more “eminent” ones, it’ll cost you a fair bit!). For item 2, there are a number of technologies out there. Impel, for example, uses something called Node.js to do this.
Disposition Delay for the next call
One under-appreciated problem with the pop-up mechanism is what I call the “Disposition Delay”. When an agent finishes talking to the caller, you’d expect him/her to be ready to take the next call. The problem is, in a number of cases (60%, we’ve seen), the customer would have hung up, but the agent will still be making notes about the call for a few minutes. So s/he can’t really take the call yet, although the phone system thinks s/he can (because his/her phone line is free). One way to solve this problem is to “hard-code” a delay in the phone system, such that ALL calls, once hung up, give the agent (say) five minutes to update your app. This actually is a BAD idea: it now uniformly slows your call center, since it adds 5 minutes in 40% of the cases where that’s NOT needed AND 5 minutes may be too much or too little in a number of the other cases. You really need a mechanism where, after the customer hangs up, the agent can somehow tell your phone system “OK, I’m done”. With the better phone systems, that’s certainly possible. For example, we have that kind of stuff worked out already with Asterisk, Knowlarity and Ozonetel.
There are a few other things to think through, but if you get these two major areas covered – the app and the pop-up – you’re pretty much set to get agents focusing on customers instead of on calls.
Next week, we’ll talk about some of the more interesting things you can do with a good PBX and how you can leverage all this for outbound contact, too.
Are there other big tech issues you’ve had to deal with in enabling a call center? Let me know!