Rebuilding a Call Center During Lockdown

In the first week of joining a major Indian NBFC, I tested the call center app the team was about to ship. I spent time with the agents who were piloting it, watched them use it, and concluded that the version we were preparing to launch shouldn’t go live.

Nothing in the app was technically broken. Everything in the requirements was there. The agents could make calls. The system worked. What I couldn’t unsee was that the workflow was hostile to the agents who would have to use it six-plus taps to make a single call, the agent’s personal number exposed to customers, no way to recover context once a call connected.

I tried to raise this through normal channels. No one felt anything was wrong. The argument I was making that the app would technically launch and operationally fail wasn’t landing through design language. So I changed languages. I built presentations and mockups, translated the user experience cost into business numbers, and walked the case to the executive who owned the rural business P&L. Two weeks of pushback ended in his office, with a green light to rebuild the workflow before launch.

That conversation set the pattern for the next several months. I led the design and product direction for the system that took the company’s outbound call operations remote during the 2020 lockdown an end-to-end calling app for thousands of agents working from personal devices. The app shipped within weeks. The remote operating model it created became permanent. But the design work was never the hardest part. The hardest part was the work I’d never had to do before: selling design to an organization that didn’t yet believe it needed to.

The real problem

The brief was “build a mobile app for the call center.” That framing was wrong, and following it would have failed in fact, it almost did. The version I’d flagged in my first week was the version that framing produced: technically complete, operationally hostile, optimized for the wrong user.

The real problem was different. How do you recreate a high-volume, tightly controlled call center on personal devices, without breaking the agent behavior the business was built on?

The company had an offline DNA. The call center was a physical floor with managers walking the room, listening in, coaching in real time. Thousands of agents had been trained on a specific Salesforce-based autodialer workflow, and that muscle memory was an asset, not a problem to redesign around. The previous mobile attempt had ignored this. It asked agents to navigate a customer list, open a profile, tap into the native dialer, make the call, and return to the app to log the outcome. Six-plus taps per call, with the agent’s personal number exposed to the customer. Adoption had stalled before I joined.

Underneath the workflow problem sat harder ones. Legal and compliance constraints meant we couldn’t expose agent phone numbers, couldn’t store customer data casually, couldn’t loosen call quality monitoring just because the floor manager was no longer physically present. Leadership was skeptical the lockdown would last long enough to justify the investment. Floor managers and hiring leads whose roles depended on a physical call center had a quiet incentive to see this fail. And every day the system was down, the business was losing money on a product line that funded a significant share of customer acquisition.

The brief was “build an app.” The actual job was to design a remote operating model for a business unit, get a skeptical organization to trust it, and do both at the same time while operating inside a company where, for the first time in my career, I was going to have to argue for design as a discipline before I could practice it.

Familiarity over reinvention

The instinct in a crisis is to redesign everything. We did the opposite.

Agents had years of muscle memory on the existing autodialer workflow. They logged into Salesforce, hit available, and calls came to them one after another, no manual dialing, no decisions about who to call next. That behavior wasn’t a constraint to design around. It was the asset the business ran on. The previous mobile attempt had thrown it away in favor of a cleaner workflow that asked agents to browse, tap, and dial. Cleaner on paper, hostile in practice.

The decision we made early and defended repeatedly was that the mobile app would not introduce a new workflow. It would replicate the existing one as faithfully as possible, on a phone instead of a desktop. One tap to go available. Calls auto-routed through the company’s official numbers, so agent personal numbers stayed private. Customer details loaded automatically the moment a call connected. Six-plus taps to start a call became one. No navigation during the call itself.

The trade-off was real. We were giving up the chance to “improve” the workflow with the mobile-native patterns a fresh design might have introduced. We accepted that. The agents we needed to support weren’t going to be retrained mid-crisis, and any cognitive load we added would compound across thousands of users and millions of calls.

Two related decisions came out of the same logic. First, we stripped the customer detail screen down hard. The desktop version showed extensive customer data useful when you have a 24-inch monitor, overwhelming on a phone mid-conversation. Rather than guess what to cut, the team listened to recorded calls, identified what agents actually referenced in real conversations, and validated with the L&D team. Name, age, location, last three purchases as a count, plus a few purchase signals. Everything else went. The list itself was filtered too customers with recent EMI defaults or low credit scores were removed before agents ever saw them, so agents weren’t making judgment calls under time pressure that the system could make better upstream.

