IT Support in China for a Software Vendor's Two Offices

The short answer: A European software vendor runs its global IT to one standard and assumes its two China offices are just two more sites on it. The tickets that actually arrive from Shanghai and Beijing are about things that standard never anticipated — a service desk nobody will call in English, a network link nobody has actually measured, and compliance obligations that sit on the local entity no matter what HQ policy says.

A global IT director at a European enterprise-software company gets a message from the Shanghai office manager: staff have stopped raising tickets with the European service desk, and problems are instead getting solved — or not solved — informally, over group chat, in Mandarin, by whoever in the office happens to know the fix. The director's first instinct is to remind everyone that the ticketing system is there for a reason. The more useful question is why a 45-person office stopped using it in the first place.

This is written for that director, or for whoever at a European or North American technology or software vendor is responsible for IT once the company's footprint stretches to a Shanghai head office of around 45 people and a Beijing sales office of around 15. It is an illustrative composite scenario, not a named client — but the pattern is one Brocent has run into repeatedly, because it sits close to the company's own history. Brocent was founded in Beijing in 2007, has operated a Hong Kong office since 2016, and has been headquartered in Singapore since 2021. A meaningful share of its client base is exactly this profile: a foreign technology company whose only presence in Asia is China, run at arm's length from a head office on the other side of the planet.

The Industry: Software Vendors Whose Only Asia Footprint Is China

Enterprise software, developer tooling, industrial software, and specialist SaaS companies headquartered in Europe frequently expand into Asia by opening exactly one office, and that office is usually in China rather than Singapore or Japan, because China is where the largest concentration of prospective enterprise customers, systems-integration partners, or in some cases the company's own delivery and engineering talent already is. The office that results is rarely a small satellite sales desk. It is often a genuine delivery or R&D presence — engineers, implementation consultants, customer success staff — sitting alongside a smaller commercial team, because the parent company found it more efficient to build product and delivery capacity in China than to fly staff in from Europe for every project.

A second office frequently follows within a year or two, almost always in Beijing if the first was in Shanghai, or the reverse, because enterprise software sales in China runs through a small number of cities where the buyers, government relationships, and systems-integration partners are concentrated. The result is two offices, a few hundred kilometres apart, that between them cover delivery and sales for the company's entire Asia business — and that were never really planned as "IT sites." They grew out of a hiring decision, not an infrastructure decision, and IT is usually the last function to notice that the company now has a genuine China operation rather than a handful of remote employees who happen to be in China.

The Scenario: 60 People Across Two Cities, One Office Manager, and a Time Zone With No Overlap

The composite site: a Shanghai head office of about 45 people — engineering, implementation, customer success, and a general and administrative function — plus a Beijing sales office of about 15, mostly commercial and partner-facing staff who spend much of their time in client meetings rather than at a desk. There is no dedicated IT hire in either city. The closest thing to local IT is an office manager in Shanghai who also handles the lease, the couriers, and the pantry supplies, and who has picked up "call the vendor if the Wi-Fi is down" as an unofficial extra duty. Everything else — identity, endpoint policy, the helpdesk, security tooling, the collaboration stack — is owned and operated by a small IT team at the European headquarters.

That team is good at its job, and the global standard it built is genuinely solid: a single identity provider, a consistent endpoint build, one collaboration suite, one ticketing system, one set of security policies applied everywhere. The problem is the clock. Shanghai and Beijing run roughly six to eight hours ahead of the European head office depending on the time of year, which means the two offices' entire working day sits either before the European team has logged on or after they have gone home. A laptop that won't authenticate at 9am in Shanghai is a ticket that gets picked up in Europe's late morning at the earliest — by which point the Shanghai staff member has either found a workaround, given up for the day, or asked a colleague in the group chat. None of those outcomes shows up as a service-desk metric anywhere, which is exactly why the problem stays invisible from Europe for as long as it does.

Real Problem One: A Service Desk That Has to Actually Work in Mandarin

The European service desk operates in English, because English is the working language of the rest of the company. A meaningful share of the Shanghai engineering and delivery staff, and a good number of the Beijing sales team, are fluent enough in English to do their jobs but not necessarily comfortable enough to describe a technical problem precisely to an unfamiliar agent over chat or phone, under time pressure, in a second language. The practical result is not that people can't get help — it's that they quietly stop asking. A ticket that would take two minutes to describe in Mandarin gets abandoned, worked around informally, or escalated only once it has become a bigger problem than it needed to be. This is not a training issue and not a discipline issue. It is a language-and-time-zone issue that a single global service desk, however well run, cannot fully solve on its own — which is exactly why a 24/7 help desk that can actually operate in Mandarin during China business hours, rather than only in English on a European clock, changes the number of problems that get reported before they become bigger ones.

