First, a personal story.
In the early life of our B2B start-up company, we had less than a hundred clients and were able to have close relationships with most of them. This translated into regular conversations with our customers, during which we’d get a lot of special requests for our software and services. It was easy to get a sense of what our customers wanted. And since we were still young and unsure of the specific direction we want to take with the product, we often catered to our customers’ needs. We followed through on almost all customer requests.
Slowly with time, and as our customer base grew, our tailored approach to servicing customers showed signs of weakness. Our teams worked 12 hour days just to keep up with all requests, and our product was being pulled in a dozen of different directions. Worst of all, our customers started holding us accountable for delays in service requests that we took on as courtesy (these weren’t technical support requests, but rather actions that customers could do by themselves).
It was clear that our approach wasn’t scalable. We couldn’t continue on without hiring dozens more team members. This would have set our margins way back. So we did what every startup in that need to scale does: We created processes. We began to standardize responses to customer requests, and setting clear expectations around what we do and what we don’t.
Everything worked well at first. Having processes helped us save time and improve the way we respond to common requests. In turn, it allowed us to focus more energy and time on customer education, creating more self-sufficient users.
Yet a few months after we started creating processes, it overwhelmed us. Our team documented preferred solutions and responses to all situations imaginable, including edge cases. Our operations manual was over 30 pages long. You know something’s wrong when people have to spend 15 minutes looking for the standard response for requests that take 5 minutes to resolve, or skip the standard process entirely because it was too much of a pain to find. Yes, we went overboard with standardization.
With time and experience, we were able to find a balance. We standardized responses to common requests, but more importantly, provided a general philosophy and rule of thumb for the rest. This gave flexibility and control to our team members, who could respond accordingly, acknowledging the context of the situation.
For example “Protect service margins” was one of the rule of thumbs that helped our account managers decide whether to pursue a time-demanding project, while “Prioritize high value clients” was another guideline they’d have to account for when dealing with customers with high value contracts. Based on these, there was no standard response to most edge cases, but simply guidelines to help team members take an independent decision.
The result was that we achieved consistency in our general approach to customer requests, without being boggled down in the details. For common requests, everyone responded similarly. For edge cases, our team members had the flexibility to do what was right in their perspective, based on general guidelines. More importantly, we were able to start providing standard service level agreements (SLA) to our customers, setting clear and transparent expectations.
I’ve learned that processes are good as long as it doesn’t slow our team down. In part five, we’ll explore how to manage common issues around process creation and process changes, including:
- When to change a process;
- Changing processes too often;
- Handling edge cases.
Should I break the process?
As a company matures, it is bound to adopt more processes to guide operations rather than rely on one-time decisions from individuals. This is how an organization gains operational efficiencies as it grows. We will not be reviewing process improvement techniques in this blog post (explored in part 4), but rather discuss when to break a process and when not to.
The need to break a process usually starts with a special request or edge case that an existing process doesn’t allow or didn’t consider.
For example, a high value customer asks for a refund at a major retailer without a receipt, past the 30 day refund deadline. If we follow the refund process, we may disappoint and lose a high value customer. So should we break the process?
One thing to recognize is that every edge case is an opportunity to assess whether the business environment is shifting and identify new market trends. When there is evidence that customer expectations are shifting, responding quickly and effectively can yield a big competitive advantage.
Consider news readers that shifted their source of information from newspapers to online articles. Publishers that acknowledged the market change were able to adapt and avoid irrelevance, while those that didn’t went under or had near death experiences.
To evaluate how to best respond to an edge case request, let’s adopt an analytical approach to answer the following questions:
Who is affected by the event and how? Knowing who is impacted will allow us to seek and consider their opinion on how to respond and why. Stakeholders can be customers, partners, or internal teams.
Is this truly an edge case or the new trend? Statistically speaking, an edge case or outlier event only occurs in rare instances. The frequency at which an outlier occurs should also not increase substantially over time.
On the other hand, a trend should experience rapid change in the ratio of occurrences over time.
To perform an accurate analysis on an event’s occurrence, I recommend segmenting the data by different population groups, categories of events, and other relevant variables.
➡ If the event is an edge case: The question becomes whether the edge case is worth breaking a process for.
- If the edge case doesn’t merit a break in process: Say no, explain why, and move on. This option is best used when the benefits of upholding the process outweighs the benefits of allowing an edge case to occur. Questions that can help us assess the situation include:
- What’s the implication of breaking this process?
- What’s the precedent that we set?
- Does it set the precedent that we want? e.g. Is offering a refund to a customer aligned with our company strategy? It could be, if the strategy is to provide outstanding service, but it could also not be, if we are a low-cost provider.
- If the edge case is worth breaking the process for, the benefits of breaking the process needs to outweigh the benefits of upholding the process. Note that repetitively breaking a process will slowly erode the process, so if we find ourself repetitively breaking a process for the same reasons, we need to re-assess whether the event is a new trend.
➡ If the event is a market trend: The organization needs to decide how and when to respond at the soonest opportunity. Not acknowledging a market trend puts the company at risk of being irrelevant.
- Does this new trend require re-designing the entire process? This is usually the case if the new trend is rapidly changing market expectations, or if the existing process is quickly becoming irrelevant. There is no time to lose.
- Or can the current process be amended and maintained for now? This approach can be taken if the existing process is still relevant, and there is no clear evidence that the new trend is rapidly changing market expectations. This allows us to wait and observe whether the trend grows, then prepare for an eventual process change when the time is right.
Let’s remember that every edge case is an opportunity to observe a potential shift in market needs. Sharing this insight with team members and having a data tracking system in place will ensure that no opportunity is missed.
Are you leading a startup team? Subscribe below to join our community!
Let’s pick a special request that was recently received and evaluate whether it is a new trend or an edge case.
Subscribe on the right for new insights every week!