Nearshoring support to Mexico worked for us because we treated it as an extension of one team, not a separate operation. The location solved a time-zone problem. The structure, three clear levels of support with the same standards in every region, solved everything else.
At Q4, my team supports public companies’ investor relations sites across North America, Europe and Latin America, including Mexico and Brazil. The nearshore part of that plan was one of the pillars I described in building a three-to-five-year support plan. This is the post on how I thought about it, and how the levels inside the team made it work.
Why nearshore, and why Mexico?
Because of hours. Our busiest moments are tied to customer deadlines in North American business hours, and a team in Europe covers the start of that day but not the end. A team in Mexico covers a time zone close to our North American customers. When a request lands at 3pm and needs to be done by 4:05, somebody being awake and working at the same time as the customer is worth more than any cost saving.
The second reason was the talent. Front-end technical support is a skilled job: the people doing it work in CSS, JavaScript, Java and HTML and have to understand what a customer is trying to publish. Hiring such people is competitive everywhere, and a plan that only drew from one city’s pool would have been slower and more expensive than one that looked wider.
I’d thought about this before. At Tyco I built an offshore team to provide dedicated 24/7/365 cover, and I wrote about the model in the follow-the-sun case study. The lesson from that work was that geography is the easy part. What makes a distributed team function is the discipline around it: shared processes, shared standards and a clear idea of who owns what. A nearshore team with different rules from everyone else isn’t an extension of the team. It’s a second team, and customers can tell.
How do you decide whether to insource or outsource?
With a full cost comparison and not a vendor’s deck. I’d learned that the hard way and wrote it up in the insource versus outsource case study. The basic point is that every model has costs the other side’s presentation doesn’t show: management overhead, tooling, the transition itself and the risk to quality and control. My older post to source or outsource makes the same argument in a few paragraphs.
Whatever you choose, be honest about control. A team you employ works within your culture and your management. A contracted team works to a contract, and the gap between the two shows up in the situations the contract didn’t anticipate. For work with hard customer deadlines and sensitive content, that gap matters more than the per-seat price. Decide how much control you need, then pick the model that gives you that much.
What do the three levels of support actually do?
Each level handles a different kind of work, and the definitions need to be written down and shared, because a nearshore team needs them even more than a co-located one does. Nobody can lean over and ask where the line is.
Tier 1 handles the work that has a known answer. Standard updates, common requests and routine questions that can be solved from documentation and experience. The goal at this level is speed and consistency: a quick first response and a correct fix at first touch. It’s the band-aid work I described in what a help desk is, and it’s where most new people start.
Tier 2 handles the work that needs more investigation or more technical skill. Requests that involve custom behaviour, unusual combinations of settings or something that has to be diagnosed before it can be fixed. Tier 2 people take longer per case and are expected to find the cause, not just the symptom, and to feed what they learn back into the documentation Tier 1 uses.
Tier 3 is the deepest technical level and the escalation point. These are the people who deal with the hardest problems, work with engineering and mentor everyone below them. They’re also where problem management lives: finding why something keeps happening and getting it fixed so it doesn’t happen again.
The same three levels apply in every region. That’s deliberate. A request should be handled to the same standard whether it’s picked up in Toronto, in Mexico or in Europe, and a person should be able to move between regions without relearning how the work is organised.
How do you move people between levels?
With defined, observable criteria, not a manager’s feeling. At AudienceView I built a three-level certification, documented in the AudienceView University case study, where each level had specific content, an assessment and a requirement to contribute to the knowledge base. The conversation changed from “when will I get promoted?” to “what do I need to do for the next level?” That’s the conversation you want, particularly with a distributed team, where people can’t see how promotion decisions get made.
A visible path also helps retention. People stay when they can see where they’re going. In a nearshore team, where you may be competing with other employers for the same skills, that matters a great deal. The levels don’t just organise the work. They tell a Tier 1 developer in Mexico that there’s a route to Tier 3 that doesn’t depend on moving to another city.
If you want to go further, tying pay to certification makes progression worth pursuing. I did that at Tyco with a four-level structure and a defined salary step at each level. It’s more complicated to set up across countries, because pay and employment rules differ, but the principle carries over.
What makes a nearshore team actually work?
Five things, none of them exotic. First, the same onboarding for everyone. A new Tier 1 developer in Mexico should go through the same curriculum, assessment and mentoring as one in Toronto. Second, shared tools and a single source of truth. If the knowledge base is in one language and one place, everyone works from the same answers.
Third, handoffs that work. When a case moves between regions or levels, the notes must make it possible to continue without asking the customer to repeat anything. I treat handoff documentation as part of the job, not an extra. Fourth, local leadership. A nearshore team needs team leads who sit with them, in their hours, who know them personally. Remote management of an entire location through a screen is fragile.
Fifth, equal standing. People who feel like a second-class team will behave like one. Invite the Mexico team to the same meetings, share the same information at the same time, recognise their work in the same places and put them in the same promotion path. And pay attention to the small things: scheduling meetings at times that suit more than one region, and not defaulting to the headquarters time zone.
Be realistic about the early months. A new location has a learning curve, and the first quarter will be slower than the plan says. Plan for it. Pair new people with experienced ones, protect them from the hardest cases at the start and expect the quality metrics to take a while to settle. If you judge the nearshore team against the established team’s numbers in week six, you’ll draw the wrong conclusion.
A word on language and culture. Working across countries means working across different habits of communication, and it’s easy to misread them. Directness that sounds normal in one place can sound blunt in another. Silence on a call doesn’t always mean agreement. The fix isn’t elaborate. Ask for confirmation in writing, repeat back what you’ve understood and encourage questions in whatever channel people feel comfortable using. Over time the team builds its own shared habits.
Think about continuity as well. A new location means a small number of people who hold a lot of the knowledge, so plan for absence, holidays and the occasional resignation from the start. Cross-train within the team, keep the documentation current and make sure no single person is the only one who can handle a particular kind of request. It’s the same discipline I’d apply anywhere, and it matters more when the team is still finding its feet.
Time zones help only if the standards are the same. Get that right and a team in another country stops feeling like another country.
Hutch Morzaria is a Director-level CX and Support Leadership professional with 19 years of experience building global support organizations across SaaS, Fintech, and enterprise technology. He has hired dozens of support and CX leaders across his career and holds ITIL Expert certification across V3 and V4.
