Eleven Questions Before You Subcontract: Vetting a Local IT Delivery Partner in Asia

Short answer: subcontracting local hands is a delivery-risk decision, not a procurement one. You already sold the work; what you are buying now is the probability that your SLA survives contact with a city you do not staff. Eleven questions separate a partner who can hold that SLA from one who will simply quote it back to you.

This article is written for a specific reader, and it is worth saying who that is before the first question. You run service delivery at an MSP, a systems integrator, a digital agency or a consultancy. You have won — or are about to win — work that includes a site in Hong Kong, Singapore, Shenzhen, Osaka, Kuala Lumpur or somewhere considerably less convenient, and you have no engineers there. The contract is signed or the proposal is in. The clock is running.

You are not deciding whether outsourcing is a good idea. That question was settled the moment you signed. Most content about IT outsourcing is written for the end customer who is still deciding, and it will waste your time. What you need is a way to tell, in two or three conversations, whether the local partner in front of you can actually deliver what you have already promised your client — and what it will cost you when the answer turns out to be "mostly".

Brocent sits on the other side of this conversation regularly. Roughly a quarter of the genuine enquiries that reach us are not end customers at all: they are IT service companies who have won work they cannot physically deliver. What follows is the list of things we wish more of them asked us on the first call, written from the position of the party being vetted rather than the party selling.

Who this is for, and who it is not for

If you are a regional HQ or a US or European head office evaluating how to cover your own Asia offices, this is the wrong article — IT support for US companies in Asia covers that decision, where the economics, the contracting entity and the internal politics are all different. There, you are the end customer. Here, you are the prime contractor, and there is a client behind you who will never see your partner's name.

That difference changes almost everything about the evaluation:

• Your risk is reputational before it is financial. A missed visit costs you a service credit. It costs you the account.
• You cannot pass through an excuse. "Our partner couldn't get someone there" is not a sentence you can say to your client.
• You need an audit trail you do not own. Your client will ask for evidence of work you did not perform.
• Margin is thin and pre-committed. You priced this before you knew what local delivery costs. A surprise there comes straight out of your gross margin.

Hold those four in mind through everything below. Each of the eleven questions exists because one of them fails in practice.

Question 1: Which cities do you actually staff, and which do you reach?

"Coverage" is the single most abused word in this market, and nearly every provider — Brocent included — uses it. It is worth forcing a partner to decompose it into three quite different things.

Staffed means salaried or contracted engineers who live in that city and work there most days. They know the buildings, the landlords, the loading-bay rules and the local hardware suppliers. Reachable means an engineer who can get there — on the same day, overnight, or by plane — at a cost somebody is going to pay. Sourceable means the provider has a network they can recruit from when a job comes in, which is a real capability but a slower and more variable one.

All three are legitimate. None of them is wrong to sell. What is wrong is presenting the third as the first. Ask the question in this form and the answer becomes checkable: for this specific address, is your nearest engineer resident in this city, resident in this country, or recruited on demand — and what is the difference in lead time between those three?

Brocent's own answer, published on the field dispatch service page, is a 100+ country dispatch network with a registered field engineer pool, and a dispatch SLA of four hours for emergency P1/P2 requests or next business day for standard ones. That is a real, contractual arrival-time commitment — but you should still ask the question above for your specific site, because a 100+ country figure describes a network, not a street.

The secondary-city problem nobody quotes for

Primary cities are easy. Every provider in Asia can put someone in Central, Raffles Place, Marunouchi or Pudong. The differences appear at the second tier: Dongguan rather than Shenzhen, Johor rather than Singapore, Kaohsiung rather than Taipei, Cebu rather than Manila.

At the second tier you should expect — and price for — a genuinely different service: longer lead times, travel time that is billable or absorbed, a smaller pool meaning less choice of skill level, and sometimes a different commercial model entirely. If a partner quotes you the same rate and the same SLA for a secondary city as for the capital, that is not generosity. It is usually a sign that they have not thought about it, and you will discover the gap in month three.

Question 2: Which delivery patterns can you run, and can we switch mid-contract?

There are three patterns that matter, and they are not interchangeable:

• Embedded — a named engineer at your client's site full time, effectively part of their team.
• Scheduled — a recurring, planned presence: two days a week, one day a fortnight, a monthly maintenance window.
• Dispatch — reactive, per-visit, triggered by a ticket.

Most subcontracted work starts as dispatch because that is the smallest commitment. A large share of it should have started as scheduled, and a meaningful share ends up embedded within a year. The question to ask is not "which do you offer" — most competent partners offer all three — but what happens commercially when you need to move between them.

