Four Properties, One IT Person, No Weekends Off: A Singapore Hospitality Group

In short: A Singapore hospitality group's only IT manager resigns with a month's notice, and nobody else knows how four properties actually run. The fix is not hiring another generalist — it is replacing one person's knowledge with a layered service: monitoring, a helpdesk that matches operating hours, owned security, tested backups, and a named vCIO.

What Happens When the Only Person Who Knows How It Works Hands in Notice

There is a particular quiet that falls over an operations meeting when someone says the IT manager has resigned. It is not panic. It is the moment everyone in the room independently realises that they do not know how any of it works, and that the person who does has thirty days left.

This article follows an illustrative Singapore composite — not a named client, and not a real company. A hospitality group runs four properties: two small hotels, a restaurant that also does events, and a café-bar attached to one of the hotels. About 150 staff in total across the properties, plus a lean head office. One IT manager. He has been there six years, he is very good, and he has just accepted a role somewhere that does not call him on Sunday nights.

The composite is constructed from the pattern that repeats across small multi-site operators in Singapore. If you run four properties on one person's knowledge, some of the detail below will be uncomfortably familiar.

Why Small Hospitality Groups in Singapore Are Unusually Exposed

Hospitality is a harder IT environment than its headcount suggests, and people outside it consistently underestimate this.

The systems mix is wide, not deep. A 150-staff professional services firm has laptops, Microsoft 365, a file server or a cloud equivalent, and a finance package. A 150-staff hospitality group has all of that *plus* a property management system with local integrations, point-of-sale terminals in three different configurations, a guest Wi-Fi network that is a marketing asset rather than a convenience, door-lock and key-card systems, back-of-house printers that print orders to the kitchen, a booking channel manager, and a small forest of networking equipment in cupboards that were never designed to hold networking equipment. None of it is individually complicated. Collectively it is a very large surface for one person.

Operations genuinely never stop. This is the part that makes hospitality different from retail, which at least closes. A hotel's front desk runs overnight. The restaurant's busiest hours are exactly the hours an office-based IT function is not working. A point-of-sale terminal that fails at 19:40 on a Saturday is not a ticket — it is a queue of people holding credit cards while a manager writes orders on paper.

Every failure is visible to a paying guest immediately. In most businesses an IT problem is an internal inconvenience for some period before it becomes a customer problem. In hospitality there is no buffer. Slow Wi-Fi in a hotel room is a one-star review with a specific complaint in it. A key-card that does not work is a guest standing in a corridor with luggage. The reputational cost arrives at the same moment as the technical fault.

And the IT function is almost always one person, or none. The economics do not support two. A group this size cannot justify a second IT hire, and so it employs one unusually capable generalist and quietly accepts a single point of failure — usually without ever writing that acceptance down anywhere.

The Month of Notice Is When You Find Out What You Actually Own

Here is what the composite group discovered during those thirty days, roughly in the order they discovered it.

The documentation does not exist. Not "is out of date" — does not exist. There is a folder on a shared drive containing supplier invoices, two network diagrams drawn during a 2023 refit that no longer describe either property, and a spreadsheet of device serial numbers last touched eighteen months ago. What the group actually has, nobody can produce on paper.

The credentials live in one head and one personal password manager. Some are written down. The administrator account for the property management system's local components is not among them. Neither is the account that the booking channel manager authenticates with, because that was set up during an integration project by a vendor who dealt exclusively with the IT manager.

The vendor relationships are personal, not institutional. The POS vendor's support line is technically a corporate arrangement, but in practice things get fixed because the IT manager knows which engineer to text. The company's actual contractual entitlement — response times, what is covered, what is billable — has never been read by anyone still employed there.

There is no coverage model, only a person. Nights and weekends were covered because he answered the phone. That was never a policy, never a rota, never a cost line. It was a person's goodwill, and goodwill does not transfer with the job title.

Nobody has assessed the security position, because the only person who could assess it is leaving. Which accounts still exist for staff who left last year? Are the guest network and the back-office network genuinely separated, or only nominally? When was anything last patched? These are not rhetorical questions in the composite — they are questions with no one left to ask.

The knowledge cliff is the real failure mode. A gradual handover is a document being updated. This is a cliff: on day thirty-one the information is simply gone, and the only way to recover it is to rediscover it the expensive way, one incident at a time.

Brocent's Perspective: The Failure Here Is Structural, Not Personal

It is tempting to frame this as a documentation failure — if only he had written things down. That reading is comfortable and wrong.

One generalist cannot cover four always-on properties seven days a week. Not this one, not a better one. He was not underperforming; he was absorbing, single-handedly, a workload that the organisation had never sized. The documentation did not get written because the person who should have written it spent his week being the reason nothing had broken yet.

Which leads to the conclusion that matters commercially: replacing him with another single generalist recreates exactly the same risk, and adds a ramp-up period on top. The new hire will spend three to six months rediscovering the estate, will accumulate the same undocumented knowledge, will also answer the phone on Sunday, and will also, eventually, resign. The group will have bought another few years of the same exposure at a slightly higher salary.

