Bhanzu Customer Lifecycle Management Tool

I led the design of CLM (Customer Lifecycle Management), the in-house support platform that replaced Zendesk at Bhanzu. CLM gives every paying student one Customer Lifecycle Manager, recognises callers through the IVR, and routes each ticket to the right person before anyone answers. The platform handled around 500 to 600 tickets a day. Every paying student got one point of contact, and every ticket got a category, an owner and an SLA. The scope covered IVR-based routing, the ticket workspace, root and child tickets, status flows, batch and session tools, role-based dashboards and access states.

Before CLM, Bhanzu handled support on Zendesk, where any agent could pick up any call. A student or parent who called back about the same issue usually reached a different person and had to explain it again. Until the issue was resolved, every call started from zero.

The business wanted to put its existing, paying students first, give them better service and bring refund requests down. The CTO and two product managers raised the change, and I joined those conversations as the user research lead. The decision was to give every paying student one Customer Lifecycle Manager (CLM) as their single point of contact, and to build a platform around that role.

Support handled around 500 to 600 tickets a day (approximate). A separate floor of around 20 to 25 operations agents handled them, and all of them were to move onto CLM.

Research was the largest part of this project. Before designing anything, I spoke to every operations executive and to the operations team lead. I wanted to understand how each workflow ran in Zendesk, how the teams communicated with students and parents, and what moving all of it to a new platform would mean for them.

I ran one-to-one calls with each operations executive, then a separate session with the operations team lead. Each executive owned a different part of the student's journey, so together the calls covered every part of how a student was supported.

With each executive, I walked through their work step by step:

Across all four functions, the picture was the same. Queries were handled in Zendesk alongside personal notes and several Excel sheets. Tickets had no category, there was no time limit for resolving a query, and nothing alerted the team lead when tickets stayed unresolved.

I also mapped every channel a conversation ran through: email, WhatsApp and the direct call line. No single place showed a student's conversation across all three.

I then spoke with the operations team lead about the team as a whole. I asked:

He told me he had little to no visibility. He needed to see how many tickets were breaching, have tickets escalate when they stayed open past a set time, and know which CLM was responsible so he could follow up with them.

The CLMs and agents needed two things urgently. First, to see the tickets assigned to them as soon as they logged in. Second, to see what was urgent: the SLA time left, and how many tickets were breached, pending, on track and due to close that day.

To understand how similar platforms handle support, I reviewed Zendesk alternatives: Freshdesk from Freshworks, Intercom and Zoho Desk. I looked at how each one routes and assigns tickets, shows SLAs, and keeps conversations from different channels on the ticket.

All three are built for general support teams. None of them came with Bhanzu's own student data, such as course, batch and refund eligibility. CLM needed that data on every ticket, so it had to be built around Bhanzu's own systems.

For every workflow, I mapped how it ran in Zendesk and what it would need to become on the new platform. This mapping became the brief for the design.

The work split into two problems: getting each call to the right owner, and giving that owner what they needed to resolve it.

The system had to identify the caller and decide where the ticket goes before an agent picked up. An existing, paying student should reach their own CLM. A new or unrecognised caller should go to the support or inquiry team. Zendesk could not make that decision because it did not hold Bhanzu's customer data.

This meant designing the routing decision itself, not only the screens before and after it. The ticket had to carry its source, category and SLA from the moment it was created.

Once a ticket reached a CLM, they needed the whole customer, not a support form. That meant the student's personal details, parents, siblings, course, batch, sessions, refund eligibility, support history, parent-teacher meetings and assessments. All of it had to be workable on one screen, within a two-hour SLA.

Shown all at once, that data is unusable. The challenge was deciding what an agent sees first, what they open on demand, and what stays in the background.

A CLM also could not resolve everything alone. Refunds, batch changes and onboarding sat with other teams. The CLM needed a way to hand that work over without losing ownership of the student.

Design a support platform that gives every paying student one point of contact. It had to identify the caller, route each ticket to the right owner, and give that owner enough context to resolve it within the SLA, pulling in other teams when needed. It also had to give team leaders and leadership visibility over load and performance.

The business goals behind it were better service for existing students and fewer refund requests.

The CLM role was new. The business had decided that every paying student would get a Customer Lifecycle Manager, but nobody had yet defined what a CLM's day looked like, how tickets would be sorted, or what counted as urgent. Before I could design the platform, I had to answer those questions with the operations team.

The routing flow answered the second question. The system identifies the caller through the IVR and sends the ticket to the student's CLM or to the support or inquiry team before an agent answers.

When a query needs another team, the CLM does not hand the student over. The ticket stays with the CLM as the root ticket, and the CLM creates child tickets for the teams that can resolve each part. The student keeps one point of contact throughout.

I ran the project in sprints and led a cross-functional team of designers, engineers, product managers, support operations and operations staff.

The work ran in sprints over nine months. Discovery came first: I planned and ran the calls with every operations executive and the operations team lead, and mapped their processes, channels and pain points. In Sprint 1, I designed the wireframes, the structure and the core flows myself, including routing and the ticket workspace.

The next phase covered the role-based dashboards, the SLA cards and the status flows, where I designed the SLA cards and the filtering. The last phase was the engineering build. I agreed the version 1 scope with the product managers and engineers, and moved the ticket journey to its own page.

The team brainstormed together, then I designed the wireframes, the structure and the core flows myself. That includes the CLM ticket workspace, where the ticket lands after routing. I assigned work across the three designers and decided what would be prototyped and how. The designers built the prototypes.

I brought the operations executives and the team lead into the sprints. The people who would use CLM every day reviewed the work and gave feedback as it was built, rather than seeing it for the first time at launch.