Specifically: is there a conversion path from accumulated dispatch spend into a scheduled or embedded commitment? Does the embedded rate reflect the fact that you are now giving them predictable revenue? Is there a minimum term on the embedded model, and does it survive your own client's contract length? A partner who has genuinely done this will have an answer ready. One who has not will offer to "look at it when we get there", which means you will be renegotiating from a weak position at exactly the moment your client is expanding scope.

Comparison: three kinds of local partner, from a subcontractor's seat

A staffing agency

• Gives you: a person, quickly, at a transparent day rate.
• Does not give you: escalation depth, tooling, documentation, or anyone to call when that person is sick. You are the second line, and so is your client.
• Right when: you need hands for a defined project with a defined end date, and you already have the engineering behind it.

A local systems integrator

• Gives you: genuine local depth, vendor relationships, sometimes better hardware pricing than you can get.
• Does not give you: multi-country consistency, or necessarily any interest in being invisible — many SIs want the end-client relationship, and some will take it.
• Right when: the work is concentrated in one country and is project-shaped rather than ongoing support.

A regional MSP acting as a delivery partner

• Gives you: one contract across several countries, a consistent process and ticket trail, escalation behind the engineer, and an explicit white-label position.
• Does not give you: the lowest possible unit rate in any single country — regional overhead is real and it is in the price.
• Right when: the work is ongoing, spans more than one market, and your client will ask for reporting you have to stand behind.

None of these is better. They fail differently, and the failure mode you can least afford should drive the choice.

Question 3: What language does the engineer speak, and what language is the ticket written in?

These are two separate questions and conflating them is the most common scoping error in Asian delivery.

The engineer standing in front of your client's finance manager in Hong Kong probably needs Cantonese. The ticket that reaches your service desk, the asset record that ends up in your CMDB, and the escalation that goes to a hardware vendor probably all need English. The person who explains a three-day parts delay to your client's regional IT lead in Shanghai may need Mandarin. That is three language requirements doing three different jobs, and a partner who answers "our engineers are bilingual" has answered none of them.

Ask it as three questions: what does the engineer speak on site, what language do your tickets and reports come back in, and who talks to my client — you or me?

Brocent's own published position on this is a bilingual help desk running Mandarin, Cantonese and English across tiers 1 to 4, with wider language availability — Japanese, Bahasa Indonesia and Thai among them — across help desk and onsite tiers. Whatever partner you use, get the equivalent stated in writing, per site, before it becomes a scope dispute.

Question 4: How quickly can a named engineer actually start?

Not "how quickly can you mobilise", which means nothing. How many working days from signature to a named individual on site, and what changes that number.

The things that change it are predictable, and you should ask about each:

• A certification requirement. Insisting on a specific vendor certification shrinks the candidate pool. Filters multiply against each other rather than adding, so two hard requirements can cut the pool far more than either alone. The effect shows up in lead time before it shows up in rate.
• A language requirement, for the same reason.
• Security clearance or background checks, which have a fixed floor no amount of money removes.
• Site induction, particularly at industrial or regulated sites, which is frequently the real bottleneck and is almost never in the partner's control.
• Your client's own access process, which is entirely outside everybody's control and reliably takes longer than anyone plans for.

A partner who gives you a single number without asking about any of these is guessing. A good one will quote you a range and tell you which of the five is binding.

Question 5: Whose tickets, whose RMM, and who owns the documentation?

This is the question that decides whether you have bought capacity or bought a dependency.

Three arrangements are common. Your partner works inside your ITSM and RMM tooling, which gives you the cleanest audit trail and the least friction, but requires them to license, train and support engineers on a system that is not theirs. Your partner works in their tooling and gives you an export or an API feed, which is easier for them and acceptable if the feed is genuinely usable. Or — and this happens more often than anyone admits — your partner works in their tooling and emails you a summary, which is not an audit trail at all.

The documentation question sits underneath it. When the engagement ends, do you get the CMDB entries, the site notes, the network diagrams, the credential inventory and the history of known issues? In a documented, portable form, not as a favour?

Brocent's answer here is a matter of published policy rather than negotiation: customer-owned documentation and credentials is an item included in every Managed IT plan tier, not an upsell. Ask your partner the same question and listen carefully to whether the answer is a principle or a concession. Concessions are withdrawn under commercial pressure. Principles are not.

Question 6: What does escalation look like when the engineer cannot fix it?

The engineer on site is the first line. What is behind them?

