Month-End Close Doesn't Care That You're a Shared Services Centre

Short answer: A shared services centre is a processing operation, not a commercial office. Its IT load is driven by the finance calendar rather than by headcount, its users sit in Singapore while its customers sit in ten other markets, and its critical systems mostly belong to somebody else. Support that models the average day will fail on the days that matter.

The regional IT manager of a European lifestyle retailer's Singapore shared services centre put it to us plainly: "Nobody's IT ticket is urgent on the fourteenth of the month. On the second working day, every ticket is urgent, and it's the same forty people every time."

That sentence contains almost everything that makes IT support for a shared services centre a different problem from IT support for a regional headquarters of the same size — and it is the reason a perfectly reasonable per-user support contract can feel adequate for eleven months and inadequate for one.

This is an illustrative composite scenario, not a named client. It is grounded in real Brocent project work described below, and every service mechanic mentioned is a real part of what Brocent does. No pricing figures, statistics or client names have been invented.

What makes IT support for a shared services centre different?

Search for IT support service in Singapore and you will find a market that mostly assumes one shape of customer: a company whose people work in Singapore, on Singapore business, during Singapore hours. Regional headquarters, sales offices, funds, agencies, SMEs. That assumption is embedded so deeply in how support is scoped and priced that it usually goes unstated.

A shared services centre breaks the assumption in four specific ways, and each one has a concrete operational consequence.

Its workload is periodic rather than steady. A commercial office has a fairly flat demand curve; a processing centre has a month-end, a quarter-end and a year-end, and the difference between a quiet Tuesday and the second working day of the month is not marginal.

Its users are internal but its customers are external — other countries. When a payables clerk in Singapore cannot access a system, the person who feels it is a supplier in Malaysia or a store manager in Thailand. The blast radius of a Singapore desktop problem extends across a region.

Its working day is stretched at both ends. Supporting markets from Japan to India means the earliest and latest hours are not edge cases; they are when a meaningful share of the work happens.

And its critical systems are largely not its own. The ERP is head office's. The HR system is head office's. The banking portals belong to banks, the tax portals belong to governments, and the market-specific systems belong to the markets. The SSC's IT team is responsible for access to a portfolio of systems it does not control.

None of these is exotic. Together they produce a support profile that a standard scoping conversation will not surface, because nobody asks "what does your calendar look like?"

The scenario: 110 people in Singapore, thirteen markets on the other end of the phone

Picture the Singapore shared services centre of a European lifestyle retail group. Around 110 people, running finance, HR administration, procurement support and merchandising operations for between ten and thirteen APAC markets. The group's commercial head office is in Europe; its stores are spread from Japan to Australia; and this building in Singapore is where the transactions actually get processed.

Finance is the largest function — accounts payable, accounts receivable, intercompany reconciliation, and a small controlling team who produce the regional consolidation. HR administration handles payroll input, onboarding paperwork and benefits administration across markets with genuinely different rules. Procurement support manages purchase orders and vendor master data. Merchandising operations maintain product data, pricing and allocation for the region.

Their technology footprint is unremarkable and typical: Microsoft 365 for everything collaborative, an ERP instance owned by European head office, a group HR system, a data warehouse and reporting layer, a handful of market-specific portals for tax and statutory filing, banking portals per market, and a store-systems interface they consume but do not own.

The Singapore IT presence is two people. Everything else — the service desk, endpoint management, the network, escalation to the group's European IT function — is delivered by an outsourced provider.

That structure is entirely sensible. It also has a failure mode that shows up on exactly four or five days a month.

The four failure patterns specific to a shared services centre

Peak load is calendar-driven, not headcount-driven

An IT support contract sized on 110 users is sized on an average. But an SSC's demand is not distributed evenly across users or days. On the second, third and fourth working days of the month, roughly forty finance staff are doing the highest-stakes, most time-boxed work of their month, simultaneously, on systems they are all hitting at once.

A password reset that is a minor annoyance on the fourteenth is a genuine operational incident on the second, because the person has a hard close deadline and a queue of markets waiting on them. The technical severity of the ticket has not changed at all. The business severity has changed completely.

