A crisis is a critical and decisive situation that endangers the growth of a project.

As far as we’re concerned, when a crisis arises, the quality of service we offer our clients is at stake, so we must be careful and agile to react in the best possible way.

The case

I want to tell you about a crisis I went through while serving a start-up almost two years ago. The company offers boxes of succulents on a subscription basis and has thousands of subscribers.

It started on July 24, 2018, a date I still remember. That day, the client told me via Slack that the pre-paid annual sales function wasn’t working. Immediately, we started investigating and, indeed, each pre-paid annual purchase was getting charged monthly. 

By charging monthly — that is, performing 12 transactions throughout the year — the company was at risk of breaches due to lack of funds, theft, credit card changes, credit card expirations, and more. Charging one payment in advance is always better than being vulnerable to these risks. Being paid up front is also better for cash flow. 

Additionally, when customers pay annually rather than monthly, they get the cost savings (and positive user experience) of a discounted rate.  

Every time I encounter a critical situation like this one, I experience two strong, paradoxical feelings. On one hand, I get the adrenaline of going out of my comfort zone and having to push my leadership and research skills further. On the other hand, I feel uncomfortable because of the client’s situation.

Despite these feelings, I tried to keep calm in front of the development team because, if I became impatient, I would have affected their response and interfered with our teamwork. 

Managing the situation

Twenty minutes passed, and the problem still was not solved. John, the client, was waiting and expected us to solve the problem ASAP. He was visibly anxious, yet calm because he knew we were actively working on the matter, and we were just as concerned as he was.

We established brief (five minutes, maximum) intervals for delivering status updates.  And even though there was not always something new to report, this move was crucial for showing John that I was available at all times. 

When, after working with the developers, we found the root of the problem, we defined an estimated time of arrival (ETA) for implementing the fix and shared it with John. Keeping in mind that the situation was already frustrating for him, as it had a powerful impact on his business, we tried to be as precise as possible and not increase uncertainty.

The fix is ready, but the case is not closed

We took one hour to reproduce, diagnose, and fix the issue. Now, after solving the problem, it was critical to provide a detailed explanation. John needed to know what had triggered the issue and its impact on the project.

Thus, we arranged a meeting with John that day. We wanted to show him the technical cause of the issue and the exact time it started.

We found out the problem had existed for three months, and had started during a deploy that updated some of the bundle prices. We shared this information with John and, although it wasn’t good news, we made him feel reassured by being transparent about what was happening and showing him that we had the situation under control; he trusted us. 

During that three-month period, all yearly prepaid subscriptions got processed as monthly. The biggest problem was that we didn’t know which subscribers had chosen the annual plan, so we couldn’t change it and charge them the right amount. Additionally, most of them had already paid for two or three months. Now, let me tell you how we managed to find them.

Analyzing the impact

To analyze the impact on the business, we created a report on the number of subscriptions that were likely affected based on the history and percentage of annual pre-payments. According to our calculations, the billing would have been approximately 10% more during May, June, and July. 

We identified the affected subscribers from a back-up and started thinking about how to solve the situation by brainstorming with the entire team. Some options were:

• Send emails to affected users and let them decide if they want to change the plan and pay the rest.
• Change the plan through a script and charge the remaining sum.
• Let it slide.

John decided to route queries to customer service. Additionally, he contacted those affected via email to explain what happened, giving them the opportunity to pay the remaining months in advance, which approximately 25% of them decided to do . They did it through a script we created and executed to calculate the months not yet charged. 

The situation wasn’t pleasant, but it helped us strengthen our ties with John, as we managed the matter with commitment and professionalism at all times.

Takeaways

The next day, we held an internal meeting to discuss what had happened and propose ideas for preventing it from happening again. One excellent improvement that came from that meeting was making unitary tests a standard practice to detect similar situations before our code reaches end users. 

Every crisis is an opportunity to grow and learn. It is vital to hold a “post-mortem” after each one to determine the real reasons behind it and propose changes to improve the process and prevent similar issues in the future. 

Over the years I’ve realized that this step is crucial for building trust with clients, as is the commitment to solving the problem and the professionalism required to communicate it.