One Engineer Is a Single Point of Failure: Leave Cover and Backfill for Onsite IT in Singapore

Short answer: one embedded engineer is a person, not a service. Annual leave, illness and resignation are certainties, not risks — and whether they are covered is a line in your contract, not an assumption. Before comparing two onsite quotes, find out whether both include backfill, because a monthly rate that covers absence is not comparable to one that does not.

A Singapore 3PL operator running two sites — a warehouse in Tuas and a smaller cross-dock closer to town — has one IT engineer. He is good. He has been there three years, he knows which forklift charger trips which breaker, and he can get a scanner back on the WMS in four minutes because he has done it two hundred times.

He also takes fourteen days of annual leave a year, occasionally gets sick, and will, at some point, resign.

Nobody in the business has ever written down what happens then. Not because they are careless, but because for three years nothing has happened that made the question urgent. The warehouse runs. The engineer is there. Until he is not.

This article is about what "covered" actually means in an onsite IT contract, what the four ways of buying redundancy actually cost, and why the instinct that buyers express — usually as "minimum two engineers, ideally three, for coverage and redundancy" — is often the right diagnosis attached to the wrong purchase.

The scenario: one engineer, two sites, an operation that cannot stop

Start with why this shape of business is different from an office.

In a 150-person professional-services firm, a day without IT is a slow day. People work from laptops, email still arrives on phones, and the worst case is an irritating backlog. In a warehouse or a light-manufacturing plant, a day without IT is a day without throughput. If the WMS is unreachable, pickers cannot pick. If the label printer on outbound is down, nothing ships. If the handheld scanners lose their wireless association at the far end of the racking, the count stops. These are not productivity problems; they are output problems, and they are measured in trailers that did not leave.

A second characteristic matters just as much: the work is physical. A remote engineer cannot reseat a scanner in a charging cradle, cannot re-terminate a cable a pallet truck pulled out of a floor box, and cannot walk to the far aisle to see whether the access point's LED is on. Roughly the share of incidents that needs hands is what justifies having somebody on site at all — that is the decision, and if you have not made it yet, our piece on industrial IT support in Singapore covers it in more depth.

This article assumes you have already made it. You have one engineer. The question now is what happens on the days he is not there.

The three absences, and why they behave completely differently

Treating "absence" as one category is the root of most bad decisions here. There are three, and they have almost nothing in common operationally.

Planned leave is the easy one, and it is the one most contracts actually address. It is known weeks in advance, it is usually a few days to two weeks, and it can be scheduled around known peaks. The right response is a named covering engineer who has been on site before, a handover note, and an agreement about what does and does not get done that week. Planned leave rarely causes damage; it causes deferral, and deferral is fine as long as somebody decided what to defer.

Sudden illness is the one that exposes whether cover is real. There is no notice. The covering engineer, if there is one, has to arrive without a handover, into a site they may never have visited, and be productive within hours. Everything that makes this survivable is documentation and access: a site runbook, credentials in a shared vault, a current asset list, and a security pass process that does not require the absent engineer to approve it. A contract that promises cover but has no documentation requirement behind it will deliver a person who stands in reception.

Resignation is the expensive one. It combines a notice period during which the incumbent is still there but disengaging, a recruitment or reassignment lead time, an induction period for the replacement, and a knowledge-transfer problem identical to the one a firm faces when its own sole IT manager resigns — except that here the knowledge belongs to your provider's employee rather than yours, which changes who is responsible for capturing it but not how much it hurts if nobody does.

Ask your provider about all three separately. A contract clause that says "leave cover provided" has answered the first and left the other two open.

What "no backfill" actually means on a rate card

Here is a real, checkable example from our own published pricing, because the distinction is easier to see in a real price book than in the abstract.

Brocent publishes two separate rate tables on the dispatch rates page. One is a 42-country table of per-visit dispatch rates — in Singapore, US$85 for the first hour and US$78 for each additional hour, at EUC L1, next business day, 9×5. The other is a seven-country table of monthly rates for a dedicated engineer, where Singapore sits at US$4,160 per month.

