We often hear customers talk about digitization or automation of processes.
Although in their own right, these are all sensible approaches to optimizing processes, they’re hardly ever a one-size-fits-all solution. As most often is the case in business, the verdict is: “it depends”.
The reality is that automation and digitization should be treated as one of the last steps when optimizing or re-engineering processes. Processes exist for various reasons (more on this here), but not always do these reasons make sense.
Prior to talking about automation, we should assess why processes exist and find other ways to optimize them.
At Monogon, we have developed the following mental model:
Eliminate
The first consideration is whether a process should exist or not. If the process does not add value to your customer or organization, it probably should not exist in the first place. There are a few models that can be used to assess value add, such as for example Michael Porter’s value chain analysis or the business model canvas.
Some questions to get started:
- Why does this process exist?
- Should this process exist or is it based on outdated practices and believes?
- Does it add value or add cost, complexity and confusion?
- Is it a key part of the core deliverable to the customer, or is it a back-office process?
Case study example:
One of the clients we worked with had a team dedicated to reconciling and reporting on data between the different organizational siloes. This team was absolutely critical to the organization, as it was the only way to get a holistic picture of the organization.
However, in the future state Monogon designed where there was only one source of truth and a de-siloed organization, there was no more purpose for this team or their processes to exist.
When reasoning from the current state, it was impossible for this client to see a future without this team. Reasoning backwards from a future state, it was clear however that this function was redundant.
Simplify
Even if a process adds value, it does not mean it is doing so in an optimal way. Some processes have become too complicated over time, adding steps or logic that has become redundant. Processes typically become unnecessarily complicated when they span across functions and roles, e.g. multiple hand-overs, duplication of work, various layers of escalation, sign-offs and poorly understood rules.
Some questions to get started:
- Can we make this process simpler?
- What steps in this process are redundant?
- What makes this process more complex than required?
- What kind of rules, logic or interactions are poorly understood by customer and staff?
- Where do we spend a lot of time educating?
Case study example:
One of our clients had 4 layers of escalation in their customer support process. As the customer was passed on from one team to another, or from one agent to their manager, information was lost and the customer was left repeating their problem various times.
Monogon designed process and infrastructure to empower the first support rep to address the client’s concerns without the need for escalation. Frontline workers were empowered, which in turn alleviated middle-management to spend more time on training and performance management.
Empower frontline employees to turn a vicious circle into into a virtuous circle.
Standardize
Even if a process were as simple as it could be, if it is executed differently in different places, there is still slack and redundancy in your organization. Sometimes, this is desirable to account for unique characteristics of markets, but often this happens organically without any holistic oversight. Bring the pieces back together and you will find that there are unnecessary differences between your markets.
Some questions to get get started:
- Across different functions, teams or geographies, which processes with the same output follow different steps?
- Do these activities differ because of regional idiosyncrasies or because they evolved differently?
- If we standardize, what trade-offs do we need to make?
Case study example
In the redesign of the marketing processes and organization of a client operating in China, we found over 600 different landing page formats that the MarTech team was maintaining. In addition to that, there were well over 3 million e-tags that the marketing team had already lost track of completely.
Monogon worked with this organization to define standardized UTM variables. We also designed a standard landing page format and aligned the messaging, which reduced the number of landing pages from 600+ down to 6.
The overhead in the MarTech team was significantly reduced (from 19FTE to 3FTE) and the business was empowered to analyze its marketing activities, track and iterate its campaigns and manage most of its own operations.
Consolidate
Some processes run across multiple geographies or functions. This is often where we see processes running in parallel. This fragmentation of work results in sub-optimal use of manpower because the throughput of parallel processes cannot be optimized between business siloes.
Some questions to get started:
- Are there regional or cross-functional activities that result in the repetition of work?
- Do these processes run in parallel?
- Are there processes where handover between functions results in an overlap?
- Are there differences in utility of regional teams?
- Should regional teams exist in the first place?
Case study example:
In a re-engineering project that we ran for an outbound call center in China, we found that different teams (Shanghai, Beijing, Chongqing, etc.) had different levels of utility and performance. For example, the team in Shanghai had a higher conversion rate and the call center resources were used 90% of the time. At the same time, the team in Chongqing had a lower conversion rate and lower utilization.
Monogon identified and re-engineered the reasons for the siloed team structure. This allowed the call center operations to be consolidated. The utility and performance of each team could now be fairly compared and optimized across the board.
Regional sales or support team structures only make sense if there is a need to visit customers physically or if there are very strong cultural reasons to do so. Otherwise: consolidate.
Automate
Now it is time to talk about automation. Prime candidates for automation are processes that are:
- Structured and repetitive such as customer communication, reporting, task management, feedback collection and scheduling. Processes that are rules-based and predictable
- Rules-based & predictable such as finance-relate back-office processes, lead dispatching, bonus calculation and reporting
So far we’ve not spoken about digitization. Having gone through elimination, simplification, standardization and consolidation, this is also the stage at which you should consider digitization and automation of a process at the same time.
Some questions to get get started:
- Can we reduce the reliance on human intervention or altogether automate this process?
- Can checks and balances be built into the system?
- Can integrations between systems avoid manual data handling and automate reporting?
Case study example:
At various clients we’ve gone through a re-engineering cycle of lead dispatching, where the outcome was always a simplified and consolidated process that could easily be automated. The automation of lead dispatching is highly rules based (e.g. lead X to market Y, lead A to available agent B), and there is no need for a human being to do this.
Not only do you save your managers from mundane tasks, you also great speed up the follow-up time from a new lead entering your system, to your agent on the phone with a potential customer.
Across various projects, we’ve seen conversion rates increase more than two-fold after automation of lead dispatching.
Self-service
Customer self-service is the cherry on top of the process re-engineering cake. Beyond automation, it is by far the best way to save time of your staff, allowing them to focus on the customer interactions that truly matter.
Some questions to get get started:
- Can the customer execute this step in the process without staff intervention?
- Will self-servicing this process empower or frustrate the customer?
- What are the risks of self-servicing this process and can we mitigate these risks?
Case study example:
Our client in the cultural exchange industry provided a flight booking service for their customers. There was extensive back-and-forth between the customer, the service team and the flight booking team using email, phone calls and questionnaires to book, rebook or cancel flights.
Monogon designed a customer-facing portal in Salesforce Experience Cloud that directly integrated the customer front-end, with CRM data and a flight booking engine. The logic for the flight booking (including budget, visa restrictions, departure and arrival gates and dates) was all managed from Salesforce.
If a process can be automated, there is a good chance it can also be self-served. Identify which customer interactions truly matter. Focus on those, and allow self-service on the rest.