Real Problem Two: Cross-Border Network Performance That Has to Be Measured, Not Assumed

The European IT team built its collaboration stack, its VPN, and its monitoring tooling assuming a reasonably uniform global network experience, because that assumption holds true for the company's other international offices. It does not reliably hold true for a China office, and the honest reason isn't a specific blocked service or a headline bandwidth number — it's that cross-border connectivity between China and the rest of the internet behaves differently by route, by time of day, and by which specific cloud regions and services are involved, in ways that shift over time. The only responsible position is to stop assuming and start measuring: test the actual applications the Shanghai and Beijing teams depend on, from those offices, at the times of day people actually use them, and design around what is actually observed rather than around what worked fine for the Singapore or Tokyo office. A related fact worth knowing rather than guessing at: Microsoft 365 in mainland China is operated as a separately run service (historically via a licensed local operator, commonly referred to by the 21Vianet name), which is a genuine operational difference from the global Microsoft 365 tenant most European teams are used to — not a reason to avoid the platform, but a reason to test the specific workflows a China office needs before assuming they behave identically to the global service.

Real Problem Three: Endpoint Management and Software Distribution Over a Link That Behaves Differently

A global endpoint management platform that pushes OS updates, security patches, and application packages to every laptop in the company from a set of cloud endpoints designed around a Europe-and-Americas user base runs into the same measurement problem as the collaboration stack. A patch cycle that completes overnight without anyone noticing at the European or US offices can behave differently for a Shanghai or Beijing device pulling the same payload across a longer and more variable path — again, not because a specific thing is blocked, but because the actual delivered experience needs to be tested from the China offices rather than inferred from how it performs everywhere else. The practical fix is usually architectural rather than dramatic: local caching or a regional distribution point for large packages, patch windows scheduled against China business hours rather than Europe's, and monitoring that reports endpoint compliance by office rather than as a single global average that quietly hides a China-specific problem. This is squarely infrastructure-deployment territory — getting the distribution architecture right once, rather than firefighting slow patch compliance office by office — which is the kind of work covered under IT infrastructure deployment.

Real Problem Four: Hardware Procurement and Fapiao Invoicing Nobody at HQ Has a Process For

A European finance team knows how to process an invoice from a European IT vendor. It generally has no established process for procuring a laptop, a monitor, or networking equipment in China, and no familiarity with the fapiao — the official tax invoice required for a purchase to be properly recorded and expensed against a Chinese legal entity, which is not simply a foreign-language receipt but a specific, regulated document type with its own compliance requirements. The result, left unmanaged, is one of two failure modes: someone in Shanghai buys equipment on a personal card and fights for months to get reimbursed against an invoice finance doesn't know how to process, or hardware purchasing quietly stalls because nobody is confident they're doing it correctly, and staff make do with aging equipment far longer than the company would tolerate anywhere else. Neither is a technology problem. Both are process problems that a China-based partner who already knows how local procurement and invoicing actually works can absorb as a routine part of the service rather than as a recurring point of friction between the Shanghai office and Europe's finance function.

Real Problem Five: MLPS and PIPL Obligations Sit on the Local Entity, Regardless of HQ Policy

The company's global information-security policy was written in Europe, almost certainly with GDPR as its reference point, and it is a genuinely good policy. It is not, on its own, sufficient in China. The Multi-Level Protection Scheme (MLPS) framework and the Personal Information Protection Law (PIPL) impose obligations that attach to the Chinese legal entity operating the Shanghai and Beijing offices specifically — data classification and system-grading requirements, security assessment and filing obligations depending on the systems involved, and rules around cross-border data transfer that are meaningfully different from GDPR's. A European privacy policy, however well written, does not discharge these obligations, and "our global policy already covers this" is not a position that holds up to a Chinese regulator. This is one of the areas where the gap between the global standard and the local reality is largest, and where getting it wrong carries real regulatory exposure rather than just an inconvenienced user — which is why it belongs inside the ongoing service relationship, under managed IT security services, rather than treated as a one-off legal project that gets filed away and forgotten once the paperwork is done.

What Usually Forces the Issue