That monthly figure is labelled precisely: an indicative monthly rate at entry level, fully loaded, no backfill — and, in the same sentence, scaling by skill tier (roughly +21% for L2 and +44% for L3 against entry) with next-business-day backfill available.

Read that carefully, because it contains the entire point of this article. The headline monthly number buys you one engineer's time. It does not, by itself, buy you a second person for the days that engineer is not there. Backfill exists and can be bought — it is a named, purchasable thing — but it is priced separately from the entry rate, which is why the entry rate is as low as it is.

Meanwhile, the full-time onsite service page sells "Seamless Leave Cover" as one of its four named features: when your onsite engineer is on leave, a replacement is provided from a pool of trained engineers, and "leave and absence fully covered" appears in the stated benefits.

Those two things are not a contradiction, and it would be dishonest to present them as one. They are two different things you can buy, described accurately in two places. The service page describes the full-service onsite engagement; the rate table gives an entry-level unit price with the options stated alongside it.

But here is why it matters to you as a buyer: when you put three quotes side by side, you almost certainly have some that include cover and some that do not, and the ones that do not will look cheaper. That is not anyone cheating. It is what happens when a market prices a service in more than one shape. Your job is to normalise the comparison before you decide.

The practical version is a single question, asked identically of everyone quoting: *when my engineer takes two weeks' leave, who is on my site, is it included in this number, and what is their skill level?*

The four ways to buy redundancy

Once you accept that cover costs something, the question becomes what shape to buy it in. There are four, and they suit genuinely different operations.

Comparison: four ways to cover a single onsite engineer

A second full-time engineer

• What you get: true redundancy, both people know the site, absences overlap harmlessly, and you gain capacity rather than just insurance.
• What it costs: roughly double the monthly figure — the single largest step change available.
• The catch: at a single site with one shift, two full-time engineers are frequently over-provisioned. You are buying eight hours a day of capacity to solve a problem that occurs for perhaps twenty days a year. Unless the site genuinely generates enough work for two, the second engineer becomes underutilised, and underutilised engineers become bored engineers, who resign — which is the exact problem you were solving.
• Best when: two shifts, two sites needing simultaneous presence, or a genuine workload beyond one person.

A named pool with contractual cover

• What you get: your primary engineer plus a defined, named set of covering engineers who have been inducted at your site, with a contractual response for both planned and unplanned absence.
• What it costs: a premium on the monthly rate — real, but far less than a second head.
• The catch: cover is only as good as the induction. A "pool" whose members have never walked your warehouse floor is a list, not a capability. Insist that covering engineers do at least one shadowed day on site before they are needed.
• Best when: one site, one shift, an operation that cannot tolerate a bad week but does not need two people every day. This is the common right answer.

Dispatch as a safety net

• What you get: no standing second person, but a contractual arrival SLA when you need hands — Brocent's field dispatch service commits to four hours for emergency P1/P2 requests or next business day for standard ones, with arrival time contractual rather than best-effort.
• What it costs: nothing standing; per-visit rates when used.
• The catch: a dispatched engineer arrives with general skills and no site knowledge. They will fix a dead switch; they will not know that the scanner problem in aisle 14 is always the same access point. Dispatch covers incidents, not operations.
• Best when: the site can absorb short degradation, the estate is standardised, and documentation is genuinely good.

A remote-first layer with occasional hands

• What you get: monitoring, patching, ticketing and remote resolution running continuously regardless of who is on site, so that the onsite engineer handles only what genuinely needs a body.
• What it costs: a per-user monthly plan, priced independently of the onsite arrangement.
• The catch: it does not cover the physical half at all. It is not an alternative to onsite presence; it is what makes onsite presence smaller and more replaceable.
• Best when: always, honestly — as a layer underneath one of the other three rather than instead of them.

Why "minimum two, ideally three" is the right instinct and often the wrong purchase