The practical consequence is that "average response time" is close to a meaningless metric for this profile. What matters is response time during the four days that carry disproportionate business weight — and if your provider does not know when those days are, they cannot staff for them.

Your users are internal, but your customers are other countries

In a normal office, an IT problem inconveniences the person having it. In an SSC, an IT problem in Singapore surfaces as a service failure in another market. The Thai store manager waiting on a purchase order approval does not know or care that the delay is a VPN issue in Singapore; they know their stock is not ordered.

This changes what "resolved" means. Closing the Singapore ticket is not the end of the incident, because there is a downstream commitment that has now slipped and somebody has to communicate about it. Support that stops at the ticket boundary leaves the SSC to do the harder half of the work.

The working day is stretched at both ends, and not by choice

Supporting markets across the region means a Singapore SSC is effectively open from early morning for the markets to its east and into the evening for the markets to its west. This is not a 24×7 operation, and it would be wasteful to buy one — but it is decisively not a nine-to-six operation either, and buying nine-to-six support is exactly what most contracts default to.

The gap hours are also the highest-risk hours, because they are the hours with the thinnest local coverage. A problem at 7:30am, before the Singapore IT presence has arrived but while the Japanese and Korean markets are mid-morning, is precisely the scenario a follow-the-sun desk exists to handle. Brocent's 24×7 multi-lingual help desk is an ITIL-based Global Service Desk operating from decentralised centres in mainland China, Hong Kong and Malaysia, handling around 15,000 IT incidents and service requests a year, with 150-plus help desk staff holding certifications across more than seventy disciplines and 90% of calls answered within forty seconds. For an SSC, the relevant property is not the headline volume; it is that a first-line response exists at the hours the local team does not cover.

The critical system list is mostly other people's systems

This is the pattern that most often surprises a provider who has scoped an SSC as if it were an ordinary office. Ask which systems are business-critical and the answer is: the group ERP, which is administered in Europe. The group HR system, same. Ten banking portals, each with its own authentication and token regime. Several government filing portals with their own certificate requirements, browser sensitivities and holiday calendars. And a handful of market-specific applications whose vendors speak the local language.

The SSC's IT function is therefore in the access, integration and liaison business far more than the systems-administration business. A large fraction of its tickets are not "our system is broken" but "we cannot get into someone else's system, and we need somebody to work that problem across an organisational boundary."

Support that is only equipped to fix what it administers will resolve perhaps half of what an SSC actually raises. Vendor liaison for third-party issues has to be an explicit part of scope, not a favour.

How Brocent thinks about supporting a shared services centre

Model the calendar, not the average

The first thing we want from an SSC is not a user count. It is a calendar: which days are close days, which weeks are payroll weeks, when the quarter-end consolidation lands, when statutory filing deadlines fall in each market, and which of those genuinely cannot move.

That calendar should then be a real input to staffing, to change scheduling, and to escalation thresholds. Concretely: no infrastructure change lands on a close day. Patching windows are planned around the calendar rather than around a generic maintenance schedule. And priority definitions are allowed to shift with the calendar, so that a routine ticket class is treated more urgently during close.

None of this is technically difficult. It requires knowing, and most providers are never told.

Run two clocks: the desk clock and the market clock

An SSC support model needs to be explicit about two different sets of hours. The desk clock is when the Singapore staff are working. The market clock is when each supported market expects service. They are not the same, and the gaps between them are where incidents get expensive.

The useful design is a tiered one: local coverage during the Singapore day, a follow-the-sun first line for the edges, and a documented rule for what the first line can resolve alone versus what waits for the local team. This is a genuinely regional operating model, and it is a large part of why Brocent's Singapore hub exists — the region is supported from Singapore as a hub rather than as one office among many.

Learn from the store-network side of the same business

Brocent's work with a European lifestyle retailer expanding into Asia is directly relevant here, because it is the same corporate shape seen from the other side. That engagement involved standardising store IT and providing a follow-the-sun service desk spanning EMEA and APAC hours, bridging a European head office with new retail locations across Greater China — store network and POS connectivity rollout, onsite break-fix dispatch for store hardware, centralised asset and warranty management, and coordinated go-live and hypercare for new stores.