Companies in this position rarely commission a review of their China IT setup proactively. Something specific tends to push it onto the agenda. Sometimes it's the moment described at the start of this article — a pattern of tickets quietly disappearing from the official queue and resurfacing as informal group-chat fixes, which someone at HQ eventually notices and asks about. Sometimes it's a customer or partner due-diligence questionnaire that asks pointed questions about data handling and compliance in China, and the honest answers turn out to be uncomfortable. Sometimes it's a security incident, or a near-miss, that reveals nobody had actually verified how the global security stack performs from the China offices. And sometimes it's simply growth — a Beijing office that started as three people covering the market from Shanghai grows into its own 15-person team, and the ad hoc arrangements that worked for three people visibly stop working for fifteen.

Brocent's Perspective: The Failure Mode Is Assuming, Not Neglecting

The honest framing is this: a European or North American software vendor whose only Asia presence is China rarely fails its China offices through neglect. Leadership generally cares, and the global IT standard is usually genuinely good. The failure mode is assuming that standard applies to China unchanged, when in practice a handful of specific things — language, time zone, cross-border network behaviour, local procurement and invoicing, and a distinct compliance regime — do not transfer without deliberate adaptation.

Brocent's view, shaped by having been founded in Beijing in 2007 and by running IT for exactly this kind of foreign technology company ever since, is that the workable answer is not to throw out the global standard and build something bespoke for China, and it is also not to pretend the global standard needs no adjustment at all. It is a short, deliberately chosen, and documented China exception list — decided once, written down, and owned by someone in-country who is actually accountable for it — covering the handful of things that genuinely need to differ: how the service desk operates in China hours and in Mandarin, how endpoint distribution is architected for the China link, how procurement and invoicing work locally, and how MLPS and PIPL obligations get discharged. Everything that doesn't need to differ stays exactly as HQ built it. That is a different thing from the undocumented local workarounds most companies in this position actually end up with — informal fixes nobody at HQ knows exist, invented independently by whoever in the Shanghai office happened to solve the problem that week.

What Full-Scope China IT Support Actually Covers

Five things distinguish a support arrangement that genuinely closes the gap between a European global standard and a working China operation, rather than quietly leaving it open.

A Mandarin-and-English service desk that operates on China hours. Staff in Shanghai and Beijing should be able to raise a ticket in the language they're most precise in, during the hours they're actually working, and get a response without waiting for Europe to wake up. This alone tends to surface the largest volume of previously invisible problems, because it removes the two biggest reasons people quietly stop reporting them.

In-country onsite dispatch for both cities. Shanghai and Beijing are far enough apart that "we cover China" has to mean two real onsite capabilities, not one engineer who happens to be based in one city and treats the other as a special trip. Network, hardware, and office-move issues in either city need a genuine local response, not a remote-only default that quietly becomes the norm because nobody budgeted for two cities.

Endpoint and patch management architected for the real link. Rather than pushing the same global distribution architecture at China and hoping, this means testing what actually happens from Shanghai and Beijing, and adjusting caching, distribution points, and patch scheduling based on what is actually observed — the same measure-first discipline that should apply to managed IT cloud services generally when a China office is in scope.

Local procurement with proper fapiao invoicing. Hardware and equipment purchased, invoiced, and expensed correctly against the Chinese entity the first time, without a European finance team having to learn an unfamiliar process or a Shanghai staff member fronting the cost personally.

Compliance obligations handled as part of the service, not as a side project. MLPS classification and PIPL obligations reviewed and maintained on an ongoing basis as systems and data flows change, rather than addressed once during a legal engagement and then left to drift out of date as the business grows.

Two managed IT offices under one arrangement, rather than two separate improvised setups, is also simply the more coherent way to run identity, security policy, and reporting across Shanghai and Beijing — which is where managed IT cloud services covering both cities under one SLA tends to replace what would otherwise be two disconnected local fixes.

One Local Hire Reporting Into HQ vs An Ad Hoc Local Break-Fix Vendor vs One Managed IT Partner Delivering the Global Standard With a Documented China Exception List

