Showing posts with label Technical. Show all posts
Showing posts with label Technical. Show all posts

Wednesday, 9 July 2014

IVR Worst practices to avoid - best practices to adopt


IVR stands for Interactive Voice Response systems – the automated voice options you often hear when you call large organisations. Call Centre Helper is a very useful British industry newsletter. It recently posted an article on what NOT to do with IVR based on advice from a galaxy of industry experts. To turn this around, let’s consider what is the right thing to do if you are considering an IVR component to your customer service delivery...

The first lesson is that what works for one company or purpose won’t necessarily work for you, so your first question must be why do I want an Interactive Voice Response system? Often the scale of the client’s operations is the determinant. Here are some common purposes we encounter at Well Done:
  1. Urgency - The simplest purpose clients want an IVR for is to choke off non-urgent enquiries after hours. Is this an emergency? Hell, yes, many will decide - and proceed to talk to our agents anyway, but the question will deter some and you can still provide good customer service to those who proceed … An IVR like this could also send your callers to different skills based queues on our systems – one for simple enquiries, and another for complex enquiries requiring escalation.
  2. Function – some clients direct particular calls to a contractor so they don’t have to handle them; some want to be able to direct enquiries to different trained staff. Some clients sift the easier work and send this to us so that their experts can handle the more complex enquiries. Some clients send calls to different answer-points on our systems based on IVR responses on their systems (e.g. entering their postcode, or selecting an issue). With an IVR you can have one national number but still control your call routing.
  3. Cost – sometimes the simplest questions can be answered perfectly well with an IVR response at a minimal cost. Bill paying by credit card is often handled this way by larger organisations.
  4. Service – you may be able to provide better service through streamlining enquiries; wait times for high volume queues requiring simple assistance can be dramatically reduced through IVR streaming of calls. People will be more prepared to wait to discuss a complex matter with an expert, or be happy to leave a voice message for a call back from this team rather than wait.
Secondly, the IVR experience should add value for your callers, so it’s worth considering the customer’s experience first, and then review the performance to check that everything is still working as it should down the track.

Bearing in mind that most smaller organisations won’t want more than 1-2 options for an IVR and that it’s really only large organisations with high call volumes that will push the limits, we ask:

What’s annoying and not useful for your customers?
  • Long waits coupled with the same On Hold message; if the wait is longer, some apology or reassurance doesn’t hurt.
  • Overly long descriptions of options, too many options; IVRs should siphon off the main reasons people call to streamline and improve the customer experience;  2 -5 options is really as much as I’m prepared to negotiate, with the most important ones first!
  • If you ask me to enter my phone number or account details via keypad, use them. I expect that you will have these in hand when I speak with you, particularly if you are a very large company, yet this often doesn’t happen…
  • Odd multiple voices, dull voices, machines that tell me to have a good day … Make sure your voice artist can be contacted to update options; it’s annoying to get multiple voices on the one line (it’s one conversation as far as I am concerned). Choose a voice that matches my idea of what your company stands for, and preferably one that sounds helpful and clear, not dull and officious. Keep your language simple and oriented to my needs. Keep the greetings and pleasantries to an acceptable minimum – I know that I am interacting with a computer, not a person.
  • Not rewarding the time I spent calling you… Don’t send your customer back where they came from; make sure you provide more service or information. If the option selected is to hear specific information then don’t provide more than one level of IVR options beyond this; for example, at this point I might appreciate the option of speaking to a person. If you’re closed, tell me first up, not after I have gone through the IVR maze. (This can be done through the time context of your IVR messages.)
  • Giving me no option to interrupt an instruction or speak to a person – afterall, I called you for help! There was conflicting advice from the experts on this one. It’s true that many will opt to speak to a human being and perhaps defeat some of the efficiency of having an IVR, but looping people through options that aren’t helping is a sure way to antagonise. 
  • Asking me to do something I can’t understand on the keypad.  For example, most people don’t know how to enter ALPHA information into an IVR (you need the * key entered to do this); if you have a complex interactive IVR database behind your system, try to configure it so that all keypad responses can be numerals only. Keep it simple – lots may be going on back at the home-front to distract me!
At Well Done we can code simple IVR options within our system. Often these are announcements that have a time context once your call enters our system. Complex sequences may require database application development, or your 1300 number provider may be able to code your IVR routing so that calls of different kinds can be pointed to particular diversion-points on our system. We can discuss the handling of those calls that you decide to route to us. It’s wise not to consider IVR options in isolation. They are but one channel in your communications with customers, and it’s best to consider the total customer experience when planning your service.

Friday, 26 April 2013

PROJECT MANAGEMENT - Lessons Learned from when things go right!

I spent some time recently responding to an Expression Of Interest for an IT development project recently and came to a question about similar IT projects and lessons learned from the experience. The project I had in mind was a large development project for a State Government department which had proceeded very smoothly despite the tight schedule and the project being approved to proceed 4 weeks later than estimated in our tender response. The upshot was that I found myself contemplating the pleasant prospect of what went right, not what went wrong...