The lesson that transfers to the SSC side is about the bridge. A European head office and an Asian operation have a genuine handover problem — different hours, different escalation cultures, different definitions of urgent — and the value a provider adds is very often in operating that seam rather than in any individual technical task. An SSC lives permanently on that seam.

Scale matters too. In a separate engagement, Brocent deployed Cisco Meraki switches, firewalls and access points across 153 retail stores in 13 countries simultaneously for a global luxury fashion brand, with centralised procurement, door-to-door logistics, an Ekahau wireless site survey at each location, technical staging before delivery, onsite installation and UAT, and a PMO coordinating every schedule. The relevance to an SSC is not the hardware; it is that regional consistency is a project-management discipline before it is a technology one.

Language of service versus language of record

An SSC serving ten-plus markets has a language question that a single-market office does not. English is almost always the language of record — the tickets, the documentation, the reporting. But the person on the phone from a market may be far more comfortable in another language, and a first-line interaction conducted in a second language is measurably slower and more error-prone.

Our view is that these should be decided separately and deliberately. Keep one language of record so that the ticket history, the SLA reporting and the knowledge base stay coherent and auditable. Allow the language of service to vary where the desk can actually support it. What does not work is letting the language of service quietly become the language of record, because six months later nobody can run a report across the estate.

Regional desk, local desk, or hybrid?

The three models compared

• Local desk only: Support scoped to Singapore hours and Singapore staff. Simplest to buy and easiest to hold accountable, because there is one team and one clock. It systematically underperforms at the edges of the day, which for an SSC is where a disproportionate share of the risk lives.
• Regional or follow-the-sun desk only: Coverage across the full market clock, with first-line response available whenever any supported market is working. Strong on availability and on the "user is internal, customer is another country" problem. Weaker on the physical and the local — somebody still has to walk to a desk in Singapore, and a remote desk cannot do that.
• Hybrid, which is what most SSCs actually need: A follow-the-sun first line covering the market clock, plus local presence during the Singapore day for anything physical, anything requiring context, and the close-period surge. The decision that makes or breaks this model is not the coverage map — it is the written definition of what first line resolves alone versus escalates, because ambiguity there converts every edge-hours incident into a delay.

What actually decides between them

• How much of your risk sits outside Singapore hours? Count incidents, not staff. If a meaningful share of your business-affecting incidents happen before 9am or after 6pm Singapore time, a local-only desk is structurally mismatched no matter how good it is.
• How physical is your estate? Laptops, meeting rooms, printers, the on-site network and new-joiner setup all need hands. The more physical the estate, the more the local component matters.
• How much of your ticket volume is third-party access? If it is high, vendor liaison capability matters more than deep systems administration, and you should scope for it explicitly.
• How sharp is your calendar? A business with a genuine close-period spike needs a provider that will flex for four days a month. That is a commercial conversation, and it works far better held in advance than discovered in arrears.

A practical shape for the first ninety days

If you are re-scoping IT support for a shared services centre — or scoping it for the first time — this is the sequence we would suggest.

Weeks one to two: build the calendar and the system map. Document the close cycle, payroll cycle, statutory deadlines per market, and the peak days. Separately, list every business-critical system and mark who administers it: you, group, or a third party. These two documents will do more for support quality than any technology decision.

Weeks three to four: define the two clocks. Agree the desk clock and the market clock, and identify the gap hours explicitly. Decide what first line can resolve alone in those hours.

Weeks five to eight: fix the boundaries. Write down the escalation path to group IT and the liaison process for third-party portals and vendors. This is the least glamorous work in the plan and the highest-yield, because it is where an SSC's tickets actually get stuck.

Weeks nine to twelve: rehearse a close. Run the support model through one full month-end with heightened attention, and review what queued and why. One observed close teaches you more than a quarter of SLA reports.

Throughout, keep the endpoint and identity fundamentals moving in parallel — managed cloud and Microsoft 365 services for the collaboration layer, and a clear view of who has access to what across a portfolio of systems that mostly belong to other people.

What this costs, in shape rather than in numbers

