Sometimes things go wrong. Sometimes it is our fault, and sometimes it is, dare I say it, something the client did wrong. We are all human, and as long as humans have any part in controlling anything, there will always be human error.
The good news, however, is that we are always on alert when things go wrong. We have lots of tools at our disposal for mitigating problems, including creative ways to inject automation into the process, using our talented staff to take a second look at data processing, and simplifying processes. Above all, we are here to get our customers up and running, no matter what the origin of the problem.
Want some examples of how we execute where there is a problem? Let’s look at a couple of recent challenges we have worked on, and their outcomes.
The case of runaway transactions
What are runway transactions? These are transactions that get run up on a key for an unexpected reason. There are a couple of main causes for these situations.
First and most commonly, runaway transactions happen because of testing. This is usually okay, as most testing happens during the evaluation phase of onboarding with our services because there are strict limits placed on free trial keys. Often, however, organizations change their processes and those changes involve a new testing phase.
So from this perspective, it really depends on what is being tested. If they are testing a change to something in the process that doesn’t directly involve using a Service Objects’ license key, then a developer or tester can potentially forget that there is a license key involved at all. Then, without the consideration of the key, they go ahead and do some stress testing on their process and unwittingly run up a lot of transactions.
Another reason for runaway transactions is because of seasonal surges or some sort of promotional event. Imagine if you are having a promotion that brings in thousands or even millions of extra users to your site, where the call to action is to sign up for your latest and greatest product. Now your license key has run out of available transactions, and the form the users are using is no longer validating the data input from the visitors. As a result, dirty data is being added to your system.
You can sleep worry-free because we are always watching out for you in situations like these. First, through monitoring transaction fluctuations versus your historical usage and, second, through alerts we get when you exceed daily transaction limits and thresholds we set. Any of these alerts trigger our team to reach out and act to mitigate the potential problem. Or sometimes a client’s developer will quickly realize they just executed a process that was going to burn through a huge amount of transactions and will shoot us a desperate email to help them avoid an outage – in which case we spring into action very quickly.
How quickly? Here is what happened recently…we received a customer support email at 5:30 pm indicating that a client was going to run out of transactions because they were experiencing some unexpected volume. By 5:36 pm we already had a representative on a call with their organization working out a solution, and even though we couldn’t work out a completely new transaction agreement in the moment, we gave the client what they needed until we could work out the details. Including a couple more minutes to set up the temporary transaction increase, this was about an eight-minute duration from request for help to a solution.
You read that right, eight minutes – and better yet, this was during a part of the day when most of us were already out of the office. So, what happens when we are all out of the office? What happens at night? Those are great questions, and the next situation will help paint a picture of what we do.
The case of the canceled key
A good example of how we react to after-hours requests is a situation that happened in December of 2018. A client emailed us that they were no longer able to make transactions against their key at 8:20 pm. By 8:50 pm, 30 minutes later, we were already on it. And had this the request come in through our after-hours phone support channel, we would have been on it within minutes.
The person who started looking into the problem here at Service Objects was a developer, so he did not have access to all the data needed to diagnose the issue, but he did realize that the key expired and that this was a long-time client. He decided that the best solution would be to extend the expiration of the key for a couple of days, giving everybody time to track down why the key had expired. Soon after, at 9:05 pm, the problem was solved. The client was happy because they kept running. It turns out that management at the company with the issue did not inform their developers that the key would be turned off, since they decided to replace the service with another upgraded service from Service Objects.
This case was a good example of how fast we respond – a response time that is even faster through our phone channel. Moreover, it shows how we make choices on the side of our clients. We were not going to let a client, be they long-term or short-term, sit around until the next day wondering what is going on while we were troubleshooting it. In this case, we gave away several transactions that we didn’t have – because it was in the best interest of our client, which if you think about it, is really also the best for all of us.
‘Everything goes smoothly for us always,’ said no one ever. Like I said at the beginning, we are all humans and we will make human errors. But responsive service is in our DNA: here is another post that goes into more detail about our service standards. It’s how we handle our errors and, dare I say it again, your errors, that helps define us as a company ready to give you the best customer service.
