Nobody tells you what you’re actually getting into.
The business case is always clean. You build a model that shows coverage hours extending to 24/7, labour costs dropping, and queue volumes distributing neatly across time zones. The spreadsheet is convincing. The board approves it. And then you get on a plane to Bangalore and realize that the spreadsheet missed about forty things that matter.
I built our offshore support operation in Bangalore during my time at Johnson Controls International, where I was running a global technical support team of 160 people from 2013 to 2018. The decision to go offshore was driven by the classic combination of cost pressure and coverage hours — we needed 24/7 operations and we needed to manage the budget to do it. What we got was all of that, and considerably more than we bargained for.
This is an honest account of what actually happened — the operational realities, the cultural dynamics, the things that took longer than the plan said they would, and the things nobody had warned us about.
(Note: I later built a nearshore operation at Q4 Inc, which had its own dynamics and deserves its own post. I’ll cover that separately.)
Bangalore Is Not What You Expect — In Every Direction
If you’ve never been to India, your mental model is probably wrong. Mine was.
The poverty is real and visible in a way that’s genuinely difficult for a Westerner to process. You drive from the airport through streets where the contrast between deprivation and gleaming tech campuses is stark and constant. I remember the colleague who joined me from Europe on the initial setup trip — someone who travelled constantly and considered himself unsurprisable — turning to me after the first day and saying he had no frame of reference for what he was seeing. He wasn’t wrong. The locals seem to navigate it as part of daily life in a way that takes time to understand. It’s something you just have to witness, and you don’t really adjust to it as much as you learn to hold it alongside everything else.
What also catches you off guard is the other side of it. The hotels in Bangalore are genuinely among the best I’ve stayed in anywhere in the world — seven-star is not an exaggeration for some properties. The food is exceptional. The people are extraordinarily warm and welcoming. The city is vibrant, constantly moving, never quiet. It’s one of the world’s great tech cities and it operates at a pace and energy that can feel exhausting and electric at the same time.
Practical note: be careful with the water. Everything else is fine.
I mention all of this not to make this a travel piece but because understanding the context of where your team is working shapes every operational decision you make. This is not a satellite office in a comparable city. It is a fundamentally different operating environment, and you need to arrive with that understanding rather than developing it after you’ve already committed to a model.
The Talent Is Real — But So Are the Cultural Dynamics
The people we hired in Bangalore were genuinely exceptional. Smart, adaptable, willing to take on any task you put in front of them, enthusiastic about growth. On pure capability, they were as strong as any team I’ve hired anywhere.
The cultural dynamic that took the most adjustment was around commitment. The tendency to agree, to say yes, to indicate that something was understood or underway — even when it wasn’t fully understood or hadn’t fully started — is not unique to India, but it’s pronounced enough that you have to build your management processes around it rather than hoping it’ll change.
What I mean practically: you cannot manage this team to outcomes and check in monthly. You need to be in the weeds, consistently verifying that what was agreed is actually happening, resetting expectations when it isn’t, and doing so without making people feel caught out — because that’s not what’s happening. It’s a communication style difference, not a performance problem. The instinct is to give you what you want to hear. Your job as a leader is to create the conditions where they can tell you what’s actually true.
The flip side of this dynamic is that once the team trusts you — once they understand that honesty about problems is welcomed rather than punished — the relationship changes dramatically. Some of my most direct and reliable feedback on operational issues came from that team once that trust was established.
There was also a significant tendency to assume mastery of topics they’d been briefly introduced to. An agent would attend a training session on a new product feature and come away confident they had it handled — sometimes correctly, often not. The solution wasn’t more testing alone (though we did more testing). It was building a culture where asking questions was normalized and admitting uncertainty was treated as a sign of professionalism rather than weakness. That cultural shift took longer than I expected and required deliberate reinforcement over months.
This connects to something I’ve written about more broadly in KPIs and the Importance of Measurements — the gap between what your metrics tell you and what’s actually happening on the ground. In an offshore context, that gap can be wider, and requires active management to close.
The Operational Realities Nobody Puts in the Business Case
Shift patterns and time zones
Covering North American or European business hours from India means your team is working nights. This is not a minor consideration — it affects recruitment (not everyone will take a night role), retention (night work has physical and social costs), and the support infrastructure you need to build around the team.
You cannot simply ask people to work through the night and assume everything else stays the same. The operational model has to account for it explicitly — in your shift design, your management coverage, and your wellbeing policy.
Support for female staff — and for everyone
This was non-negotiable and I’d make it policy from day one in any future operation: no employee — regardless of gender — should be alone in the office. For female employees on night shifts, this is especially important both for safety and because local norms make it a significant concern for families who may be weighing whether to allow a family member to take the role.
Beyond the safety dimension, this affects scheduling. You need to build shift patterns that ensure coverage is never a single person. This adds complexity to your rota design but it’s not optional.
Food and transport subsidies
These are not perks. They are standard parts of the employment offer for any serious operation in this market. A food subsidy (typically a canteen or meal allowance) and a transport subsidy (company transport or reimbursement for travel to and from the office) are expected and factored into candidates’ evaluation of an offer. If you’re not offering them, you’re at a disadvantage in the talent market before the conversation even starts.
Remote work doesn’t work — or didn’t
When we set this team up, remote infrastructure in Bangalore simply wasn’t reliable enough to support a contact centre operation. Connectivity was inconsistent, home environments weren’t conducive to call handling, and the collaboration tools we relied on didn’t perform predictably enough over residential connections. The operation ran in-office, full stop. Plan your model around this reality rather than assuming flexibility you may not have.
The Accent and Voice Question — The One Most Leaders Avoid
I’m going to address this directly because most write-ups of offshore operations skip it entirely, and skipping it doesn’t make the problem go away.
Customers in North America and Europe frequently reacted negatively to offshore agents — not because the agents were less capable, but because of accent and perceived cultural distance. The research on this is robust and uncomfortable. A University of Chicago study by Lev-Ari and Keysar found that speakers with foreign accents are consistently perceived as less credible — even when their statements are objectively accurate and their content is identical to that of a native speaker. A 2024 study published in the Journal of Service Research found that an unfavourable foreign accent negatively influences customer participation and cooperation in service interactions — with some customers preferring to switch to self-service rather than continue an interaction with an agent whose accent they perceived negatively. Research from Emerald Insight found that foreign accents in voice-only service environments specifically reduce customers’ tolerance and increase their perception of a service provider’s lack of understanding.
None of this means the assumptions customers are making are correct. They are not. But they are real, they affect CSAT, they affect escalation rates, and they affect whether customers trust the resolution they’ve been given.
We implemented accent neutralization training across the Bangalore team. This isn’t about erasing identity — it’s about training agents to modulate pronunciation, adjust cadence, and communicate in patterns that reduce friction with their caller demographic. It’s a skill, and it’s teachable. The University of Leeds Business School research specifically recommends inclusive staffing and training policies that elevate service communication skills to help agents overcome stereotypical judgements — not relegating agents to back-office roles, but equipping them to navigate the bias.
What surprised me was that the same training was valuable — and was rolled out — to our Montreal team. Different accent, different friction pattern, same underlying dynamic. Customers in certain markets responded differently to Quebecois-accented English in technical support contexts. We addressed it the same way.
I’m aware this is uncomfortable territory. But running a support operation means making decisions that affect the customer experience, and pretending this variable doesn’t exist doesn’t serve anyone.
The Handoff Problem — and How We Solved It the Hard Way
Building a team is the easy part. Building a team that operates as part of a seamless 24/7 operation with teams in other time zones is the genuinely hard part.
The mechanics of the handoff — how tickets in progress are transferred, how context is communicated, how in-progress calls are routed — require discipline that has to be built deliberately. It doesn’t emerge on its own. This is true of SLA design more broadly: the framework on paper and the operational reality can be very different things, and the difference usually comes down to handoff discipline.
When we set this up, we were operating before proper omnichannel or skill-based routing was available in our environment. We built 24/7 coverage using DTMF functionality — the phone system would route calls to the appropriate team based on time of day and availability using basic keypad-based menu routing. It was not elegant. It required careful configuration and careful documentation. But it worked, and it taught me something I’ve carried into every subsequent operation: the discipline of handoffs matters more than the technology enabling them. I wrote more about the evolution of routing models in Navigating the Complexities of Skill-Based Routing — the Bangalore operation was where I first learned what breaks when routing logic isn’t right.
The human problem was harder than the technology problem. The North American and European teams didn’t want to give up control. This is understandable — they’d built their queues, their relationships with escalation contacts, their familiarity with recurring customers. Handing that off to a team they’d never met, working overnight, felt like loss of quality rather than extension of coverage.
Getting past this required patience, structured overlap periods where both teams were working the same queue simultaneously, and deliberate investment in relationship-building between the teams. Video calls that were about people rather than tickets. A recognition that trust between teams is built the same way trust between people is built — slowly, through demonstrated reliability.
The incident management and problem management discipline I’d built into the broader operation was critical here. Having clear ownership of in-progress issues at the point of handoff, with documented context rather than verbal transfer, was what allowed the offshore team to pick up where the day team left off without losing thread. Without that discipline the handoff becomes a fresh start for the customer — which defeats the entire purpose.
It took longer than I expected. But eventually we reached a point where calls and tickets routed seamlessly between time zones without the customer experiencing any discontinuity. That was the goal. We got there.
What I’d Do Differently
Start the training longer and earlier. The assumption that you can compress the onboarding timeline because you’re working with smart people is wrong. Smart people who receive compressed training still have gaps — they’re just better at hiding them until the gaps matter. Build more time into the plan than you think you need.
Invest in the team relationship before the operation is live. The friction between regional teams would have been lower if we’d built the cross-team relationship before the handoff process started. Get the teams on calls that aren’t about operational process. Let them know each other as people.
Build the governance model for overcommitment explicitly into your management cadence. Don’t wait for a missed commitment to create the checkpoint framework. Build weekly verification into the process from day one, make it normal, and make it clear that the purpose is support rather than surveillance.
Plan for longer. Everything takes longer than the business case assumes. The talent is there. The capability is there. The cultural alignment takes time, the operational discipline takes time, and the regional team trust takes time. Build that into your timeline before you promise a go-live date.
A Final Note on the Experience
I’ve been back to Bangalore since that initial setup trip, and my appreciation for the city has grown each time. The complexity of it — the coexistence of extremes, the energy, the genuine warmth of the people — is something that stays with you.
The team we built there was one of the most dedicated I’ve managed anywhere. Once the operational model was right and the trust was in place, they delivered consistently and took real pride in being part of a global operation. That pride matters. The best offshore operations aren’t remote outposts — they’re extensions of a team with a shared identity.
Getting to that point takes more work than the business case suggests. But it’s worth it.
Editor’s note: The nearshore operation I built at Q4 Inc had its own dynamics — different geography, closer time zones, different challenges, some of the same cultural dynamics in new forms. I’ll cover that in a follow-up post.
Hutch Morzaria is a CX and Support Leadership professional with 19 years of experience building and leading support organizations across SaaS, Fintech, and enterprise technology. He has held Director-level roles at Q4 Inc, AudienceView, Johnson Controls, and others, and holds ITIL Expert certification across V3 and V4.