We will not invent figures. Brocent's managed IT support plans are per-user monthly tiers with published per-market pricing, and the Singapore market is priced natively rather than converted from a regional average. Live figures are on that page and on pricing.

What is worth understanding for an SSC specifically is that per-user pricing is a reasonable base but an incomplete model for this profile, because it prices the average rather than the peak. The two variables that genuinely move an SSC's support cost are the coverage window — how far the market clock extends beyond the desk clock — and whether the close-period surge is handled by flexing capacity or by simply letting queues grow. Both are worth pricing explicitly at contract time rather than discovering in the first quarter.

For a broader Singapore cost view, our published guides on Singapore IT support costs and the managed IT versus in-house comparison cover the general shape of the market.

Frequently asked questions

How is a shared services centre different from a regional headquarters for IT support purposes?

A regional headquarters is a commercial operation — sales, marketing, management — with a fairly flat demand curve and mostly local consequences when something breaks. A shared services centre is a processing operation with a calendar-driven demand spike, downstream consequences in other markets, a stretched working day, and a critical-system list mostly administered by others. Same city, same headcount, materially different support profile.

Do we need 24×7 support for a Singapore SSC?

Usually not literal 24×7, but almost always more than nine-to-six. The honest test is to plot when your business-affecting incidents actually occur across a quarter. Most SSCs discover they need first-line coverage from roughly the start of the Japanese working day to the end of the Indian one, with full local capability during Singapore hours — a follow-the-sun first line rather than a round-the-clock local team.

Our ERP is administered by European head office. What is left for a local provider to do?

A great deal, and it is the part that determines whether the SSC functions day to day: endpoints and identity, the local network, Microsoft 365, access management across the third-party portfolio, first-line triage that correctly routes a group-system issue to group IT rather than sitting on it, vendor liaison, and the physical work. The provider's job at the ERP boundary is to escalate accurately and fast — which requires knowing the boundary, and that is a documentation task.

How should support be structured around month-end close?

Three things. Freeze infrastructure change during the close window. Allow priority definitions to shift so that routine ticket classes are treated more urgently during close. And agree capacity in advance for those days rather than relying on best efforts. All three require the provider to know your calendar, which means giving it to them.

Should the help desk operate in local languages or in English?

Separate the language of service from the language of record. Keep English as the language of record so ticket history, SLA reporting and the knowledge base remain coherent and auditable across markets. Allow the language of service to vary where the desk genuinely supports it — Brocent's desk operates in Mandarin, Cantonese and English. What fails is letting the language of service silently become the language of record.

We are already outsourced and it mostly works. What is the highest-value thing to change?

Almost always the calendar and the boundary map. Give your provider the close calendar and a system-ownership list, then agree in writing what first line resolves alone during gap hours. Those two artefacts typically fix more perceived support problems than a tier upgrade, and they cost nothing but a couple of days of somebody's attention.

Does Brocent support this kind of operation?

Yes. Brocent has been headquartered in Singapore since 2021 and operates it as a regional hub, with an ITIL-based multi-lingual Global Service Desk, ITSM integration with ServiceNow, SDP, Jira and other major platforms, monthly SLA metric reporting, and field dispatch across the region. The retail engagements described above — a follow-the-sun service desk bridging EMEA and APAC for a European lifestyle retailer, and a 153-store, 13-country Meraki rollout for a luxury fashion brand — are the same operating muscle applied to the store side of the same industry.

The point

The mistake is not choosing the wrong provider. It is describing the operation as "110 users in Singapore" when it is really "a processing engine for thirteen markets that runs hot four days a month."

Those two descriptions produce different support models. The first produces a per-user contract sized on an average and scheduled to Singapore office hours, which will look fine on a dashboard and feel wrong to the finance team every close. The second produces a calendar-aware, two-clock model with explicit boundaries at the group and third-party seams — which costs a similar amount and works on the days that matter.

Month-end close does not care that you are a shared services centre. It is worth making sure your IT support does.

If you are running a shared services centre in Singapore and your support model was scoped as though you were an ordinary office, talk to us. The first useful step costs nothing: write down your close calendar and your system-ownership map, and see how much of your ticket history they explain.