Future of Support
October 23, 2015
Where are we going in support? What is being done to craft better customer experiences outside of faster response times? One of the biggest jumps we’ve made is easy to put together self service sites to cut down on the “easily” answerable support / how-to questions a customer might have.
But what about that error that isn’t easily reproducible? Those errors might look like:
Null object reference not found
The customer has no idea what they did to cause the error, and without a reproduce the logs might not be clear to engineering what the cause is. It might only happen a couple times a week, it’s an annoyance, but not happening enough to assign a developer to dig deep into it.
I went to an engineering talk yesterday that discussed how a local company sped up the prototype process from weeks to a few days for new features they wanted to put in front a customer to get feedback on by being able to easily modify the View and State of an app. In this specific case it was an angularjs app the company develops.
This talk gave me ideas on how an app if from the beginning architecture level was built with support in mind could allow those small nagging issues to be resolved quicker than ever.
The basic jist is this – An app goes from State > View > DOM. Using a house as an analogy the View is the rooms in the house, the State is how furniture and such is arranged, and the DOM is everything coming together when you walk through the house.
Where this can become a breakthrough is the State is a JSON file that holds the information of what the data looked like at that moment. For example: A support app would have Open, Complete, Solved as an option for ticket on a screen, the State would hold what status the ticket is in. If the status of the ticket changed from Open to Complete the State JSON would be updated to reflect the Closed status.
This puts in an amazing position where when we run into the dreaded:
Null object reference not found
When reported the current State and the States leading up to the error could be sent to the support rep could in a DVR like way walk through what happened for the customer in a Sandbox environment, and hopefully get that ever valuable reproduce. We would then learn if it’s a bug that needs to be fixed or maybe something as simple as making an error message clearer.
Maybe this isn’t 100% possible, but if an app is built with this in mind from the beginning it could open the flood gates of solving the nearly impossible to solve.