How I Improved Customer Satisfaction from 78% to 96% by Transforming Technical Support Operations
An operational transformation case study from my time leading Technical Support at Pagefreezer.
Company: Pagefreezer
Role: Manager, Technical Support
Period: April 2022 – September 2024
The Results
Within nine months of taking over Technical Support at Pagefreezer, we achieved several measurable improvements:
-
Customer Satisfaction (CSAT): Increased from 3.90/5 (78%) to 4.78/5 (approximately 96%).
-
Resolution Time: Reduced by approximately 33%, from six days to four days on average.
-
Sustained Performance: Maintained CSAT at approximately 94–96% through September 2024.
-
Technical Independence: Reduced reliance on Engineering by expanding Support’s troubleshooting capabilities.
These improvements weren’t the result of a new support platform, additional headcount, or a major technology investment.
They came from addressing operational weaknesses, improving collaboration, investing in employee development, and creating a culture of accountability.
The Challenge: A Capable Team Constrained by Its Processes
When I joined Pagefreezer in April 2022, customer satisfaction averaged approximately 3.90 out of 5.
The Technical Support team supported three distinct product areas: Web Archive/Capture, Social Media Capture, and Web Preserver, a Chrome browser extension.
Through individual conversations with team members and a review of our Jira ticket backlog, I identified several problems.
Knowledge was concentrated in silos. Engineers had developed expertise in specific products but weren’t always comfortable troubleshooting issues outside their specialties.
Ticket ownership was inconsistent. Engineers could select their own tickets, which meant more complex issues were sometimes left for senior colleagues. When an engineer was absent, their assigned tickets could sit untouched for days or even weeks.
Escalations were frequently delayed. Tickets sent to Engineering or Product sometimes lacked sufficient technical information for investigation. These incomplete escalations competed against existing development commitments and could remain unresolved.
Service levels weren’t actively managed. Although customer SLAs existed, the team lacked consistent monitoring and escalation processes.
Operational visibility was limited. Regular backlog analysis, ticket aging reports, and company-wide performance dashboards weren’t established.
The underlying problem wasn’t a lack of commitment from the Support engineers.
In fact, the team recognized many of these issues and wanted things to improve. What they needed was the structure, support, and leadership to make those improvements possible.
1. Creating Accountability Through Structured Ticket Ownership
One of the first changes I introduced was replacing self-selected tickets with a first-in, first-out (FIFO) assignment process.
Instead of engineers choosing which issues they wanted to investigate, tickets were routed to individuals.
Every engineer was expected to take ownership of assigned work, even when the issue fell outside their primary area of expertise.
We also established a simple operational rule: no ticket should remain unassigned at the end of the day.
At minimum, customers needed acknowledgment that we had received their request and understood the problem they were reporting.
This helped address two challenges simultaneously: tickets being overlooked and customers being left without communication.
2. Breaking Down Knowledge Silos Through Practical Cross-Training
Traditional training programs often involve lengthy presentations or generic product demonstrations.
I wanted something more practical.
We introduced recurring knowledge-sharing sessions where Support engineers walked their colleagues through actual tickets they had investigated.
Each presentation focused on a challenging issue, the troubleshooting process, and how the engineer reached a resolution.
These sessions didn’t need to last hours. Sometimes thirty minutes was enough to share valuable knowledge.
We extended the approach to Engineering, arranging monthly sessions where engineers explained complex tickets that Support had escalated.
I also arranged Git repository access for the Support team, allowing engineers to better understand the applications they supported and strengthen their investigative capabilities.
Over time, this increased technical confidence and helped the team resolve more issues independently.
Rather than escalating problems simply because they were unfamiliar, engineers could investigate more thoroughly and determine whether Engineering intervention was genuinely required.
3. Improving Cross-Functional Escalation Processes
One of the more significant operational bottlenecks existed between Support, Engineering, and Product.
Support engineers were escalating issues without always providing the information needed for effective investigation.
Engineering and Product teams, meanwhile, were managing their own sprint commitments and often couldn’t prioritize incomplete support requests.
I met with the relevant teams to understand their expectations and identify the information they needed before accepting an escalation.
Together, we introduced standardized Jira templates defining the technical details required for each type of escalation.
This reduced ambiguity and improved the quality of information Engineering received.
However, better documentation alone didn’t solve the prioritization challenge.
I worked with Engineering and Product Managers and their Scrum Masters to establish a process for including approximately one or two Support escalations in each sprint.
This gave Support a more predictable path for addressing issues requiring development expertise.
The objective wasn’t to force Engineering to abandon planned work. It was to establish a collaborative process that recognized customer-facing technical issues as part of the organization’s operational priorities.
4. Making Performance Visible Throughout the Organization
Before these changes, Support performance wasn’t being measured or shared consistently.
I introduced Jira dashboards tracking:
-
First-response times
-
Ticket aging and backlog
-
SLA compliance
-
Individual engineer performance
-
Customer satisfaction
These dashboards were accessible throughout the company, creating greater transparency into Support’s workload and performance.
I reviewed backlog reports daily and used the information to identify problems requiring attention.
Individual performance reporting also became part of our regular conversations.
Importantly, I didn’t want engineers to feel that dashboards existed simply to monitor them.
Technical Support engineers are skilled professionals. My goal was to give them visibility into their performance, help them recognize opportunities for improvement, and provide coaching when needed.
Metrics became a tool for improving performance rather than an end in themselves.
5. Improving Customer Communication
One of the clearest findings from the initial review was that customers sometimes waited far too long for updates.
Even when engineers were actively investigating a complex problem, customers didn’t necessarily know what was happening.
We introduced clearer expectations for communicating with customers.
For complex tickets with an estimated resolution timeline, engineers were expected to provide proactive updates at approximately 50% and 75% of that period.
For example, if an issue was expected to take five days to resolve, the customer would receive progress updates before the estimated completion date.
The principle was straightforward: customers shouldn’t have to chase Support to find out what’s happening with their issues.
We couldn’t always resolve technical problems as quickly as customers wanted, but we could communicate consistently and manage expectations.
6. Strengthening Customer Satisfaction Measurement
Jira already provided an optional customer satisfaction question associated with support tickets.
However, relying entirely on customers voluntarily completing those surveys limited the feedback available to us.
I introduced a supplementary process that involved contacting a random selection of customers who hadn’t completed the Jira survey.
Approximately 50 nonresponding ticket creators were contacted each week and invited to provide feedback using the same satisfaction questions and rating scale.
The results were combined using a consistent calculation methodology and included in our company-wide reporting.
Across approximately 300 monthly tickets, we collected an estimated 100–150 customer satisfaction responses through the combined feedback channels.
This provided a broader picture of the customer experience.
We also shared positive customer feedback and commendations during our semi-monthly company-wide Parleys.
Negative feedback was reviewed to identify possible operational improvements, while recognizing that some dissatisfaction related to matters outside Support’s direct control, such as pricing.
Customer feedback became an ongoing source of learning rather than simply another number on a dashboard.
7. Developing People, Not Just Improving Processes
An operational transformation is difficult to sustain if employees don’t feel invested in the changes.
Fortunately, the Pagefreezer Support team was receptive from the beginning.
The engineers recognized the challenges and welcomed improvements that made their work more effective.
I also changed the focus of our one-on-one meetings.
Previously, these conversations had largely revolved around technical updates.
I wanted them to focus on the individual: coaching, mentoring, career development, training opportunities, and professional goals.
For example, one engineer was interested in moving into software development, while another wanted to pursue security operations.
I supported relevant training and worked with managers in other departments to arrange shadowing opportunities.
I also worked with the CTO and VP of HR on a proposed Senior Support Engineer role to provide formal recognition and a career progression path for engineers already performing senior-level responsibilities.
Although that initiative hadn’t reached implementation before my departure, it reflected a broader objective: recognizing and developing the technical expertise that already existed within the team.
The Outcome: Sustainable Performance Improvement
Customer satisfaction began improving shortly after the operational changes were introduced.
By January 2023, approximately nine months after I assumed responsibility for the department, CSAT had increased from 3.90 to approximately 4.78 out of 5.
Expressed as a normalized percentage, that represented an improvement from 78% to approximately 96%.
The improvement wasn’t temporary.
CSAT remained around 94–96% through the remainder of my tenure, finishing at approximately 96% when I left in September 2024.
Average ticket resolution time also decreased from approximately six days to four days, a reduction of roughly 33%.
Cross-training, broader technical knowledge, and stronger ticket ownership helped the team troubleshoot more effectively and reduced its dependency on Engineering.
Meanwhile, improved documentation and proactive communication strengthened our working relationship with Customer Success.
Support began providing more detailed information in the CRM and proactively informing Customer Success leadership about significant customer issues.
These changes helped Customer Success better understand technical issues and prepare for customer conversations, including Quarterly Business Reviews.
Beyond the Numbers: Giving Support a Seat at the Table
One of the most rewarding outcomes wasn’t reflected in a dashboard.
As performance improved, I felt that Technical Support gained greater credibility within Pagefreezer.
Collaboration with Engineering, Product, and Customer Success became stronger.
Support wasn’t simply the team that received customer complaints and passed technical problems to someone else.
It was becoming a more confident, technically capable, and collaborative part of the business.
Perhaps most importantly, the engineers took pride in the improvements.
The processes didn’t require constant enforcement because the team could see the results of its work.
Accountability became part of how the team operated.
What This Experience Taught Me About Leadership
My time at Pagefreezer reinforced something important about the kind of work I find most fulfilling.
I enjoy building and transforming operations.
I like understanding why something isn’t working, identifying the underlying challenges, and working with people to create solutions that make a lasting difference.
Pagefreezer gave me an opportunity to do that.
Looking back, the most rewarding achievement wasn’t simply increasing customer satisfaction from 78% to 96%.
It was watching a capable team develop greater confidence, take ownership of its performance, and become recognized for the value it contributed to the organization.
Sustainable operational improvement isn’t just about introducing better processes. It’s about creating an environment where people have the knowledge, tools, confidence, and ownership to succeed.
That’s the approach I bring to customer support and customer operations leadership.
Mohamed Bhimji is a Customer Support and Customer Operations leader with experience in technical support transformation, service delivery, contact centre operations, process improvement, and team development.
Connect: contact@mohamedbhimji.com
Website: mohamedbhimji.com