 Let us play a game!
You get 1 point for every correct answer: Scenario: I call my bank [1] via their general enquiries telephone number obtained from their website. I just want to understand what their local branch hours are during lockdown. (No, their banking hours have not been updated on their website) Q1: How long did I have to hold before I was able to navigate through the IVR options and successfully speak to an actual human being? Q2: How many options did I need to select before I was able to speak to a human being? Q3: How many times did I need to re-enter my Identity number before I was able to speak to an actual human being? Q4: How many times did I need to repeat my REASON FOR CALLING to the BOT what asked me what my query was about before passing me through to the next IVR option? Q5: Did the BOT direct me to the correct division, based on my (finally accepted) response? (This is a Yes/No question) Q6: Did the human agent ask me for my REASON FOR CALLING? (This is a Yes/No question) Answers: Q1- Three of the longest minutes of my life (I suspect this was a good day and I should be grateful) Q2- Six – but to be fair, I bailed out after starting to beat my head on the desk… so by repeatedly entering the ‘#’-key, the IVR gives up and transfers you to an agent (#NoteToSelf, #TimesavingTipForFuture, #YesWeCanBypassYourSillyIVRTree) Q3- I gave up after the third time. (I was extremely careful to enter right correct numbers) Q4- Three. BOT > HUMAN? (I don’t think so) [2] Q5- What do you think? – NO! Q6- Yes (…I did not and still don’t have words…) If you got too many questions right, I think we are all in more trouble than we thought we were… This was (unfortunately) a real-life experience. No kidding! You know I am not kidding because I bet you’ve experienced it too…on numerous occasions…am I right? Why does this happen? IVR (Interactive Voice Response) is a technology that gathers information and then routes calls to the appropriate recipients or divisions who have been trained to deal with that specific type of query. It is implemented by organisations to primarily save themselves some money. Bottom line. IVR systems are typically rolled-out in call centre environments where agents are quickly trained in only 1 or 2 specific skills (silo-based) and if something is encountered that is beyond what they were trained on, they would need to transfer the call. This is probably dictated by business models where call centre staff are paid minimal fees, work in shifts, are youngsters/students/temps and where the turn-over of staff is very high. The IVR call-tree helps business manage calls across their workforce. It begs several questions around how serious such organisations are about serving their customers or giving them a wonderful experience…but let me not completely derail myself here. I’m not sure if customer experience has EVER played a major role in deciding whether to implement an IVR solution (come on – be honest….), but I would venture that costs typically override customer experience… Maybe the heart of the matter is…what culture are we trying to create?
These are processes that are NOT: S - stupid U - ugly C - confusing K - killing your customer’s enthusiasm to buy from you again…ever! Obviously no-one (in their right mind anyway!) ever sets out to design processes that qualify in the above categories, so why then do we end up with them? This might be because of tight deadlines, not starting with the customer in mind, not testing the processes with the target audience or even not updating implemented processes once they are found to be sub-optimal or S.U.C.K.’y….. Whatever the reasons, we should seek to prevent the creation of processes like these by all means. Here are a few suggestions to consider next time when you design your next process:
“Knowing the right thing and not doing it is the ultimate cowardice” as well as Ignoring to do the right thing when required Credit: Danie Van Den Berg
0 Comments
Best Way to resolve issues involving conflicting requirements from two or more stakeholders?17/5/2020 In order to determine what action should be taken to resolve conflicting requirements, the analyst must first determine the root cause of the conflict. The causes of conflicting requirements are typically the same, time and time again. Here are a couple of the more typical causes and how you might deal with them.
1) One or more of the stakeholders/groups misunderstand the higher level divisional or company goals which are driving their specific requirement. This leads them to push for a process or system requirement that is not in line with the true needs of the business.
Credit: Chris Adam & Samuel Olanrewaju |
BloggerSamuel Olanrewaju is an Enterprise Analyst with over 10 years’ experience of delivering Multi-Million-Pounds End2End SMART Requirements & Solutions in the Finance & IT Sectors. 
|