Ask what happens at three specific moments: when the engineer arrives and the fault is outside their skill level; when the fault is outside the agreed scope entirely; and when it is 2 a.m. locally and your client is on the phone to you rather than to them.

You are looking for an escalation matrix with names or at least roles, an out-of-hours arrangement that is contractual rather than goodwill, and a clear rule about who owns the ticket while it is escalated. The failure mode you are trying to avoid is the one where your partner's engineer closes their visit, your ticket stays open, and nobody owns the gap between the two.

Question 7: What is the unit of billing, and what is not in it?

Unit economics in this market vary more than most people expect, and the headline number is rarely the comparable one.

Dispatch work is normally billed by visit, with a first-hour rate and a lower additional-hour rate. Brocent's published dispatch rate table is a 42-country list on exactly that structure — for example, a first hour in Singapore at US$85 and each additional hour at US$78, at EUC L1, next business day, 9×5. Dedicated engineers are billed monthly: a separate seven-country table, with Singapore at US$4,160 per month at entry level.

What matters more than the numbers is what sits inside them. Ask explicitly:

• Is travel time billable, and from where — the engineer's home, an office, or the city centre?
• Is there a minimum callout, and does it apply per visit or per day?
• What is the out-of-hours and public-holiday multiplier, and whose calendar of public holidays applies?
• Are parts, consumables and courier costs passed through at cost or with a margin?
• Is the rate fully loaded, or are there statutory employer costs, FX handling or payment-term financing charged separately?

That last one is where most surprises live. Brocent's dispatch table footnote states that its rates are fully loaded — covering cost of living, bilingual engineers, training, FX and tax handling, credit-term financing and 24×7 coordination — and its FTE table prices skill tier openly, at roughly +21% for L2 and +44% for L3 against entry level. Whether or not you use us, insist on the equivalent breakdown. A partner who cannot tell you what is inside their rate has not calculated it.

Question 8: Liability, insurance, background checks, and your client's data

This is the least interesting section of any vetting conversation and the one that ends careers when it is skipped.

Establish: who employs the engineer and in which legal entity; what professional indemnity and public liability cover exists and at what limit; whether background checks are performed and to what standard; and — critically — what the partner's legal basis is for touching your client's data.

That last point deserves a sentence of its own. In Hong Kong the PDPO, in Singapore the PDPA and in mainland China the PIPL all impose obligations that flow down the chain. You are a data processor for your client; your partner is a sub-processor. If your client's agreement with you requires sub-processor disclosure — and most enterprise agreements do — then a partner you have not disclosed is a contractual breach waiting to be discovered during your client's next audit.

Question 9: Whose logo is on the shirt, and whose name is in the ticket?

The white-label question is simple to ask and revealing to hear answered.

Some partners will work fully white-label: their engineer introduces themselves as working for you, wears nothing branded, and appears in your ticket system under your process. Some will work co-branded, which many end clients actually prefer because it is honest. Some will insist on their own identity, which is a legitimate commercial position but tells you they regard your client as a future prospect.

There is no correct answer, but there is a correct sequence: decide what your own client has been told, and then find a partner whose position is compatible with it. Discovering the mismatch when your partner's engineer hands your client a business card is an avoidable and expensive way to learn this.

Question 10: What do we take with us when this ends?

Every engagement ends. Ask, at the beginning, what the end looks like.

Specifically: notice period on each side; whether there is a minimum term and what breaks it; whether accumulated documentation transfers to you; whether the engineer has a non-solicitation clause and whether it is mutual; what happens to spare parts, loan devices and consumables held at your client's site; and whether the partner will support a handover to whoever replaces them, at what rate.

A partner who answers these cleanly is telling you something useful about how they expect the relationship to go. One who becomes evasive is telling you something more useful still.

Question 11: What happens when their engineer resigns mid-contract?

This is the question almost nobody asks, and it is the one most likely to hurt you.

If you have bought an embedded or scheduled engineer, that engineer is a person with a career, a notice period and a competitive local labour market. In Hong Kong and Singapore in particular, experienced bilingual infrastructure engineers do not stay unemployed. At some point during a multi-year engagement, yours will resign.

Ask: what is the contractual replacement commitment, in days? Does the replacement arrive already inducted, or does the induction clock restart? Who pays for the overlap period, if there is one? What documentation exists such that the replacement is not starting from zero? And — the sharpest version of the question — is leave cover and backfill included in the rate you just quoted me, or is it a separately priced service?

