On-Call Onsite IT Support in Asia: Taipei and Kuala Lumpur Rates, SLAs and Setup

On-call onsite IT support in Asia can be reactive-only for two small offices, as long as three things are written down before the first incident. Who is allowed to call, what the engineer may touch, and how fast "immediately" really is in each city. This guide shows how that works across Taipei and Kuala Lumpur, what the published rates add up to, and where it quietly fails.

Which two offices are we talking about, and what actually needs hands?

Picture the APAC infrastructure lead at a multinational software group. Two of the group's smaller offices sit in her region: a 22-person office in Taipei and a 16-person office in Kuala Lumpur. Neither has an IT person. Both have laptops, a Wi-Fi network, a switch in a cupboard, a couple of meeting rooms with video screens, and a shared printer. The lead does not have headcount for either site, but she does have a budget line for incidents.

An important note before going further. This is an illustrative composite scenario, not a named client. It is assembled from the shape of a request that comes up repeatedly: a buyer who has already decided on reactive-only onsite support, for two countries, with no fixed visit pattern. If you are still choosing between embedded, scheduled and on-call patterns for a single site, that is a different question and is covered in our article on onsite IT support models in Hong Kong. This article starts after that decision has been made.

So what actually needs a person standing in the room? Remote support handles most of a small office's IT life: password resets, software, licences, mailbox problems. The incidents that need hands are a short and rather physical list.

• The network is down and the cause is physical. A switch has failed, a patch lead has come loose, a power supply has died, or the internet line is up at the street cabinet but not in the room. Remote engineers can see that the office has fallen off the network. They cannot see why.
• A meeting room will not work before a customer call. The camera, the speakerphone or the display is dead, and there is a meeting in forty minutes.
• A laptop is dead before a demonstration. The device will not boot, and a replacement has to be imaged, handed over and signed for. The person who needs it is flying out tomorrow.
• Something has to be moved, plugged in or collected. A new starter's equipment arrives and needs unboxing, or a failed device has to be returned.
• A printer, a rack or a small piece of kit has failed and nobody on site can tell whether it is the device or the cable.

Notice what these have in common. They are rare in any single month, they are urgent when they happen, and nobody can predict which month. That pattern is exactly why a fixed monthly visit schedule feels like paying for nothing, and why this buyer chose a reactive model.

Why is reactive-only rational at this size?

At 16 to 22 people, an office does not generate enough predictable onsite work to keep an engineer busy. A dedicated engineer is a monthly commitment whether or not anything breaks. A scheduled visit is a smaller commitment, but it still bills for a block of hours whether or not anything was wrong.

On-call dispatch inverts that. You pay when something happens, and you are billed after the job rather than in advance. The dispatch rates page describes a dispatch visit as a straight per-visit price with no prepayment, billed after the job on standard 30-day credit terms and itemised by ticket. For a company with a budget line for incidents rather than one for headcount, that is the right shape of cost.

There are three honest reasons this works at this size.

1. Most of the work is already remote. If the remote layer resolves the large majority of tickets, the physical remainder is small and lumpy. Paying per event matches that.

2. Two offices in two countries multiply the cost of fixed patterns. A monthly visit in each city is two commitments, two sets of access arrangements and two invoices. A single dispatch relationship across both is simpler. The field dispatch service page describes coverage in 100+ countries via a single contract, which is the mechanism that makes "one provider, two countries" possible.

3. The cost of being wrong is bounded. If one month produces three incidents, you pay for three visits. You never pay for a visit that was not needed.

It stops being rational when volume rises, or when the incidents are caused by things that a visit could have prevented. We come back to that later, with numbers.

What has to be in place before the first call?

The failure of reactive-only cover rarely comes from the engineer. It comes from a cold dispatch: a stranger arrives at a door they have never seen, with no idea where the cupboard is. Five pieces of pre-work turn a cold dispatch into a warm one, and all of them cost nothing in rate terms.

A site pack

One page per office, kept where the dispatch desk can reach it. It should hold the address and floor, the building's opening hours and any after-hours restrictions, the reception arrangements, the location of the comms cupboard and the meeting rooms, the make and model of the main network equipment, and a photograph of the cupboard. A photograph saves the first ten minutes of every visit.

Access

In many commercial buildings in both cities, an engineer who is not on a visitor list is turned away at the lobby, however urgent the problem. Decide in advance who can add a visitor, and how. Agree whether the engineer can enter outside office hours and who will let them in. This is the single most common reason that "immediately" turns into "tomorrow".

A current network diagram

Not a work of art. A single sheet that shows the internet line, the router or firewall, the switch, the access points and the main devices, with the IP addressing and the administrator contact for each. If this does not exist, the first engineer builds it on your time and at the hourly rate.

