Why Did This Phase Become Important?

In Phase 1, we moved the problem from the level of “ticket volume and churn” to Customer Health. By defining risk signals and analyzing customer behavior, we found that some customers entered a high-risk state very early after purchase—not necessarily because of a technical issue, but because they had not properly set up the product, were unfamiliar with its core capabilities, or had not yet experienced its value in their day-to-day work.

This raised an important question:

If customers fail to reach meaningful product usage during the first few weeks and months, can better education and more accessible content prevent Churn?

At that stage, our initial hypothesis was that a significant portion of training-related tickets and some Churn were caused by insufficient training. We therefore decided to design a focused intervention across Onboarding, Education, and Self-Service before making major product changes, and measure its impact.

Hypothesis

If customers, at the beginning of their journey:

• can set up the product faster;

• have a clear learning path;

• have accessible content for core capabilities;

• and do not need to contact Support to solve simple issues;

we should be able to:

1. Reduce the time it takes customers to reach meaningful product usage;

2. Reduce training-related support tickets;

3. Reduce dependency on Support;

4. Ultimately reduce Churn associated with low perceived value or low product usage.

For this reason, we did not view the solution simply as “creating a few videos.” Instead, we examined the entire customer journey from installation to learning and support.

What Did We Change?

01 — Simplifying Setup and Installation

At the beginning of the journey, both customers and Support spent significant time and effort on installation and system setup. We therefore simplified the installation process through an Installer, allowing customers to complete the initial steps with less dependency on technical staff.

However, during implementation, we realized that simplifying installation alone was not enough. A customer could successfully install the product and still not know where to start, which capabilities mattered most, or how to incorporate the product into their daily business workflow.

This shifted our focus from “successful installation” to “successful product adoption.”

02 — Designing Initial Training

We designed initial training for new customers to move learning away from scattered, expert-dependent explanations toward a more structured learning journey.

Instead of simply presenting a list of features, we focused the training on the tasks customers actually needed during their first days:

• Getting familiar with the product environment

• Performing basic actions

• Setting up essential capabilities

• Learning frequently used workflows

• Understanding which business problems the product actually solves

This was an important distinction because we realized that teaching a feature is not the same as helping a customer reach value.

03 — Post-Onboarding Follow-Up

We did not limit training to the first session or first day. Follow-up and additional training were provided after customers started using the product to determine whether they had actually adopted it or had simply completed the installation and training process.

We distinguished between three different situations:

• The customer has installed the product but is not using it;

• The customer is using the product but is blocked by a specific capability;

• The customer has not reached product value and does not yet understand why they should continue using it.

This distinction helped us understand that not every customer problem could be solved with generic educational content.

04 — Creating Educational Content for Different Capabilities

We created educational videos for frequently used capabilities and topics that generated the highest volume of questions. The goal was to allow customers to find relevant answers when needed instead of contacting Support for every simple question.

To make the content easier to consume and reduce dependence on live instruction:

• Videos were kept short and topic-specific;

• Separate content was created for specific capabilities;

• Subtitles were added;

• Content was placed closer to the points in the journey where customers were likely to need it.

05 — Clarifying Printer Setup

Printer setup was one of the areas where customers had significant dependency on Support. We moved this process away from ad-hoc verbal instructions toward a more structured flow, making it clear:

• What prerequisites were required;

• What the setup steps were;

• What errors could occur at each stage;

• Where to get help if something went wrong.

06 — Testing a Chatbot and Routing Customers to Relevant Content

We experimented with a Chatbot to explore the potential for automating customer support. The goal was not simply to answer questions, but to determine whether we could guide customers from their initial question to the right content, relevant training, or an appropriate troubleshooting path.

The experiment showed that simply introducing a new support channel was not enough. If customers could not get a reliable and relevant answer, they quickly returned to the familiar channel: contacting Support.

07 — Aligning Support and the Contact Center

To ensure that Self-Service was not limited to the product itself, Support and Contact Center teams were also trained to direct customers to relevant content during support interactions.

The goal was not to prevent customers from receiving help. Instead, we wanted to:

• Resolve simple issues through appropriate content;

• Prevent customers from entering a lengthy support process for minor questions;

• Encourage customers to build the habit of using Self-Service resources.

Outcome

At first glance, the initial reduction in training-related tickets could have been interpreted as a success. However, when we looked at a longer time horizon, we found that the reduction was not sustained.

Customers used the content when they first started, but when they encountered new problems, they continued to choose Support as their preferred channel.

This led us to move beyond metrics such as video views or short-term ticket reduction and ask a more important question:

Did customers actually change their behavior and become more independent after receiving the training?

Over the 4–6 month period, the answer was largely no.

Key Learning

The problem was not simply “customers were not trained.”

Training does not necessarily lead to product adoption, Self-Service, or perceived value.

A customer might watch a video, but that did not necessarily mean they would:

• Use the capability in their daily workflow;

• Find the answer independently the next time they encountered a problem;

• Or better understand the value of the product.

We therefore identified an important distinction between:

Receiving Training ≠ Using a Capability ≠ Experiencing Product Value