• One local hire reporting into HQ — Puts a real person on the ground, which genuinely helps with language and presence, but a single hire is a single point of failure with no coverage for leave, illness, or turnover, no formal escalation path, and rarely the breadth of skill to cover network engineering, endpoint management, security, and compliance all at once. It also tends to become an informal second IT department that HQ has limited visibility into.
• An ad hoc local break-fix vendor — Useful for the occasional physical fix — a printer, a cable run, an office move — but structurally reactive: no 24/7 coverage, no ownership of the endpoint fleet or security posture, no compliance capability, and no accountability for whether the Shanghai and Beijing offices are actually meeting the same standard as the rest of the company.
• One managed IT partner delivering the global standard with a documented China exception list (Brocent's model) — Keeps everything that doesn't need to change exactly as HQ designed it, and handles the handful of things that genuinely do differently and deliberately: a bilingual service desk on China hours, onsite coverage in both cities, endpoint delivery tuned for the real network path, local procurement and invoicing, and MLPS/PIPL obligations managed on an ongoing basis. The tradeoff is that it costs more than a single local hire on paper — the honest answer is that a single local hire was never actually covering the same scope.

Frequently Asked Questions

What does "IT support China" actually include that a global helpdesk doesn't?

It includes the things a language- and time-zone-neutral global helpdesk structurally can't provide on its own: a service desk that operates in Mandarin during China business hours rather than only in English on a European clock, onsite dispatch that actually reaches both Shanghai and Beijing rather than treating China as one location, network and endpoint performance that has been measured from those specific offices rather than assumed to match everywhere else, local hardware procurement with correct fapiao invoicing, and MLPS/PIPL compliance obligations that a purely European security policy does not discharge. None of it replaces the global standard — it fills the specific gaps where that standard doesn't transfer unchanged.

Do we need a China entity before we can buy IT support locally?

In most cases, yes — a registered local entity is typically what makes local hardware procurement, correctly invoiced through the fapiao system, and most forms of locally contracted IT service straightforward, and it's also the entity that MLPS and PIPL obligations actually attach to. Companies that have staff in China without a formal local entity yet should treat that as one of the first questions to resolve with legal and finance advisors, because it shapes what can be procured and contracted locally versus what has to route through the parent company in the interim.

How should we test whether our global collaboration tools actually perform well enough from each office?

Test the specific applications your Shanghai and Beijing staff actually rely on day to day — video calls, file sync, the identity and VPN path, any SaaS platforms core to their work — from those offices, at the times of day people actually use them, over a period of days rather than a single check. Compare that against what the same applications look like from a European or US office, and treat any meaningful gap as a design input rather than a one-off inconvenience to be tolerated. Avoid assuming a specific service is or isn't affected without testing it directly from the office in question — cross-border network behaviour changes over time and by route, which is exactly why measurement beats assumption here.

Who is responsible for MLPS and PIPL — us or the provider?

Legal responsibility sits with the Chinese entity operating the Shanghai and Beijing offices, which in practice means the company, not any outsourced provider — a managed IT partner can't absorb that legal accountability on your behalf. What a capable partner can do is the operational work that keeps you in a defensible position: system classification, ongoing security controls aligned to MLPS requirements, and data-handling practices that support PIPL compliance, delivered as a continuous part of the service rather than a one-time project. Final accountability, and sign-off on classification and filings, should still involve your own legal counsel.

Can one provider cover both Shanghai and Beijing under one SLA?

Yes, and for a company of this size it is usually the more coherent option, because the two offices share identity, security policy, endpoint standards, and reporting, and a single provider avoids the coordination overhead of managing two separate local vendors who don't talk to each other. The SLA can and should still reflect that Shanghai and Beijing are two distinct onsite locations with their own response commitments, rather than pretending "China" is a single point on a map.

What changes if we later open a third China city?

Less than most companies expect, provided the first two offices were set up with a documented approach rather than ad hoc fixes. The service desk, the identity and security baseline, the procurement and invoicing process, and the compliance framework are largely designed to extend rather than to be rebuilt from scratch — what a third city mainly adds is another onsite dispatch location and, if the office is large enough, its own local network measurement, following the same measure-first approach already used for Shanghai and Beijing rather than assuming performance will simply match.

Getting IT Support in China That Matches How the Business Actually Runs

A Shanghai head office and a Beijing sales office are not simply two more sites on a global IT standard built in Europe — they run in a different language, on a different clock, across a network path that has to be measured rather than assumed, and under a compliance regime that attaches to the local entity regardless of what HQ policy says. None of that means starting over. It means a short, deliberately chosen, documented list of where China genuinely needs to differ, owned by someone accountable for it, layered on top of a global standard that stays exactly as good as it already is everywhere else.

Brocent has supported foreign technology and software companies operating in China since it was founded in Beijing in 2007, and has run that same conversation with dozens of companies whose only Asia presence is exactly this: a Shanghai and a Beijing office trying to run on a European standard that was never quite built with them in mind. If that sounds like where your company is today, get in touch for a conversation that starts with what your Shanghai and Beijing offices actually need, rather than with a template.