A terminated customer is not a lost customer
We knew Q1 2020 was going to be a tough quarter. But we also knew that a large number of new SIEM customers were entering the business, so our hopes were intact. All of these customers were existing customers simply with a different SIEM system that they wanted to change. Their common denominator was a dissatisfaction with their current supplier, which was also the case with our terminating customers. The dissatisfaction was caused by the fact that expectations for the system, the economy and internal requirements had not been sufficiently aligned.
With that in mind, I contacted one of our four customers in question, with the intention of booking an hour’s meeting with them, where I wanted to clarify their reasons for terminating the SIEM agreement.
Prior to the meeting, my team and I had had a thorough review of our existing working methods. We established a new process for onboarding SIEM and surveillance customers in the future. Today, this process is our standard process.
The first meeting with the customer: We talked about purpose!
The focus was to clarify the customer’s intention and specific need for a SIEM solution. We had identified a number of issues that needed to be clarified at the meeting: “Why did they want a SIEM solution? What was it for? Which challenges would they like to solve? Were there any legal requirements for reporting? How would they handle GDPR sensitive data? How would the solution be operated and how would they report to management?”
The most important issue of this meeting was about operation. The challenge with a SIEM solution is that as soon as you start sending data to a SIEM system, clean-up must be carried out on an ongoing basis. If this is not the case, the data and the information collected become useless.
The second meeting with the customer: “How do we dimension your SIEM solution?
The customer called us for another meeting with the agenda to clarify how such a SIEM solution should be dimensioned.
Based on the customer’s needs and with input from Elastic, we then developed some models for calculating data usage, storage consumption and events per second in order to be able to dimension the solution, as well as a description of how many licenses and number of servers and logs should be used.
The source of good cooperation? Expectation reconciliation
The second meeting was followed by a serious of meetings with the purpose of reconsiling expectations.
At the subsequent meetings we talked about:
- Sizing and reviewing the process for the implementation: Purpose – process – delimitation – contents & delivery – estimates – schedule – assumptions – risks – organization (who participates and what role do the individual project participants have) as well as finance.
- How much time the customer could expect to spend and review of the schedule that lay ahead of us.
- What was within scope, and just as important; what was out-of-scope. This reconciliation of expectations is incredibly important, as it must ensure that the agreed terms are met.
In this process, we learned that by using short projects with a project length of a maximum of 3 months, we can delineate the task and ensure a successful delivery and anchoring of the project.
When each project is completed, a shortlist and a project evaluation are drawn up to ensure that we continue with what went well and to correct what can be improved.
When a project is completed, a new project is started with new goals and a new process.
Clarity of retention period
We had now reached the point where we had clarity about the architecture, needs, process, number of log-ins and. EPS consumption, but we had yet to become 100% aware of the retention period – i.e. how long one would store log data.
We presented a graph to the customer that showed the number of months and what cost it would entail with the number of ESP calculated. The graph formed the basis for the customer’s decision – 13 months were considered to be a reasonable retention period.
We touched on the topic of operation, as we needed to get a clear picture of how the solution was to be operated. We agreed on a flexible solution where the customer focused on the projects and implementation of the solution. We were thus responsible for the very basic operation of the SIEM system; a both scalable and flexible solution that the customer can jump in and out of as needed.
After a process of 8 to 10 meetings where we worked through the onboarding process and everyone now had a clear picture of the size, cost and operation of the solution, all we had to do was to clarify which reporting/dashboards the customer wanted. It was agreed that we would come up with some proposals which we implemented. Based on these proposals, the customer could choose what they needed.
It was a good process about on-boarding a SIEM solution, which culminated in the customer calling us and informing us that they wanted us to deliver the solution.
Successful on-boarding process
We did it. We won the customers back thanks to a successful onboarding process. Just as disappointed as I was in Q1, just as happy I was in Q4 2020 as our process proved to be the success we had hoped for. In this process, we learned how important the onboarding process is, and we have been using that process ever since.
We hope that history has given you food for thought and that it is good reminder that if a customer wants to terminate their agreement, it is not necessarily a lost customer. It is never too late to establish a good onboarding process.
That was our story, and we hope you can use it. A few days later, I had a meeting with Gartner, who showed me a slide that said:
“The best technology never wins. The best story and sales engine always do!” Rob Addy.