Buyers articulate this requirement frequently and unprompted, in both English and Chinese, and the instinct behind it is completely sound: one person is a single point of failure, and a single point of failure in an operation that cannot stop is a real exposure.

Where it goes wrong is in jumping straight from the diagnosis to the most expensive prescription.

"Minimum two, ideally three" is the correct answer when you are staffing coverage hours — two shifts, or seven-day operation, or two sites that both need somebody present at the same time. There, you need multiple people because one person cannot be in two places or awake for sixteen hours.

It is frequently the wrong answer when you are staffing redundancy for a single eight-hour presence at one site. There, what you actually need is not two people employed full time; it is one person plus a guaranteed substitute. The failure you are insuring against occupies perhaps twenty to thirty days a year. Buying a second full-time engineer to cover thirty days means paying for roughly two hundred and twenty days you did not need.

The useful reframing is to separate the two requirements explicitly when you write the scope: *how many hours of presence do we need* is one question, and *what happens when the person providing them is absent* is a completely different one. Most scopes conflate them, and the conflation is what produces the "we need three engineers" conclusion that then gets rejected on cost, leaving the site with one engineer and no cover at all — the worst of the available outcomes.

What has to be true for cover to work at all

This section is the one most likely to save you money, because it is the reason cover fails even when it has been paid for.

A covering engineer can only be useful if four things are already true on the day they walk in.

Documentation exists and is current. A site runbook — network diagram, WMS and scanner architecture, the printer estate, what is on which VLAN, the three things that break most often and what to do about them, and the known workarounds. Not a folder of PDFs from the original installation. Something maintained as part of the engineer's job, with the maintenance written into the contract.

Access does not depend on the absent person. Credentials in a shared vault, not in his head or his personal password manager. Admin accounts that are not named after him. A second administrator on every system that has one. If your covering engineer's first action is to call the sick engineer for a password, you have not bought cover.

Site induction is already done. Security pass, safety briefing, PPE, forklift-aisle rules, who to report to, where the comms room is and who holds the key. At industrial sites this is frequently the binding constraint — a fully competent engineer who cannot get through the gate is not cover. And it cannot be done reactively: the induction process at most warehouses takes longer than the illness you are covering.

Escalation is defined and does not route through the absent engineer. Who the warehouse manager calls, what the covering engineer does when the problem is beyond them, and which vendor contracts allow somebody other than the named engineer to open a case.

The reason this list matters commercially is that every item on it is cheap to maintain and expensive to create in a hurry. A provider who builds these as part of normal service is selling you something different from one who will "arrange cover when needed", even if the monthly numbers look similar.

The resignation case, which is the expensive one

Leave and illness are interruptions. Resignation is a transition, and it needs to be handled contractually rather than hopefully.

Singapore notice periods for this kind of role are typically one to two months, and experienced infrastructure engineers with warehouse or plant exposure do not stay on the market long. So the sequence you should have agreed in advance is:

• Notification. How quickly does the provider tell you? Some contracts commit to informing the client within a set number of days of receiving the resignation, which matters because your planning window is their notice period.
• Replacement commitment. A contractual number of days to a named replacement, not "as soon as possible".
• Overlap. Whether the replacement arrives before the incumbent leaves, and who pays for the overlap. A week of overlap is worth considerably more than a month of documentation written alone, for the same reason a walkthrough beats a document in any handover.
• Knowledge capture. Whose responsibility is it to ensure the site runbook is current at the point of departure? If the answer is "the departing engineer, in his last week", it will not happen.
• Rate. Whether a replacement at a different skill tier changes your monthly cost, in either direction.

Notice that most of this is the same problem an internal team faces when its own IT person resigns. The difference — and the actual argument for buying onsite capacity as a service rather than employing it — is that your provider has other engineers, a documentation obligation, and a commercial incentive to make the transition invisible. An employer replacing an employee has a job advertisement and a gap.

Where the per-user plan fits underneath all of this