This distinction changed how we analyzed the problem.

We realized that if customers still depended on Support to find capabilities, understand workflows, or solve simple problems, the issue was not necessarily a lack of content. It could also stem from:

• Poor discoverability of capabilities;

• Complex workflows;

• Unclear copy and guidance;

• A gap between educational content and real customer scenarios;

• Or low perceived product value.

As a result, instead of simply producing more content, we began looking at the problem at the product experience level:

If customers need continuous training to use the product, perhaps part of the problem should be solved within the product itself—not through more educational content.

Connection to the Next Phase

This phase produced two important insights for the next stage.

First, we learned that reducing Support pressure cannot be achieved through more training alone. Processes need to be designed so customers can identify and resolve more issues independently.

Second, we realized that not all customers and not all Churn cases have equal value. Some customers would not be retained even with more training and follow-up because they lacked sufficient economic value or product fit. Therefore, preventing every instance of Churn was neither realistic nor necessarily the right business decision.

The focus therefore shifted from:

Preventing all Churn through more training and follow-up

to:

Identifying valuable customers, preventing their Churn, and designing a scalable Support model.

This became the bridge to the next phase. Instead of asking only “How can we help the customer?”, we began asking:

Which problems should be solved through education, which should be eliminated through product design, which can be automated, and which customers are actually worth intervening for?

This perspective led us to examine the broader Support ecosystem in the next phase—including installation, training, updates, renewals, and service activation—as one connected system.

03 — Preparing Support for Growth Without Proportional Headcount Increase

As the business strategy evolved, a new challenge emerged:

If the number of stores grows fourfold, does Support also need to grow fourfold?

Business Goal

Analysis of Support processes showed that the bottlenecks were not limited to ticket volume:

Installation · Training · Updates · Renewals · Online Service Activation

Installation: From Simplifying the Installer to Redesigning the Entire Process

Initially, an Installer had been created to guide users through the installation process in a few simple steps.

But an important question emerged:

If the installation process has been simplified, why hasn’t installation capacity increased accordingly?

Current-State Analysis

I broke down the installation process into individual stages and analyzed where time was actually being consumed.

On average, installation took approximately 1.5 hours for ready systems and around 4 hours for problematic systems.

However, the issue was not only installation time. A significant portion of Support capacity was also spent on locating customers, coordination, troubleshooting, and routing each issue to the appropriate specialist.

Solution: Pre-Installation + Installation + Exception Management

Instead of simply making the Installer faster, we divided the process into multiple stages.

01 — System Readiness Check

Before installation started, the system was checked for:

• Windows version;

• Available disk space;

• Partition status;

• Required installation conditions.

02 — Installation Without Specialist Support

If the system was ready:

Download → Install → Activate

No remote access from a specialist was required.

03 — Problem Detection & Logging

If a problem occurred, the Installer identified the issue and reported it to Support.

For example:

• Windows issue;

• Insufficient disk space;

• Partition issue;

• Installation failure;

• Unknown error.

In the initial version, users only saw an error message. In the new version, in addition to detecting and logging the issue, short instructional videos were embedded directly on the relevant screen for selected errors.

From Showing Errors to Solving Problems

Some problems were not simply reported—the system could also resolve parts of them.

The flow therefore moved from:

Error → Contact Support

toward:

Detection → Guidance → Customer Resolution → Issue Logging → Escalation

Installation Process Management Dashboard

Once the major error types had been identified, we designed a Dashboard for managing the installation process.

The Support manager could see the status of all cases, while each specialist could view only the cases relevant to them.

This prevented every request from entering the same queue.

Issue Detection → Ownership Assignment → Follow-Up

Solving One Bottleneck Revealed the Next

One of the most important learnings from this stage was:

Simplifying one step does not necessarily increase the capacity of the entire process.

The previous Installer had simplified the installation process, but installation capacity had not increased as expected.

The process analysis revealed two major remaining bottlenecks:

1. Finding and coordinating with the customer;

2. Systems that were not ready before installation began.

The problem therefore shifted from “installing the software” to “making the system ready for installation.”

Reducing Dependency on Specialized Staff

For customers with ready systems, specialized Support staff were no longer required to participate in the installation process.

The new flow became:

Sales → SMS & Notification → Pre-Installation → Installation → Activation

Only problematic cases were routed to the specialist team.

Simple follow-ups were also handled by Tier-1 / Contact Center staff, allowing specialists to focus their time on more complex issues.

As a result, the role of Support shifted from:

Executing every installation step

to:

Managing and resolving exceptions

An Example of Data Analysis

During the installation process analysis, approximately 29% of installations fell into the problematic-installation category.

Therefore, the objective was not simply to reduce installation time. The primary goal was to identify problematic cases before they consumed specialist capacity.

Training: The Next Bottleneck

Ticket analysis showed that a significant portion of Support requests were educational in nature.

Instead of treating all of them the same way, we categorized requests based on the nature of the problem:

This approach helped us identify that some issues previously classified as “Support tickets” were actually “Product problems.”

Overall Outcome