Successful Re/Solutions Require Precise and Detailed Communications

My brother and I were recently discussing how we personally dealt with customer services issues from the customer perspective - i.e. as a result of something going wrong during an online / digital retail purchase. In his case a payment gateway had taken his money, but the actual checkout status was simply that the purchase had been cancelled (i.e. 0 transaction value), in my case - something had been ordered but not shown up for delivery for an unusually long period.

Both of us are veterans of nearly two decades of Forum support and specifications and briefings for our own companies, and know how important clear and precise, and sufficiently detailed communications are in order to achieve successful outcomes. When I follow up a query I include as much pertinent information as is reasonably possible - time and date of transaction, references to individual stages of progress - from origin / source to end point - and reference to any kind of ’receipts’ including email notifications, screen shots, order and invoice references and anything else visible during the process - possible error codes or oddities encountered. I learned from an early science scholarship - that it is all about the powers of observation and how finely you communicate those. In my scholarship group I observed an ammeter pointer barely move during an experiment - but it did very fractionally quiver and I noted such when no one else did - earning bonus marks along the way.

The same is true of any kind of written exchange - and in these circumstances you are far better served by the written word and visual attachments than merely by voice alone. I will always put things in writing as it is the quickest and most comprehensive way to communicate the most details - and can be the most precise too. We often have to educate some of our customers on occasion to get them to understand that the formal written word is usually the strongest means of communication - and that precise reference points are critical to the success and speed of resolution. Occasionally a screen-share or Skype call can assist with nuance, but in the case of most queries, the bare bones written details are what’s essential.

With Markus’s phantom transaction - he was able to quote a variety of different reference points in order to communicate how his money had in fact been taken while the core system reported essentially that nothing had happened. Without the proper ’receipts’ and references being communicated it would have taken a lot longer to get his point across convincingly - if at all. As it was, he was able to communicate clearly and emphatically that the payment system had taken his moneys without registering any record of the transaction. It only took a couple of personnel on the other end to trace the sequence of described events and resolve the issue equitably.

In my case, I also very emphatically and descriptively, yet briefly - set out my sequence of events with the pertinent references, and was able to come to a reasonably quick and equitable outcome. Had I been less precise and less detailed - the process would simply have taken a lot longer to resolve and would have required more toing and froing until the investigating party could be satisfied that they understood the issue sufficiently - how it may have occurred, and what the correct resolution should be.

All too often we are forced to try to deal with issues where there is no proper paper-trail or detailed sequence of events, and too many references are missing to be able to make any sort of reasonable progress. You really must be able to put yourself in the position of the person at the other end - they are often coming to this completely blind / cold / fresh - and if you don’t give them a properly signposted path to follow, they may really struggle to make any reasonable forward progress at all.

When dealing with digital formats and software, it is always key to communicate precisely, in a scientific manner, how a problem arose, and what the likely steps are to replicate it. You also need to record the ’ambient conditions’ at the time - which will include things like browser type, screen resolution and device. Then you must annotate a sequence of steps with URL references and screenshots as necessary, so that the problem-solver can re-trace your exact steps to hopefully arrive at the same juncture or conclusion.

To do any sort of due diligence we have to have a clear understanding and be able to trace the correct sequence of steps, as the trigger point to an error or issue can occur at any point in the chain - hence the starting point is often critical - for instance you may have clicked on a link in an email to get onsite - this is important evidence, as that link is likely unique, with a unique tracking code which can record behaviour and signify where the issue likely occurred.

Never try to second-guess or self-diagnose - like a visit to the doctor, you just need to clearly and sufficiently be able to communicate the symptoms. As with any visit to the Doctor - as much pertinent detail as possibly is critical, because so many conditions share largely similar symptoms - where it’s only the tiny slight deviation or variation which allows the Doctor to figure exactly what it is you have. Insufficient detail will simply lead to mis-diagnosis which will certainly not lead to a successful outcome.

The same can be said of any kind of briefing or reporting - they must be conducted scientifically and with proper references, otherwise you are most unlikely to reach a successful outcome ... at least certainly not in any kind of timely manner.