Our lessons learned may be a bit different to other businesses because our contact centre services require a lot of coordinated involvement of different work teams - Sales, Client Services, Operations Support (trainers, call centre managers), IT, Management and the contact centre agents and team leaders - so the user experience is very central in our service delivery. Even so, we do a great deal of custom IT development to support complex services that integrate with our Customer Management Application. Examples include databases to collect data that can be exported to a client CRM; applications to control contextual call handling or direct messages to specific individuals or departments in a large organisation; or applications that can control escalation sequences or control bookings in limited capacity venues.

So, what we learned from what went right....

1. The Client Service Specifications were clear from the outset and did not vary during implementation.

This was very important because every time the specifications change, you have the prospect of having to back code changes to work already done, and you risk introduced errors and bugs that later need to be fixed.

2. We consulted with all the work teams and took on board their feedback before constructing the IT specifications for the IT Team from the Client brief. 

IT also reviewed existing work commitments and priorities and factored any long term hosting and support requirements for the application in our system planning at this point.

3. A Project Manager was appointed to set timelines and milestones and lead progress reviews and meet with the Client. 

The Project Manager had an operational role in the success of the project (call centre Branch Manager), which combined a clear understanding of the Client's requirements with the experience and authority to lead the team of agents (end users) handling the service. The Project Manager also had Management support to step in and assist in any area of the project delivery, including teams working outside her direct authority, to expedite any actions needed to keep scheduled progress on track.

4. With work teams working from 3 sites plus one client with various stakeholders involved, clear communication was vital to coordinated effort. 

A central email box was set up for the project for all relevant people; both client and the project team members received all information. Two documented meetings per week were scheduled throughout the project period (4 weeks) to review progress against timelines and milestones and action lists were generated (and followed up) for particular people working on the project from this.Top management were also involved in these meetings led by the Project Manager.

5. We tried to set work teams to work con-currently wherever feasible. 

For example, Client Services adapted the Client call flows to our internal norms immediately and briefed Operations and the main Branch Manager controlling the service as soon as these were received so that our Training Manager could commence developing training materials and key staff like Team Leaders could be briefed early on. While coding was undertaken, Client Services worked on other areas of the service delivery such as call recording and linkage to our Customer Management Application (our central communications platform) were set up. Our Web Designer started work on the look of the application at this point, too; specific menu changes were easy to adjust later.

6. User Testing continued throughout the project.

When the first draft of the application was available, this was immediately presented to the Client and our Trainer so our Web Developer received immediate user feedback on screen navigation and functionality before all coding was completed. Modules were also tested by users as they became available.

7. The Project Manager also met with the Client just before and again after implementation to check that everything was working as expected.

As a result of the continuous testing throughout development very few adjustments were needed at this point: success! As everything proceeded smoothly, there were no nasty cost over-runs, either.

We also found that we had more control over the project because all people involved were full time staff, and their work priorities could be reordered by Management more flexibly than might have been possible if sub-contractors had been used. This may not be the experience of associates who regularly collaborate with subcontractors on particular projects, but this project was quite different to other work that we have done, so it helped that the team worked together so well. 

A final point - let's not forget that it's all about people - congratulations go the Project Team and in particular, to our Web Developer, Cathy (pictured) for such excellent work.




Tuesday, 5 July 2011

EMAIL TRANSMISSION

Did you get my email?

Working in sales I've sent, received and seen enough missed messages to know that email is not infallible. Technical issues and human error can intervene, so some goodwill and perseverence is recommended if things go wrong. 

For the record, here are some of the issues we've encountered:

1. Wrong Address - it's usually safer to copy and paste than rekey anything, particularly phone numbers and email addresses. If your email program auto-suggests previous recipients, just bear in mind that it can also auto-suggest the ones that didn't work as well unless you clear these from the automatically captured list. You'll normally get a bounce back of a failed email minutes from sending it, but several times I've had such bounces a week or more later, so beware. 

Check the original name spelling, punctuation within the name, the domain address (especially the .com and .com.au variations).  Most addresses will be in the form of <name>@company or ISP domain that you can check on their website, though larger corporates may also have private domains not easily checked and recent changes to naming protocols have opened this up beyond .com, .gov and .org. Look out for .biz and more.

2. Spam filters - a graphic in your signature or an attachment, or the use of a particular word,  can cause the programs filtering your recipient's mail to presume it is spam and file it in the junk folder. Ask your recipient to add your name to their address list to prevent this (or white list it in their domain), or to check their junk folder if your email isn't in their Inbox. When all else fails, email in plain text and remove the images.


3. Lost in their server - in one curious case all emails to a domain address were not received. Our IT was able to verify that the emails reached the server, yet they were not routed to the recipient. Emails from other parties reached him, however, so we could only flag a problem for his webmaster to investigate. 


4. Misconfigured Domain Name Server (DNS) - if your recipient's domain name server is incorrectly set up, emails won't get through.


5. Misconfigured or temporarily unavailable Mail System - if your domain or Internet Service Provider (ISP) have a problem with set up, or find themselves temporarily blacklisted because of a spam issue, emails won't get through until the spam or configuration issue is resolved.