The question to ask is not "who replaces him?" It is "what did he actually do, and what structure does each of those things properly belong in?" Unbundled, his job was at least five different jobs:

• Watching things. Noticing when a switch, a server or a link was unhealthy — in practice, noticing *after* someone complained.
• Fixing things when people asked. The helpdesk function, delivered during whatever hours he happened to be awake.
• Keeping the place secure. Accounts, patches, network separation, the guest/internal boundary — owned in theory, deferred in practice.
• Making sure data could come back. Backups configured once and rarely, if ever, tested by restoring something.
• Deciding what to do next. Which systems to replace, what to budget for, what the refit needs — the roadmap, carried in his head and negotiated verbally.

Those five are precisely the five things a managed IT plan is built to carry. Monitoring that does not sleep. A helpdesk sized to the hours the business actually runs, not the hours an office is open. Security governance with a named owner. Backup and disaster recovery that is tested rather than assumed. And a virtual CIO who holds the roadmap — which is the part that most directly fixes the original problem, because a roadmap held by a service is a roadmap that stays in the company when an individual leaves.

That is the argument for an outsourced managed plan here, and it is worth being precise about what the argument is not. It is not "outsourcing is cheaper than a salary" — sometimes it is, sometimes it is not, and we have written the honest version of that arithmetic for Singapore separately in managed IT versus an in-house team. The argument is that four properties running seven days a week need a *structure*, and one employee is not a structure.

What the Transition Actually Looks Like

The most valuable asset the group has in this situation is the thing that feels most like a countdown: the notice period. Used badly, it is a rushed brain-dump into a Word document nobody reads again. Used well, it is a structured discovery window with someone competent asking the questions.

The difference is who is doing the asking. A departing employee writing documentation alone will write down what he thinks is important, which is not the same as what an incoming service needs to know. A transition team runs it the other way round: it arrives with a list of what must be captured and works through it while the only person who knows the answers is still contractually obliged to give them.

Brocent's structured onboarding is a three-month transition, and the shape of it matters more than the branding:

• Weeks 1–2, survey and IT audit. Physical site visits — roughly a day per site to begin with — documenting what is actually installed, not what the invoices say was installed. In a four-property group that means four visits, each of which will find something nobody mentioned.
• Weeks 2–4, knowledge transfer. The structured interrogation of the departing engineer: how the property management system's integrations are wired, which vendor holds which contract, what the workaround is for the thing everyone has a workaround for.
• Weeks 3–6, shadow and re-shadowing. Incoming engineers work tickets alongside the existing arrangement, then run them unsupervised while the knowledge is still verifiable. This is where wrong assumptions surface — before they surface at 19:40 on a Saturday.
• Month 3 onwards, service go-live. Full managed service, with an asset inventory that exists as a maintained record rather than a spreadsheet.

Two practical notes on scope, because this is where hospitality-specific expectations need to be set honestly. Payment terminals remain a vendor-owned boundary. Card-present payment devices sit inside their provider's own compliance and support perimeter; a managed IT provider coordinates with that vendor and makes sure the network underneath behaves, but does not take the terminals over. And the property management system is supported at the layer where support is actually possible — the servers, the network, the workstations and the integrations around it — while the application itself stays with the software vendor who publishes it. Anyone who tells you otherwise is selling you something they cannot deliver.

Comparison: Three Ways to Replace One IT Manager

Hire another generalist

• What you get: A single person who, once ramped up, holds the whole estate again and is genuinely responsive when present.
• What it costs: A full salary plus employer contributions, recruitment time, and three to six months before the new hire is more useful than disruptive.
• The structural problem: You have re-created the single point of failure, including the undocumented-knowledge problem, and you will be reading this article again in four years.
• Coverage reality: One person, one set of working hours. Nights, weekends and annual leave are still covered by goodwill or not at all.
• When it is genuinely right: If the group is about to double in size and needs an internal IT leader — but then you are hiring a *manager of a service*, not a person to fix POS terminals.

Stitch together point vendors

• What you get: The POS vendor supports POS. A networking contractor handles Wi-Fi. A break-fix shop handles desktops. Each is competent at its own thing.
• What it costs: Individually reasonable; collectively opaque, because nothing is a fixed monthly line and every incident is billable.
• The structural problem: Nobody owns the boundary between vendors, and every real incident lives on a boundary. The Wi-Fi contractor says it is the ISP; the ISP says it is the firewall; the POS vendor says the terminal is fine. Somebody internal has to arbitrate, and that somebody just resigned.
• Coverage reality: Business hours for most, with out-of-hours available as an emergency call-out rate if it is available at all.
• When it is genuinely right: For a single-site operation with a simple estate and a capable operations manager willing to own coordination.

An outsourced managed plan with a named vCIO (the Brocent model)