The result was counterintuitive on paper: agents made fewer calls per day than the original mobile workflow had targeted, but conversion per call went up significantly. We were optimizing the right variable.

The workshop

After the green light from the rural business head, the design problem became tractable. The organizational problem didn’t.

Work and feedback was running like a ping-pong match. I’d take a screen to one stakeholder, get changes, take it to another, get conflicting changes, take it to a third, get told “this is how it’s done here” with no further explanation. Things were getting rejected without reasons. Engineering had ruled certain features out because they assumed legal wouldn’t allow them. Legal had reservations they hadn’t fully articulated. Nobody in the chain had any incentive to help me move faster if it worked, I’d get the credit; if it failed, they’d be safe.

I’d done workshops before in previous roles, so I knew what they could do. I also knew that if I sent the invite, half the room wouldn’t show up. So I asked the group head to invite the workshop instead, and got his executive assistant to set it up. Once the invitation came from his office, attendance stopped being optional.

In the week before the workshop, my team and I met every stakeholder individually. We listened to their concerns and built a separate version of the same flow for each one engineering’s preferred screens, legal’s preferred screens, operations’ preferred screens, L&D’s preferred screens. When we walked into the workshop, we put all the versions side by side, with each stakeholder’s feedback labeled next to the version they’d shaped.

The room saw what I’d been seeing for weeks. Two of the group head’s close associates and their teams were the bottleneck on a number of decisions that weren’t actually in the company’s interest. They were holding positions out of habit, not out of analysis. The group head found it funny. They pulled back on most of those positions in the room. The temperature shifted from “I’m protecting my territory” to “I’m being seen as the obstacle,” and the second mode is much harder to maintain in front of your boss.

The legal conversation was the one I needed to win specifically. Their original position was that users had to consent to six to eight separate documents terms, privacy policy, dos and don’ts, each scrolled and acknowledged individually. The pitch I made was simple: two people on your team will work for a week on this, or thousands of users will go through eight extra steps before they can do their job, and if we get the consent flow right we can take this pattern to the company’s other apps. They agreed. It became one consolidated consent step.

The most useful output of the workshop wasn’t a list of decisions. It was a shared map of where the boundaries actually were, agreed in front of the senior person who could enforce them. We knew what we could build without re-litigating it. Engineering reversed several of their earlier rejections once they heard legal’s actual position. Legal gave us tighter and earlier guidance because they understood what we were trying to do. The monitoring system that came out of the workshop call recording, peer review, lead review, flagged keywords, an audit trail wasn’t a compliance burden bolted on at the end. It was part of the product from week one.

The trade-off was the time we spent before building. Workshops took days we felt we didn’t have. But every day we spent aligning early saved a week of rework later, and the larger thing the workshop bought us was permission to move fast for the rest of the project.

Adding friction on purpose

A few months in, the app started picking up an audience we hadn’t planned for. A content creator on YouTube had made a video claiming you could install the app, start making calls, and earn money. Sign-ups spiked. On the surface, that looked like a win.

It wasn’t. The agents this video was attracting were not the agents the system was built for. The job required talking to customers about loans, handling rejection, following call quality guidelines, and operating inside a regulated financial product. The video framed it as a side hustle. The signal-to-noise ratio of new applicants collapsed almost overnight.

The default move in this situation is to tighten the funnel quietly better filtering on the back end, more aggressive vetting in review. We did some of that. But the bigger decision was to deliberately make onboarding slower.

We extended the training before a new agent could make their first call. We made the in-app product training a real test, with content modules they had to pass and recorded sample calls they had to listen to and respond to before unlocking the dialer. We collected PAN and Aadhaar at the start, ran a CIBIL check, and tied identity to the device so anyone rejected couldn’t simply re-register from a new number. The KYC step itself became a filter applicants who weren’t serious dropped off before they ever made a call. We were fine with that. We wanted them to drop off.

