Not, strictly speaking, an Excel post at all: but I thought I'd share this with you anyway.
From time to time, I have to cover the support work on a large reporting system which serves Excel files out through a web portal. We're running something between five hundred and a thousand distinct reports.
Here's an edited - heavily redacted! - transcript of a typical support call, with the details changed to protect commercial confidentiality, and the fundamental concepts entirely unaltered:
Fish: "Hi, Aquarium Support Desk?" Support: "Hello, this is the Aquarium Support Desk, can I help you?" Fish: "It's the water" Support: "There's something wrong with your water?" Fish: "Yes, there's something wrong with the water: can you help?"
Support: * Thinks * I could ask what's wrong with the water, again... Support: ...But it's going to be quicker to get the testing kit and go there myself
Support: "Which tank are you in?" Fish: "Yes, I have a problem with the water" Support: "I need to run some tests, can you tell me which tank has a problem with the water" Fish: "Thanks, how long will it take you to fix this?" Support: "I don't know which one of the 450 tanks of water in this building has a problem, and I need to know which tank to test" Fish: "It's a problem with the water, can you tell me how long it'll be?" Support: "Are there any identifying marks on your tank?"
There's no 'punchline'... So lets stop right there, and nail the mistake before the repetition gets tedious.
The Fish has no concept for 'Tank' and the support technician doesn't realise that nothing AT ALL is communicated in any question or statement centred on 'tank' and 'location'.
Maybe if Support used the word 'Aquarium', they'd get a response; and maybe not - some people have a distinct vocabulary for their work, and the concepts embedded in their work can only be communicated in that exact language (Oracle administrators are the most extreme example) - but it's entirely possible that the fish has NO vocabulary for, and no concept of, a distinct body of water with a boundary container.
That's not to say the fish is stupid - I'd like to see how long *you* would last on a tropical reef, and your attempts at breathing when immersed in water are, quite frankly, embarrassing - and anyway, the problem was never going to be solved by being 'smarter' than the fish.
The problem is going to be solved by being smarter than a support technician who doesn't see that that a gap in communication isn't going to be fixed by throwing more questions down the the same hole: asking for more details about the tank won't work, no matter how many questions you ask, if 'Tank' is a concept you can't communicate at all.
So here's the 'fix': ask a question centred on a concept the user will understand, with answers that will 'leak' location information:
Support: * Mutters, almost as if he or she doesn't want to be heard * Support: "It's the 4%@#ing octopus again" Support: * Asks, clearly and politely: * Support: "Is there an octopus in the tank adjacent to yours?" Fish: "There's a Pacific blue-ringed female so sunward..." Fish: "And a tuberculate pelagic octopus next to the source of vibration I complained about last week"
Support: "Tank 224. I'll be right over with the testing kit"
Something else for you to ponder: the 'user experience' here is that Support asked no end of irrelevant questions that elucidated nothing except their own cluelessness, and they took their own sweet time to get to work on the problem.
And the first thing the user will see is support faffing around with a testing kit, when they've already been told, repeatedly, that there's something wrong with the water.
Support isn't a technical skill, it's about communication and manipulation. And if you are wondering how this fishy tale is relevant: more than half the time expended by support technicians in speaking to the users consists of failed attempts to identify the specific report that the user needed fixing..
So anyone who builds reports - or Excel applications - and releases them for widespread use needs to be labelling-up *every* sheet with the app or report name, and filling in a 'Settings' or 'about this report' or 'documentation' sheet that the user can be guided to by first-line support. Or by you.
And the moral is:
The most important piece of information that your application, worksheet, or report can communicate to a support technician is an unambiguous identifying name; and, better still, a location.Meanwhile, I will buy you beer if you can bring a toxic blue-ringed octopus into today's technical explanations to the users.