• What you get: 24×7 monitoring, a helpdesk with defined hours and escalation, security governance with an owner, backup and DR that is tested rather than assumed, and a named vCIO who holds the roadmap and meets you on a cadence.
• What it costs: A published per-user, per-month figure. In Singapore the plan tiers currently list at S$126.36 per user per month (Startup), S$185.08 (Established) and S$227.20 (Growth), with Enterprise custom-quoted — figures read from the live pricing page at the time of writing, which is where you should re-check them rather than trusting a blog post. Infrastructure add-ons are priced separately and visibly: Network & Wireless at S$113.60 per month covering up to ten devices, Cloud Backup at S$18.70 per device per month.
• The structural problem it solves: The knowledge lives in a documented estate and a service organisation rather than in one person. When an individual engineer moves on, the group does not have a crisis.
• Coverage reality: Monitoring is continuous. Helpdesk hours and response targets are contractual, which means they can be argued about in advance rather than discovered during an outage.
• The honest caveat: It is not a person sitting in your office. If a property genuinely needs someone physically present most days, that is a different conversation — onsite presence is available, but it should be bought deliberately rather than assumed.

What to Do in the Next Thirty Days

If you are reading this during a notice period, the sequence that matters is short:

1. Stop treating the handover as the departing employee's homework. Put a structured discovery process around it, with someone whose job is to ask the questions.

2. Capture credentials into an institutional system this week, not in the final fortnight. This is the single highest-risk item and the one most often left until last.

3. Get the contracts read. What does the POS vendor actually owe you? What is the property management system's support entitlement? These answers change what you need to buy.

4. Decide the coverage model before you decide the supplier. What hours genuinely need cover, and what happens at 02:00? Answer that first, then price against it.

5. Do not hire in a panic. The worst version of this story is a rushed replacement hire who inherits an undocumented estate and leaves in eighteen months.

Brocent has run Singapore as its global headquarters since 2021, with the group's operating history going back to its founding in Beijing in 2007 and a Hong Kong office since 2016. For Singapore-specific service detail, our Singapore IT support page covers the local delivery picture. If you want to talk through a transition — including one that starts inside a notice period — get in touch.

Frequently Asked Questions

Can outsourcing really replace an in-house IT manager?

It can replace the *functions*, which is the useful way to think about it. Monitoring, helpdesk, security ownership, backup and roadmap are all deliverable as a service, and delivered more reliably than one person can manage across four always-on sites. What outsourcing does not replace is physical presence and institutional familiarity — a provider learns your estate during transition rather than knowing it already. Groups that make this work tend to keep a business-side owner internally: an operations person who holds the relationship and makes decisions, rather than an engineer who fixes things.

What happens during the handover month?

Ideally, a structured discovery process rather than a brain-dump. Site visits to document what is physically installed, interviews with the departing engineer against a checklist, credential capture into an institutional store, vendor contract review, and shadowing on live tickets so assumptions get tested while the person who knows the answers is still there. The goal is that on day thirty-one there is a documented estate, not a folder of invoices.

Who covers nights and weekends?

Monitoring is continuous under a managed plan — systems are watched around the clock whether or not anyone is at a desk. Helpdesk attendance during specific hours is a separate, contractual question, and hospitality is exactly the sector where it needs to be answered explicitly rather than assumed. Decide what genuinely requires a human response at 02:00 versus what can wait until 07:00, and buy against that answer. Be sceptical of anyone who agrees to everything without asking what your Saturday evening actually looks like.

What about our property management system and POS vendors?

They stay. A managed IT provider supports the layer those applications depend on — servers, network, workstations, integrations, connectivity — and coordinates with the software vendors rather than replacing them. Payment terminals in particular remain inside their provider's own perimeter; the sensible arrangement is that your IT provider makes sure the network and infrastructure underneath behave, and that someone competent is in the room when the vendor says the problem is at your end.

Is outsourcing more expensive than one salary?

Sometimes, and it depends on what you are comparing. A fair comparison counts the full cost of employment rather than base salary, and counts what the single-hire model does not include — out-of-hours coverage, holiday and sick-leave continuity, specialist security skills, and the risk cost of the knowledge cliff. We have written the Singapore-specific version of this comparison in managed IT versus an in-house team, and the per-user plan figures are published on the pricing page so you can do the arithmetic against your own headcount.

What happens to the systems documentation?

Under a managed plan it becomes a maintained asset inventory rather than a document, which is the important difference. A document written during handover is accurate for about a month. A maintained inventory — devices, configurations, contracts, who owns what — is updated as changes happen, and it belongs to the group rather than to whichever engineer last touched it. Ask any prospective provider what the documentation deliverable is and whether you keep it if you leave.

How long does the transition take?

Brocent's structured onboarding is scoped as a three-month transition: survey and audit in weeks one and two, knowledge transfer in weeks two to four, shadowing and re-shadowing in weeks three to six, and full service from month three. Starting inside a notice period compresses the most valuable part — the knowledge transfer — into whatever window remains, which is why the first call matters more than the contract date.

Can we keep some IT in-house?

Yes, and for many groups it is the right answer. A common split is that the group keeps a business-side IT owner — someone who holds vendor relationships, approves changes and sits in the vCIO cadence — while the delivery layer is outsourced. That person is a coordinator, not an on-call engineer, which means the role is survivable and the group is not back in the same position when they take annual leave.