6. Free web mail services - these work most of the time, but they aren't as reliable as an email service you pay to have hosted on your domain or by your ISP. We don't recommend that you use free web email addresses for the messages that our Contact Centres send you.


7. Email deleted - if your program automatically deletes emails after a period or your mouse hovers over the delete button you can lose mail without being aware of this. I've seen Thunderbird move a message semmingly of its own accord just because you've entered certain keystrokes when you think you're typing elsewhere on the screen. 'Undo' and vigilance is all.


8. Work Pressures - in business many of us receive hundreds of emails each day. A few days off sick can take hours to catch up on. We've addressed this problem in Client Services support by introducing a central CSR ticketing system. Emails to this point create a job ticket that is centrally logged and allocated to a staff member to handle with an ETA response period. If someone is away, overdue work is visible and can be actioned by others. In general, though, some understanding of the realities of the working world, and patience, is advisable.

9. Server glitches - for an email to be sent it must leave your PC and be sent by your ISP or server and then be retrieved and routed by their ISP and server. Mostly this works well, but there can be glitches at any point. Follow up by telephone can be sensible if the matter is timely or important.


Fortunately, contact centre messages are less fraught because of the systems in place to send and track large volumes of emails. Our operators use 'Message drop downs' that are set up to send messages to preconfigured recipients; all they need to do is determine what the call is about and who should be notified how.

Email is great, but it is not infallible, and when it fails it's often no one's fault in particular. Keeping tabs on urgent matters and methodically working through the possible causes of email failure with goodwill are always the most sensible courses of action.

Thursday, 23 June 2011

Call Recording issues


In the past call recording has been the preserve of larger organisations, but the proliferation of 'on demand' PABX recording and the arrival of low cost 1300 number recording options has brought this within the reach of smaller businesses.

Call recording can be useful where your business wants to record that information or terms have been understood and accepted for legal reasons, or where you're running your own call centre and want to use this for training purposes.

Where you are outsourcing your calls to a contact centre, there probably isn't much point to record simple messages being taken, but used properly there can be some benefit with it to refine the handling of more complex services.

Important Considerations
You need to understand the difference from having staff that answer your calls all the time and know your business inside out, and the job of the contact centre generalist. The generalist gets little warning that this next call is for you, and has literally seconds to orient to your protocols. Simpler call handling protocols and higher volumes make their job easier, but be aware that it is inherently harder to answer for a range of businesses than for one you work in all the time. 


When you listen to calls you should also remember that the operator's perspective will differ from your own. A request that makes perfect sense to you, with your indepth experience, may not be so clear to a generalist. If the call isn't handled in the way you expect, pick a good call recording and one that you have concerns about, and send these to your Client Services support team for an opinion. They are better placed to understand what's going on in the call from both perspectives and can often recommend changes to the screen instructions or operator training that will make all the difference.


Legalities around Call Recording
When we record calls on your behalf, we play a message warning the caller that their call may be recorded for training or quality monitoring purposes. We also advise our operators that these calls are being recorded. This is a requirement of the federal Telecommunications (Interception) Act 1979. 

The general rule under this Act is that calls may not be recorded, but there are a few exceptions.  Organisations are allowed to record calls to record instructions, provide a record in the event of a dispute, or monitor training or coaching of staff handling calls provided all parties to the call are warned at the beginning of the conversation that the call may be recorded or monitored. This provides people with the opportunity to end the call or ask to be transferred to another line where recording does not take place.


When you decide to record calls to your 1300 number, a message is played to this effect to your callers, but this is not heard by the contact centre operators answering your calls. It is your legal responsibility to notify us if you intend to record your calls so that we can advise our operators, otherwise you will be in breach of the Act.


For more information on how this operates in Australia see http://www.privacy.gov.au/faq/individuals/q1



Monday, 2 May 2011

SMS Delays

Recently we were asked about SMS delays by two different clients. As it turns out, who your telephone carrier is and where you are can have bearing on this...

Causes of SMS Delay

At Well Done, we send out our SMS messages immediately. If a client is experiencing delays in receipt, it is likely to be a problem with the carrier. However, for the record, here are the potential causes of delay:
  • Their phone is out of range - an SMS requires less signal to get through than a phone call, and will normally get through where a call may not
  • Carrier capcity constraints - SMSs will normally get through in metropolitan areas faster BUT where there are high call volumes SMSs are given a lower priority by carriers than phone calls. They may allow a backlog to develop until enough bandwidth is available - it depends on their bandwidth and towers available.
  • Volumes A large number of SMS messages going out at once - this is unlikely at Well Done as operators are taking calls all the time and our SMS messages aren't sent out all at once.
Note that your message is sent once the operator completes their call log. The message is time and date stamped on our Customer Management Application (CMA) both when the call was first received and when the message log was sent. We can also go into our message gateway account and check when an SMS was sent.

At Well Done we use Messagenet because of their superior service provision over cheaper alternatives; we need to ensure fast and reliable handling of emergency calls.