That distinction is real and it is worth being precise about, including about our own pricing. Brocent's full-time onsite service page sells "Seamless Leave Cover" as a named feature, with replacement drawn from a pool of trained engineers. The published FTE rate table is labelled, in the same breath, as an entry-level monthly rate without backfill, with next-business-day backfill available alongside it. Those are not contradictory — they are two different things you can buy, and the honest framing is that a headline monthly figure which includes cover is not comparable to one that does not. When you compare quotes from three partners, make sure all three are quoting the same thing.

What Brocent's own answers are

It would be evasive to publish eleven questions and not answer them, so, briefly, in the same order.

We staff engineers directly in Hong Kong, mainland China, Singapore, Malaysia and Japan, and dispatch into 100+ countries through a registered field engineer network with a contractual four-hour emergency or next-business-day arrival SLA. We run embedded, scheduled and dispatch patterns and will convert between them mid-contract. Our help desk operates in Mandarin, Cantonese and English across tiers 1 to 4, with Japanese, Bahasa Indonesia and Thai available across help desk and onsite tiers. Lead time depends on the filters you set, and we will tell you which one is binding rather than quoting you a number we cannot hold.

We will work inside your ITSM or ours. Documentation and credentials are customer-owned as a matter of standing policy across every plan tier. Rates are published — 42 countries of dispatch rates and seven of monthly FTE rates — and are fully loaded, with the skill-tier uplift stated rather than buried. We work white-label where that is what you need. And on the last question: leave cover exists as a named service, backfill is separately priced against the entry rate, and we would rather tell you which you are buying now than have you find out in July.

Behind all of it sits the same engine as our per-user managed IT plans — the monitoring, the patching, the help desk and the reporting that make any individual engineer replaceable. That is the actual argument for using a regional MSP as a delivery arm rather than a staffing agency: not the engineer, but what stands behind them.

If you are scoping a specific site and want the eleven answers for that address rather than in general, talk to us.

Frequently asked questions

Do you work white-label?

Yes. Engineers can attend site unbranded and present as your team, and work can be recorded in your ticketing system under your process. We also work co-branded where the end client prefers transparency. The position needs to be agreed before the first visit, not after it, because it affects how the engineer introduces themselves and what appears in the service report your client signs.

Which cities do you staff directly?

Brocent has staffed operations in Hong Kong (since 2016), mainland China (the company was founded in Beijing in 2007), Singapore (headquarters since 2021), Malaysia and Japan. Beyond those, delivery runs through the dispatch network rather than resident staff. For any specific address, ask us to tell you which of the two applies — the answer materially changes lead time and cost, and we would rather say so up front.

How fast can an engineer start?

For dispatch work, the contractual SLA is four hours for emergency requests or next business day for standard ones. For an embedded or scheduled placement, the honest answer is a range that depends on how many hard requirements you have set — certification, language, clearance and site induction each narrow the pool, and they multiply rather than add. We will quote a range and name the binding constraint rather than give a single number we cannot hold.

Can we use our own ticket system?

Yes. Working inside your ITSM is usually the cleanest arrangement for a subcontracting MSP because it gives you a single audit trail you own and can show your client. It does require licensing and engineer training on your platform, which is a real cost to somebody and should be agreed commercially rather than assumed.

What are your minimums?

Dispatch is billed per visit with a first-hour and additional-hour structure and no prepayment requirement — the published dispatch rate table shows the structure across 42 countries. Dedicated engineers are a monthly commitment. Where a site is recurring and higher-volume, a token pack or a per-user managed plan is usually cheaper than paying dispatch rate every time, and we will say so rather than let you accumulate visits.

Do you work with our client directly, or only through us?

Whichever you specify. Many delivery-partner engagements run entirely through the prime contractor, with Brocent invisible to the end client. Others work better with a direct escalation path for out-of-hours incidents. What matters is that it is decided explicitly and written down, including what our engineer does if the end client asks them a commercial question on site.

Who owns the documentation?

You do, and by extension your client does. Customer-owned documentation and credentials is an included item in every Managed IT plan tier rather than a negotiated concession, and the same principle applies to delivery-partner work: asset records, site notes, network diagrams and known-issue history transfer at the end of the engagement in a portable form.

What are the payment terms?

Terms are agreed per engagement, and credit-term financing is one of the costs explicitly named as being inside our fully loaded rates rather than charged separately. If you need terms that differ materially from standard, raise it during scoping — it is a pricing input, not an afterthought, and a partner who accommodates unusual terms without repricing has almost certainly priced them in somewhere less visible.