I recently registered for Homecoming Weekend at the old alma mater. For me, it’s a reunion year ending in zero, so this year is of particular interest to me. (No, I won’t say which one it is. All I’ll say is, I’m getting old!)
While going through my own information on the Homecoming web site, I noticed a minor error. It wasn’t particularly big, and the error isn’t important in and of itself, but the university wouldn’t let me change it online; I needed to email them to get it fixed.
In response, I received a Jira service request notification indicating that it was in the queue. I knew right away that they were using Jira; we also use it in our office, and the email format and appearance is unmistakable.
The next email I got from them, a couple of hours later, is the graphic you see above, and as someone who’s worked in technology his entire professional career, I found it to be particularly irksome. When I received the message, my immediate thought was, “excuse me, but I am the customer. Who are you to say that my issue is resolved and completed?!?”
Sure enough, when I checked my information again, it still hadn’t been updated. I even tried clearing my cache and refreshing the browser. No dice. I wrote back, saying that I didn’t see the change and asking how long I should wait before I saw it. For all I knew, the web server had to refresh before any data changes appeared, so I gave it the benefit of the doubt. I received an automated message saying the case had been reopened (I was responding to Jira, after all). I didn’t get another response until this morning, when once again, it was marked “Resolved” and “Complete.” When I checked my information again, the change was there. I did not receive any other communications or acknowledgements, other than the automated Jira responses.
In their defense, to me, a department called “Constituent Records” sounds more like a data end-user role, rather than a full-blown IT or DBA role (I could be mistaken), so maybe they weren’t versed in concepts such as tech support, support levels, incident management, or support procedures. Nevertheless, I still found this to be annoying on a couple of levels.
First, it is up to the customer, not the handler, to determine whether or not an issue is resolved. The word “customer” can have a number of connotations*; in an internal organization, the “customer” could be a departmental manager or even your co-worker sitting next to you. To me, the “customer” is the person who initiated the request in the first place. An issue is not resolved until the customer is satisfied with it. It is not up to the handler to determine whether or not an issue is resolved. The handler does not have that right.
(*Side thought: the customer and handler can be one and the same. If I come across an issue that I’m working to resolve, I am both the customer and the handler. Nevertheless, the issue isn’t resolved until I, the customer, is satisfied that I, the handler, took care of it to my — the customer’s — satisfaction.)
Second, as a technical communicator, I was annoyed by the complete lack of communication from the person handling the request. The only communications I received were either comments contained within the Jira ticket or automated responses from Jira itself. Not once did I receive any message asking for any feedback or asking to see if I could see the change. The only messages I received — before I responded saying I didn’t see the change — was an automated Jira response acknowledging that they had received my request, and a second message that it had been resolved and closed. Boom. End of story.
I’m writing this article as a lesson for anyone working in a support role. First, feedback is important. You need to know that you’re handling the issue correctly. “How am I doing?” is a legitimate question to ask. Second, it is not up to you, the handler, to determine whether or not the issue is resolved. That right belongs only to the client — the customer who initiated the request, and whose issue you’re handling.