A named local contact and a spare

Name one person in each office, with a mobile number, who can say "yes, let them in" and "no, do not reboot that". It does not have to be a technical person. It does have to be someone who is reachable. And if a single piece of equipment is critical, such as a switch or an access point, consider keeping a configured spare in the cupboard. A configured spare turns a half-day outage into a ten-minute swap.

A written authority list

Three short lists: who is allowed to raise a dispatch, what the engineer is allowed to touch (the cupboard, the meeting-room equipment, the user's laptop) and what needs a separate approval (changing the firewall, replacing a device that holds data, anything that affects the whole group). This is the second of the three things in the summary at the top, and it is the one that most often goes unwritten.

The network and hardware maintenance service is the place to look if you want the site pack, the diagram and the spares maintained as a service rather than as a document that goes stale.

What does "4-hour" or "next business day" mean in Taipei and Kuala Lumpur?

Here the wording matters, and it is where most expectations go wrong. Brocent publishes several things that sound similar and mean different things.

• The rate table basis. The dispatch rate table on the pricing page is stated as EUC L1, next-business-day, standard 9x5 coverage. The rate you see for Taiwan and Malaysia is for that basis.
• The SLA tiers. The same page lists three coverage options. Normal business hours (8x5) has a next-business-day onsite response. Extended hours (8x7) has same-day onsite. The 24x7 emergency tier has a 4-hour onsite response.
• The field dispatch page. It states a 4-hour emergency or next-business-day dispatch SLA, and that the arrival-time SLA is contractual.
• The country pages. The Taiwan and Malaysia landing pages each state a 4-hour onsite response target for P1 and P2 incidents in a defined service area, supported by remote triage.

So "immediately" is not one thing. A broken switch that stops a 22-person office from working is a P1 or P2 and can fall under the 4-hour model, within the defined service area. A dead laptop with a demonstration next week is a standard request and falls under next business day. The rate table gives you a price for the standard basis. It does not give you a price for the emergency tier, and the scenario profiles on the rate page say only that after-hours work is typically billed at an after-hours multiple of the local dispatch rate. That multiple is not published as a number, so it is a question for the quote.

What "defined service area" means in each city

For Taiwan, the Taiwan landing page describes Taipei as the primary anchor, with coverage designed for Taoyuan, Hsinchu Science Park, Taichung and Kaohsiung depending on SLA and project scope. For Malaysia, the landing page describes Kuala Lumpur and Klang Valley as the direct service area, with Penang, Johor Bahru and Cyberjaya coordinated under the same delivery model.

The practical lesson is to write your offices' exact addresses into the contract and ask the provider to confirm, in writing, which response window applies to each. An office in central Taipei and an office in a distant industrial park do not get the same answer to "how fast".

What Brocent says about its presence in each country

The company's office dataset lists a Taipei service centre in the Xinyi District, operating through the local entity Taiwan Bro Cloud IT Service, with offices in Taipei and Kaohsiung. It lists a Kuala Lumpur service satellite site operating through Brocent Cloud Service (Malaysia). The Taiwan landing page says "15+ local certified engineers". The Malaysia landing page describes local engineers covering Klang Valley, Cyberjaya, Penang and Johor Bahru. We state these as published on the site on the day of writing, and we do not add to them. Any contract will name the actual contracting entity, and that is the document to rely on.

What do the published rates add up to?

Now to the arithmetic. The figures below come from the on-site dispatch rate table on the dispatch rates page, as published on 2026-10-05. They are USD, tax exclusive, indicative 2026 H2 standard price book rates for EUC L1, next business day, 9x5, city-centre. The page describes each rate as covering a first-hour minimum plus travel within the metro or central business district area, with each additional hour billed at a lower rate.

• Taiwan: first hour US$91, each additional hour US$78.
• Malaysia: first hour US$65, each additional hour US$59.

Everything below this line is illustrative arithmetic on those published rates. It is not a quote, and it ignores tax, the after-hours multiple, parts, and any volume pricing.

A single visit

• A one-hour fix: Taipei US$91, Kuala Lumpur US$65.
• A two-hour visit (first hour plus one additional hour): Taipei 91 + 78 = US$169, Kuala Lumpur 65 + 59 = US$124.
• A four-hour visit (first hour plus three additional): Taipei 91 + 3 x 78 = US$325, Kuala Lumpur 65 + 3 x 59 = US$242.

A year of reactive cover

Suppose each office has eight two-hour incidents in a year, which is a plausible figure for a small, remote-first office, but is an assumption and not a statistic. Taipei: 8 x 169 = US$1,352. Kuala Lumpur: 8 x 124 = US$992. Together, US$2,344 for both offices over the year, at the standard-basis rate. Even if the number of incidents doubled, the total would be a small fraction of the cost of a person.

When does a scheduled visit become cheaper?

Assume, for illustration only, that a monthly scheduled four-hour visit is billed at the same rate card. Brocent's service page says scheduled preventive visits are available, but does not publish a separate rate for them, so this is an assumption to confirm with a quote.

• Taipei: one four-hour visit a month is US$325, or US$3,900 a year.
• Kuala Lumpur: one four-hour visit a month is US$242, or US$2,904 a year.

Compare each with a reactive two-hour visit: Taipei US$169 and Kuala Lumpur US$124. The scheduled visit costs about 1.9 reactive visits in Taipei (325 / 169) and about 1.95 in Kuala Lumpur (242 / 124). In plain words, a monthly scheduled visit pays for itself only if it prevents roughly two reactive visits every month. For a 16 to 22 person office, that is a high bar. If your office is generating two or more physical incidents a month, switch to a scheduled visit. If it is generating fewer than that, stay reactive.

When does a dedicated engineer become cheaper?

The dedicated engineer rate table has a Malaysia row but no Taiwan row. Malaysia's entry-level dedicated engineer is published at US$1,820 a month. Divided by the US$124 reactive two-hour visit, that is about 14.7 visits a month. A small office will never reach that, which is why a dedicated engineer is a decision for a campus site and not for this buyer. For Taiwan, no dedicated-engineer rate is published, so a comparison cannot be made from public data.

What is not in these numbers

Parts and replacement equipment are not part of the visit rate. The dispatch rates page says local tax invoices are issued the same way as for its prepaid Token Service packs. The Taiwan and Malaysia landing pages mention local billing in TWD and MYR, while the rate table is in USD, so ask which currency your invoice will be in. And the page notes that multi-site and multi-country programmes price below the single-ticket rates shown. Two offices in two countries under one contract is exactly that kind of programme, which is a reason to ask for a combined quote rather than reading the table line by line.

What about language?

Language is a practical issue, not a courtesy. The engineer will be talking to someone who is under pressure and who may not be technical.

In Taipei, the working language of the office is Mandarin, with English in the software group's own tools. The Taiwan landing page lists English and Traditional Chinese support. In Kuala Lumpur, the office may work in English, Bahasa Malaysia, Mandarin or a mix. The Malaysia landing page lists English, Bahasa Melayu and Mandarin.

Two things follow. First, put the language requirement into the dispatch request, not just the contract: "reception speaks Mandarin only" is useful information for an engineer to have before the visit. Second, keep the site pack in English and, where the local contact prefers, in the local language as well. The engineer may be reading the diagram in a stairwell on a phone, and an unreadable diagram is no diagram at all.

What is the failure mode, and how does a remote layer fix it?

Here is the quiet failure. On-call dispatch is a series of strangers. The engineer who comes to Taipei in March is not the one who came in January, and neither of them knows what the other found. Every visit starts with "what is the setup here?" You are paying the hourly rate for the same ten minutes of orientation each time.

A reactive-only arrangement also has no memory of its own. Nobody is looking at the estate between incidents. A switch that has been reporting errors for three weeks stays quiet until it fails on the morning of a customer demonstration, at which point the incident is urgent and probably after hours.

The fix is not more visits. It is a remote layer that knows the estate. That means a service desk that holds the site pack and the diagram, a record of what was changed on each visit, monitoring that raises the failing switch before it fails, and a single team that briefs the engineer before they leave. The engineer is still a stranger, but a stranger who has been briefed by someone who knows the office.

This is what field IT dispatch looks like when it is the hands layer of a larger service rather than a stand-alone booking. The Brocent field dispatch page describes the request going through the helpdesk or ITSM platform, with the arrival-time SLA being contractual, and the dispatch rates page says each visit closes with a signed service report that records the start and end time. That signed report is the thing that builds the memory.

Reactive dispatch only, reactive plus a monthly visit, or reactive plus a remote managed layer?

This is the comparison most buyers in this position are really making. Here are the three, side by side, using the numbers above.

Compare the three patterns

• Reactive dispatch only. Cost: pay per incident, with the rates above and no standing commitment. Strength: nothing to pay in a quiet month, and the simplest contract. Weakness: every visit is a cold start, nobody is watching between incidents, and the cost is lumpy. Best for: a pair of small offices with low incident volume, a strong local contact and a site pack that has been written.
• Reactive plus a scheduled monthly visit. Cost: a standing block of hours each month in each city, plus reactive visits on top. At the published rate card, a four-hour monthly visit is about 1.9 reactive visits in Taipei and about 1.95 in Kuala Lumpur. Strength: a regular face, and a chance to fix small things before they fail. Weakness: you pay for the visit even when nothing is wrong. Best for: offices with two or more physical incidents a month, or with equipment that benefits from routine checking.
• Reactive plus a remote managed layer. Cost: a per-user monthly plan covering the remote service, with dispatch visits still billed per event. Strength: the briefed stranger. The remote team knows the estate, records every visit and spots the failing switch early. Weakness: a recurring cost that exists whether or not an incident occurs. Best for: groups that want the small offices to behave like the large ones without a local hire.

None of these is wrong. The mistake is choosing the first and expecting the benefits of the third.

How do you move from visits to a per-user plan?

The honest bridge between these options is the per-user managed IT plan. It does not replace the dispatch relationship. It sits underneath it.

The managed IT support page publishes per-user monthly plans in four tiers (Startup, Established, Growth and Enterprise), with the Established tier listed for businesses of 5 to 300 employees. Brocent's pricing data for those plans covers four markets: Hong Kong, Singapore, mainland China and the United States. Taiwan and Malaysia are not among the published per-user markets, so there is no public per-user price for either office, and we will not estimate one. A plan covering Taipei and Kuala Lumpur needs a quote. That is worth knowing before you plan a budget around a public figure that does not exist.

What the plan changes is the economics of the cold start. The remote layer holds the site pack, the diagram and the visit history. It watches the equipment. It briefs the engineer. The dispatch visit is still billed per event, but each one is shorter, because the engineer arrives informed. For a software group that wants its smallest offices to feel supported, but not at the cost of a local hire, that is usually the most sensible destination.

Start with the three written lists from the beginning of this article. They are free, and they make every pattern work better. Then watch your incident volume for a quarter. If it stays below two physical incidents a month in each city, you can stay reactive. If it rises, or if the same equipment keeps failing, move to a monthly visit or a remote layer.

Frequently asked questions

How fast can an engineer reach a Taipei office?

It depends on the severity and the tier. Brocent's published materials state a 4-hour onsite response target for P1 and P2 incidents in the defined Taiwan service area, with Taipei as the primary anchor. A standard request falls under next business day, which is the basis of the published rate table. We have not found a published travel time for specific districts, so ask for the response window to be confirmed in writing for your exact address.

Is there a minimum charge?

The rate table has a first-hour rate and a lower additional-hour rate, and the page describes the first hour as a minimum that includes travel within the metro or central business district area. The page does not publish a separate minimum charge beyond that. Ask for the minimum, the after-hours multiple and any out-of-area travel charge to be stated in the quote.

Can the same provider cover both countries under one contract?

Brocent's field dispatch page describes coverage in 100+ countries through a single contract, and lists Taiwan and Malaysia in the dispatch rate table. Brocent also lists local entities in Taiwan and Malaysia in its office dataset. Which entity signs, and in which currency it invoices, is a contract question, so ask for it in writing. The dispatch page also says that multi-site and multi-country programmes price below single-ticket rates.

What if the fix needs a part?

The visit rate covers the engineer's time and travel within the metro area, not parts or replacement equipment. For a small office, the sensible approach is to keep a configured spare for the one or two items that would stop the office, such as a switch or an access point, and to agree in advance who is allowed to approve a purchase. The dispatch rate does not make a part appear. A spare does.

Who briefs the engineer?

In a stand-alone dispatch arrangement, nobody does, unless you do. That is the failure mode described above. With a remote service desk that holds the site pack and the visit history, the desk briefs the engineer. The dispatch rates page describes requests going through the helpdesk, which assigns an engineer and provides a ticket number and an estimated arrival time, and closing with a signed report.

Is the published rate what we will actually pay?

No, and the page says so. The rates are indicative, fully loaded, and for the standard basis. The page states that they fall at higher volumes and that scenario profiles are illustrative and are not a quote. Use the table to understand the order of magnitude, then ask for a quote that reflects two offices, two countries, your response windows and any after-hours cover.

When should we switch to a scheduled visit?

When your office produces roughly two or more physical incidents a month, or when the same equipment keeps failing. The arithmetic in this article suggests that a four-hour monthly visit costs about as much as two reactive two-hour visits, so it pays for itself only if it prevents about that many. Below that volume, stay reactive and invest the difference in the site pack and the written authority lists.

Where do you go from here?

If you are running two small offices in two countries and want to keep onsite cover reactive, the work is mostly writing things down. Write the site pack, agree the access arrangements, draw the network, name the local contact and write the authority list. Then look at the dispatch rates and ask for a quote that reflects both offices.

If you would like to see how a remote managed layer would sit under that arrangement, start with the managed IT support overview, or look at the pricing page for the plans and the markets they cover. When you are ready to talk about Taipei and Kuala Lumpur together, contact us with your two addresses and your expected incident volume.