The reason to end on this is not that it is the sale; it is that it is the thing that changes the shape of the problem rather than just paying for it.

An onsite engineer at a warehouse spends their day on a mix of things. Some of it genuinely requires a body in the building: physical faults, cabling, device swaps, walking the racking with a spectrum analyser, helping a supervisor who will not raise a ticket. Some of it does not: password resets, patching, monitoring, software deployment, ticket triage, licence administration, reporting.

Every hour of the second kind that a remote layer absorbs is an hour that makes the onsite role smaller, more clearly defined and more replaceable. That is what a per-user managed plan does underneath an onsite arrangement — help desk, patch management, monitoring, backup, and the documentation and credential ownership that make a covering engineer productive on day one. Customer-owned documentation and credentials is an included item in every plan tier, which is exactly the prerequisite the "what has to be true for cover to work" section above is about.

The honest framing is this: a remote layer does not replace the person in the warehouse. It makes the person in the warehouse someone you can cover.

If you want to work out which of the four redundancy models fits your site, and what each costs against your actual absence exposure rather than in the abstract, talk to us — or start from the published rates and ask us to price cover as a separate line so you can see both halves.

Frequently asked questions

Is leave cover included?

It depends entirely on what you bought, and this is the question to ask before comparing prices. Brocent's full-time onsite service sells "Seamless Leave Cover" as a named feature with replacement from a pool of trained engineers, while the published entry-level monthly FTE rate on the dispatch rates page is explicitly labelled as fully loaded but without backfill, with next-business-day backfill available alongside it. Those are two different purchases described accurately in two places. Ask any provider — including us — which one their number represents.

What happens if our engineer resigns?

Contractually, that should be defined before it happens: how quickly you are notified, a committed number of days to a named replacement, whether there is an overlap period and who pays for it, and whose obligation it is to have the site runbook current at the point of departure. Practically, expect a transition rather than a swap — even an excellent replacement needs induction and site knowledge. The single biggest determinant of how painful it is, is how good your documentation was six months earlier.

How long does a replacement take?

Honestly, it is a range, not a number, and it depends on what filters you have set. Requirements for a specific certification, a particular language, prior warehouse or plant experience, or security clearance each narrow the candidate pool, and they multiply against each other rather than adding. Site induction is frequently the binding constraint rather than recruitment. Any provider quoting a single confident number without asking about those is guessing — a good one gives you a range and names which constraint is binding.

Will the cover engineer know our systems?

Only if you have paid for that, in one of two currencies. Either the covering engineers are a named pool who have been inducted and have shadowed at your site, or the documentation is good enough that a competent stranger can work from it. Ideally both. A cover arrangement with neither delivers a qualified person standing in your reception area waiting for someone to explain the building.

Can we share an engineer across two sites?

Yes, and it is often the right answer for a 3PL or a multi-site manufacturer — but be precise about what you are buying. A shared engineer is not present at either site full time, so you are trading depth of presence for cost. Define the split explicitly (which days at which site), define what happens when both sites have an incident simultaneously, and make sure travel time between them is accounted for in the rate rather than silently eating into your coverage hours.

Is two part-time engineers better than one full-time?

Sometimes, and it is an underused option. Two half-time engineers give you genuine redundancy without the cost of two full heads, and both know the site. The trade-offs are real: neither has continuous context, handovers between them become a recurring overhead rather than an occasional one, and it only works if the workload genuinely splits. It suits sites with predictable, repetitive support needs better than sites with long-running project work.

What does redundancy add to the cost?

There is no single figure, because it depends on which of the four models you choose. A second full-time engineer roughly doubles the monthly cost. A named pool with contractual cover is a premium on the monthly rate that is substantially less than a second head. Dispatch as a safety net costs nothing standing and is billed per visit — the published rate for Singapore is US$85 for the first hour and US$78 for each additional hour. A remote layer is priced per user and is independent of all three. The right comparison is not which is cheapest, but which matches your actual exposure: how many days a year you are uncovered, and what a bad one of those days costs your operation.