With 20 to 25 engineers and two product managers on the project, scope had to be agreed, not handed over. The clearest example was the ticket journey. I proposed showing it in expandable rows on the dashboard. The product managers and engineers pushed back on the complexity for version 1, and we agreed to give it its own ticket details page and plan the expandable rows for version 2 (decision 8).

The design had to work within the support operation, the data that existed, and what engineering could build in the first release.

CLM is not a set of screens for one user. It connects a caller, a routing system, a new role, several operations teams and their leads. I designed it as one ticket model that every role works from, with access rules deciding what each role can see and do. That kept every role looking at the same ticket, instead of separate tools drifting out of sync.

The CLM's core user flow is the ticket journey. From the moment a ticket is assigned to the moment it closes, every step happens on the ticket page.

The IVR call is the main entry point. Other teams receive work as child tickets created by a CLM.

Eight decisions shaped the platform.

I first explored a standard dashboard layout with a fixed left navigation, where CLMs would switch between tabs for the CLM dashboard, student data and other sections. I rejected it after looking at what a CLM does day to day. Everything a CLM works on is a ticket: the call and its duration, who it is with, what the query is, the earlier conversation and the communication log. A CLM only needs student data when a ticket is about it, so a separate tab for it would rarely be opened.

So I made the ticket the centre of the platform. Each ticket ID opens a page that holds everything about it: the root and child tickets, the conversation before and after, the logs and the student's details. A CLM goes from picking up a live ticket to closing it without leaving that page.

I split the customer record into three levels by how often an agent needed it on a call.

I placed a communication rail next to the ticket with three views: Ticket Comms, Activity Log and Ticket Timeline. Ticket Comms holds the WhatsApp thread, messages and call recordings with playback, so an agent never leaves the ticket to check what was said.

Ticket Timeline shows the root ticket and every child ticket under it, with the team each one went to. A CLM handling a repeat issue sees its full history in one place, instead of starting from zero.

A ticket moves through Open, Pending, Follow up and Paused, and is closed separately with a disposition and a closing comment. I designed each status change as its own flow rather than a label switch. Pausing, for example, asks for a resume date and a description.

CLMs, team leaders, other teams and leadership work from the same data but need different screens. I designed role-based views over one shared model instead of separate tools, with access rules defining what each role sees. I also designed the blocked-access state (403) for when a user reaches for something outside their role.

Discovery gave me two clear needs. CLMs had to see the tickets assigned to them as soon as they logged in, and they had to see what was urgent. That meant the SLA time left, and how many tickets were breached, pending, on track and due to close that day.

My first version used small filter icons in every column header of the ticket table. I replaced them with four SLA cards at the top of the dashboard: Breached, Due in 2 hrs, Due in 24 hrs and Delayed by 72 hrs. Each card shows a count, breached tickets show in red, and clicking a card filters the table to those tickets. Urgent work became visible at a glance and one click away, instead of sitting behind small icons.

I proposed expandable rows on the CLM home dashboard. Expanding a row would show the ticket's full journey: when it opened and closed, who it was assigned to along the way, its child tickets, and the teams they went to. A CLM could track every ticket without opening it.

The product managers felt it added complexity, and engineering pushed back because it made the version 1 front end harder to build. We agreed to move it to version 2. For version 1, the ticket journey moved to its own page. Clicking a ticket ID opens the ticket details page, with the ticket details, student details, ticket comms, ticket timeline and the assignee's details in one place.

The final structure gives each role its own home, and every CLM ticket opens into one ticket details page. It follows from decision 1: the CLM's work lives inside the ticket, not across tabs.

The shipped platform follows the CLM's day: the dashboard, the ticket details page, the status flows, and the batch and session tools that sit inside the ticket.

The dashboard opens on the CLM's own tickets. Four SLA cards sit at the top: Breached, Due in 2 hrs, Due in 24 hrs and Delayed by 72 hrs. Breached shows in red, and clicking a card filters the table. Tabs split the work into My Tickets, Other Teams Tickets, Closed and Paused, and root and child tickets sit in the same list.

Clicking a ticket ID opens the ticket details page. I designed this page myself, from wireframe to final layout. The header carries the essentials, the action tabs sit above the student record, and the conversation sits on the right.

Behind the collapsed sections is the full record a CLM might need on a call: refunds, support history, parent-teacher meetings and assessments, each opened only when the query is about it.

A ticket moves between Open, Pending, Follow up and Paused. Each change is its own small flow: pausing a ticket asks for a resume date and a description, so a paused ticket always has a date to come back to. Closing is separate, through the Close Ticket tab, with a disposition and a closing comment. Every change is recorded in the activity log, and the ticket timeline shows the root ticket and its child tickets.

Batch allocation was one of the functions that sat with its own operations executive, worked across Zendesk and Excel. On CLM, a student's batch is allocated or reallocated from the Batch Details section, and catch-up sessions are created against the trainer's calendar from Session Details, without leaving the ticket.

Each role sees only what it needs. When a user opens a page outside their role, they see a designed blocked-access state instead of a dead end.

Testing ran inside the sprints. The operations executives and the team lead reviewed the designs and the prototypes as they were built, and their feedback went into the next round. I decided which flows to prototype and how, and the designers on my team built the prototypes.

CLM changed how Bhanzu's support worked, from who answers a call to how a team lead sees what is breaching.

The goals behind CLM were one point of contact for every paying student, a two-hour SLA on every ticket, and fewer refund requests from existing students. The platform delivered the first two by design. I do not have refund figures from after launch, which is why measurement is the first point in my reflection.