The trade-off was conversion at the top of the funnel. We knowingly turned away applicants who would have signed up under a frictionless flow. In exchange, the agents who came through were the agents we wanted: people who had read the material, passed the test, and accepted the regulatory weight of the job. Quality of conversations went up. Compliance incidents stayed manageable as we scaled. The training infrastructure we built during this period modules, in-app testing, sample call libraries became permanent and was used long after the lockdown ended.

When the wrong users start showing up, friction isn’t the enemy. It’s the tool.

The leaderboard was an accident

We hadn’t planned to gamify anything. The original need was simpler: team leads couldn’t walk a floor anymore, and they needed a way to see how their agents were doing. We had limited screen real estate and limited time to build a separate management view, so we put performance data inside the same app the agents used.

The designer on my team with a gaming background showed me a leaderboard version of the screen in one of our daily design reviews. He’d built the requested version first, then made a second version because he thought there was a better way. My honest first reaction was internal: this means I’ll have to convince so many people, all over again. I didn’t say it out loud. The team was sharp enough to read me anyway.

I went with the leaderboard for two reasons. The first was that I’d seen this designer’s work on the workshop mockups a few weeks earlier when I needed multiple stakeholder versions of the same flow built fast, he’d executed cleanly under pressure. I had direct evidence he could pull this off, not just a portfolio I’d seen at hiring. The second was that I knew the lockdown wasn’t ending anytime soon. Productivity across the call center was dropping, and the curiosity a leaderboard would create agents checking the app between calls to see where they ranked was something we needed.

I was right about the pushback. Several people felt the leaderboard wasn’t worth the political capital, that the lockdown would end before any of this mattered, that the team’s bandwidth would be better spent on the consumer side of the business. I held the position. The leaderboard shipped.

The effect was immediate and disproportionate. Agents started checking the app between calls. Daily targets, total loans booked, team standings all of it became visible in a way the physical call centers had never made it. Engagement went up without us having to design for engagement.

Worth naming clearly: the insight wasn’t mine. It was a designer on my team whose background gave him a frame I didn’t have. The lesson I took from it was about hiring, not gamification people see solutions you can’t see, and your job as a lead is to make sure those solutions get heard and protected when the inevitable “is this serious enough” pushback comes.

A good decision, rolled back

Later in the project, working with the data team, we identified that a smaller, persona-targeted call list converted at significantly higher rates than the broader list. Calls dropped, conversions per agent climbed sharply, and customers who didn’t fit the loan profile stopped getting calls they hadn’t asked for. By every measure I was tracking, this was a clean win.

The feature was rolled back within weeks.

What I hadn’t fully understood was that agent and floor manager incentives were tied to call volume, not conversion. Fewer calls meant lower payouts on a structure that had been in place for years. The people closest to the decision weren’t resisting the persona logic they were responding rationally to the incentive structure they actually lived inside. I was looking at a dashboard. They were looking at their pay slips.

The feature came back online a few months later, after the incentive plan had been restructured to reward conversions rather than volume. Same product decision, different organizational ground underneath it.

I had not worked inside an incentives-driven business before this project, and it showed. The lesson wasn’t “incentives matter” that’s a slogan. It was harder than that: the work of getting design adopted includes understanding the systems that determine whether good decisions can survive contact with the organization. I’d treated that as someone else’s job. It wasn’t.

What broke

The first version was meant for a small test group a controlled rollout where we could watch behavior, fix issues, and stage the broader release. It didn’t go that way.

The APK got shared. Someone on the test list forwarded it to a WhatsApp group, and within a short window it had spread across multiple teams and beyond. People who hadn’t been onboarded, who didn’t know it was a test build, started using it as if it were the production app. Load went past what the backend was provisioned for. The system slowed, then crashed. Several training sessions had to be cancelled. Some of the early adoption goodwill we’d been building got burned.

The honest version of what happened: we should have whitelisted the build to a fixed set of devices and we didn’t. The decision to skip that step wasn’t a deep oversight it was the kind of small operational discipline that gets dropped when a team is moving fast and trusts the people on the test list to behave. The trust was reasonable. The lack of a hard control was not.

We restricted access, stabilized the backend, and rebuilt the rollout plan with proper gating. The system recovered within days. But the timing cost us those were days early in adoption when we were trying to demonstrate to skeptical leadership that the app could handle real load, and the first thing leadership saw was the app failing under load.

The lesson I took was specific, not generic. Speed and discipline aren’t opposites, but under pressure they feel like they are, and the discipline is the part that gets cut. The fix isn’t to slow down. It’s to identify the two or three controls that actually matter and refuse to ship without them, even when nothing has gone wrong yet.

What it became

The app shipped within weeks of the project starting and carried the company’s outbound call operations through the lockdown. That was the goal it was built for. What’s worth saying more carefully is what happened after.

The system didn’t get rolled back when retail reopened. The remote operating model agents working from home on personal devices, calls routed through official numbers, real-time monitoring built into the product became a permanent part of how that line of business ran. Several elements that started as crisis workarounds turned out to be better than what they replaced. The training infrastructure we built to filter applicants during the YouTube-driven sign-up surge stayed in place and became the standard onboarding path. The call quality monitoring system, designed alongside legal in the first weeks, replaced parts of the older floor-based supervision model. The leaderboards a designer suggested in a daily review became a permanent fixture of how teams tracked themselves.

Adoption scaled past what we’d planned for, more than once. Persona-based targeting came back online after the incentive restructuring and lifted conversion per agent meaningfully. The referral program we’d added to compensate for closed college hiring channels turned into a real recruiting funnel.

The less visible outcome was inside the organization itself. The argument I’d had to make in week one that user experience was worth a redesign even when the app already technically worked became easier to make in the projects that followed. The workshop pattern stuck. Legal stayed in the room earlier than they used to. Engineering stopped pre-emptively rejecting features on assumed compliance grounds. None of this was formal. It was the kind of cultural shift that happens when one project shows the cost of working a different way and other teams start copying the parts that worked.

I’m being deliberately careful with numbers in this writeup this was an NBFC, and the specifics are confidential. But the qualitative shape is this: a project built to keep an offline business running during a crisis became a piece of how that business worked afterward. The lockdown ended. The system stayed. And the way design fit into the company shifted, slightly, in a direction it hadn’t been moving before.

What I’d say in hindsight

Two things, looking back.

The first is that I came into this project as a designer and finished it as a product owner, and the gap between those two roles was wider than I’d understood going in. I didn’t know the business when I started. I was learning how an NBFC actually made money, how an incentive-driven sales organization worked, how legal and compliance fit into a regulated product, all while making decisions that the business couldn’t afford to wait on. The persona rollback was the most visible cost of that learning curve, but it wasn’t the only one. I missed the incentive question because I was reasoning about the product, not the system the product lived inside. I think I’d notice that earlier today, but I’d be wary of any version of myself that claimed I’d notice it every time. Some of these lessons are situation-specific, and humility about that is part of what I took from the project.

The second is more concrete. If I ran this project again, I would invest earlier in two things I undervalued the first time: rollout discipline and incentive mapping. Rollout discipline because the APK leak cost us political capital we didn’t need to spend, and the fix would have been a half-day of process. Incentive mapping because most of the resistance we hit from floor managers, from agents, from regional leads was rational once you understood the incentive structure people were working inside, and we could have predicted and addressed it instead of discovering it in real time. Neither of these is a design skill in the conventional sense. Both are the kind of thing the role I was actually doing required.

The larger thing I took from the project, though, sits underneath both of those. I came into this organization expecting to do the work of design. I learned that in a company that hadn’t yet decided design was a discipline, the work of design includes the work of arguing for it at the start of every project, with every stakeholder, in the language they actually use. The two-week pushback in week one wasn’t a detour from the project. It was the project, in microcosm. Everything that followed the workshop, the legal pitch, the rollback, the leaderboard pushback I held against was a variation on the same task: making design legible to an organization that hadn’t yet seen what it was for.

I notice now that this pattern shows up in smaller ways in how I work. When something goes wrong, I write the lesson into the team’s guidelines so the next person doesn’t have to learn it from scratch. When a stakeholder makes a request that’s actually a request for trust, I try to answer the trust question first. When a teammate sees something I don’t, I try to back them publicly even when it costs me politically. None of these are dramatic. They’re the kind of habits that accumulate into how a person actually leads.

The honest summary: the project worked, the system stayed, and I came out of it a different practitioner than I went in.