Three Proposals, One Real Difference: How a Singapore Engineering Consultancy Chose

TL;DR: A 50-person Singapore engineering consultancy — an SME by any local definition — had three managed IT proposals on the table, all quoting a similar monthly figure and all promising 24/7 support and proactive monitoring. The decision stalled for six weeks — not because the firm could not choose, but because nothing in the three documents was actually comparable. What finally separated them was structural, not commercial.

This is an illustrative composite based on the kind of decision Singapore professional-services firms bring to Brocent. It is not a named client. The three proposals described are deliberately unnamed and are characterised only by their shape — we are not going to tell you what any real competitor does or does not do, and a provider who does that in a sales meeting is telling you how they will talk about you later.

A firm where an IT failure is a billing failure

Our composite firm is an architecture and engineering consultancy of around fifty-five people in Singapore: a structures group, a building-services group, a small visualisation team, and the project managers who hold it all together. Their work is file-heavy in a way that general office IT advice consistently underestimates.

A single coordinated BIM model can run to several gigabytes, and it is not one file but a federation of linked models that half a dozen people open at once. A workstation is not a laptop that runs email; it is a specified machine with a specified graphics card, and when it is replaced with "something equivalent" the difference shows up as a render that takes four hours instead of ninety minutes. Project archives are not cold storage — a job closed out two years ago gets reopened because the client wants a variation, and the whole model tree has to come back intact, with its external references resolving.

And the work is deadline-shaped in a particularly unforgiving way. A tender submission has a clock on it. A coordination deadline with the architect and the M&E consultant has a clock on it. An authority submission has a clock on it. When the file server is slow on a Tuesday afternoon, the cost is not "inconvenience" — it is billable hours consumed by waiting, multiplied by however many people are waiting, on the week where the firm can least afford it.

That is the specific reason this firm's managing director refused to treat the IT decision as a procurement formality. In this business, IT downtime converts directly into unbillable time, and nobody else in the firm is going to notice the conversion happening.

Six weeks with three proposals that would not compare

The shortlist was already done. Three providers, all credible, all recommended by someone the MD trusted. The proposals arrived within a fortnight of each other, and then the decision simply stopped moving.

Here is what the firm was looking at, characterised only by shape.

Proposal A was the cheapest per month by a noticeable margin, ran to nine pages, and described its service in categories: "helpdesk support", "proactive monitoring", "security management", "backup management". Every category was a heading with two or three sentences beneath it.

Proposal B was the longest at forty-one pages, came from the largest firm of the three, and contained a detailed tooling list — a named RMM platform, a named endpoint protection product, a named backup product, a named ticketing system, and a named documentation tool.

Proposal C sat in the middle on price, was moderately detailed, and led with response-time commitments presented as a table of priority levels against target times.

All three promised 24/7. All three used the phrase "proactive monitoring". All three offered onboarding. The monthly figures were within about fifteen per cent of one another.

The MD's honest summary after the third read-through was that she could not tell whether she was looking at three versions of the same service at three prices, or three genuinely different services that happened to cost similar amounts. That is an uncomfortable position to be in, and it is far more common than the industry admits.

What was actually wrong with the comparison

The problem was not that the proposals were dishonest. It was that each of them was internally coherent and externally incomparable — they answered different questions, so laying them side by side produced no signal.

Four specific gaps did the damage.

"Response time" was measured from different starting lines. Proposal C's table looked like the most rigorous document of the three precisely because it had numbers in it. But read closely, its commitment was to *acknowledge* a ticket within a stated window. Acknowledgement is a real and useful thing — it tells you your problem has entered a queue — but it is not the same as an engineer starting work, and it is emphatically not the same as resolution. A provider can hit an acknowledgement target perfectly while a render farm sits idle all afternoon. When the firm went back and asked all three to state, in writing, what the clock was measuring, the answers were different from each other in ways the original documents had completely obscured.

"Included" meant four different things. Proposal B's tooling list was the most concrete document on the table, and it was also the one that raised the most awkward question: if the service is five separately-licensed products, who owns the seams between them? The endpoint tool sees a device; the ticketing system sees a request; the documentation tool sees whatever someone remembered to write down. Nothing joins a remote session to the ticket that caused it, or the ticket to the asset it touched. That is not a hypothetical filing problem. It is precisely why the firm's previous provider had never been able to answer "who was on this machine last Thursday and why" without a two-day reconstruction.

Onboarding was a formality with no defined end. All three proposals used the word. None of them said what "finished" looked like. There was no deliverable named, no acceptance criterion stated, no date at which the firm could say the transition had either succeeded or not. In a professional-services firm, an open-ended transition is not a neutral risk — it overlaps with live project deadlines, and an incomplete handover shows up as a missed authority submission rather than as a late IT project.

Nobody had said who owns the documentation. This is the one the MD raised herself, from experience, and none of the three had addressed it. If the network diagrams, the asset register, the licence inventory, the runbooks and the administrator credentials live only inside a provider's own platform, then leaving that provider means reconstructing your own environment from scratch — which is a switching cost that never appears in a monthly figure, and which gets discovered at the worst possible moment.

The questions that finally made the proposals comparable

What broke the deadlock was reframing the evaluation away from *what does the service include* and toward *how is the service built*. Four structural questions did most of the work, and each of them came out of a problem this specific firm had already lived through.

Is this one engine, or a stack of tools?

The firm's previous arrangement had failed at exactly the point where one product handed off to another. So the first question became: when an engineer connects to a workstation, does that session exist as a record in the same system that holds the ticket, the asset and the history — or does it live in a remote-access product that knows nothing about any of them?

This is Brocent's own architectural position rather than a neutral observation, so read it as such: BCS Beam is built as one engine rather than a stack, and the specific consequence is that a remote session launched from a support ticket is linked to that ticket, so the history tells the whole story instead of three partial ones. One platform also means one audit trail and one vendor's data-handling policy, rather than a patchwork of SaaS tools each with their own.

The reason this matters to an engineering consultancy in particular is the reopened project. When a two-year-old job comes back, the questions are archaeological: what was this workstation's configuration, which licences were on it, what changed and when. A stack of tools answers those questions in fragments. A single record answers them in one query, or admits honestly that it cannot.

Is the takeover a defined project with a finish line?

The firm rewrote this question as a demand: show me the transition as a plan with phases, durations, deliverables, and a point at which it is over.

For reference, Brocent's onboarding process is structured as a three-month takeover in four phases — a site survey and IT audit in weeks one and two, knowledge transfer and CMDB build in weeks two to four, a shadow and re-shadow period in weeks three to six where engineers work under observation until they meet a benchmark, and full service go-live from month three. The parts that matter for comparison are not the durations; they are the artefacts. A configuration management database that catalogues every asset, configuration and software licence. Standard operating procedures written for every recurring task. An identified top three infrastructure weaknesses from the audit, with the hardening work to address them scheduled inside the transition rather than deferred. An escalation matrix that names the path from helpdesk to supervisor to account manager. And a formal thirty-day post-go-live review that exists to find the knowledge gaps the transition missed.

You do not need a provider to use that exact shape. You need a provider who can produce *some* shape with a finish line in it, because "we'll get up to speed over the first few months" is not a plan, it is a hope with an invoice attached.

Can you show me the session log?

This is the question the MD liked best, because it cannot be answered with an adjective.

Ask a prospective provider to show you what a remote support session looks like from the customer's side. Specifically: does an engineer connecting to a staff member's machine produce a consent prompt that names the engineer? Does a banner stay on screen while the session runs? Can a user see how many sessions are active and which account is connected, without asking anyone? And afterwards, is there a record of who connected, to which device, when, in what mode, and against which ticket — and can you get it yourself rather than requesting it as a favour?

Those are the specific behaviours Brocent's own endpoint agent implements, and the reason to ask about them is not brand preference. It is that the answer is verifiable in a demo, in five minutes, and it tells you something a proposal cannot: whether "secure remote support" is a property of the system or an assurance from the salesperson. For a firm holding client drawings under confidentiality obligations, the difference is not academic.

Two related questions travel with it. Where does the session data live, and does a third-party remote-control cloud sit in the path? And is the security-audit component of the agent able to *act* on your machines, or only to observe? Brocent's audit agent is deliberately read-only — it reports settings, software inventory and update status, matches installed software daily against the global CVE catalogue prioritised by real-world exploit risk, and cannot execute anything; hands-on work happens only through the consented, logged remote-support channel. Whatever your provider's answer is, get it stated rather than assumed.

Does the documentation belong to us?

The last question is a single sentence, asked of every proposal: if we terminate in two years, what exactly do we leave with?

The good answer names artefacts — the asset register, the network documentation, the runbooks, the licence inventory, the credentials — and a format and a timeframe. The bad answer is a reassurance about how it has never been a problem. The MD's rule after this exercise was blunt: anything that cannot be named in the contract does not exist.

The mechanics of actually executing a provider switch are a separate subject with their own pitfalls, and we wrote them up in detail in how a Hong Kong trading company switched providers without breaking anything. The relevant point at proposal stage is narrower: the exit terms tell you how the provider thinks about the relationship while they are still trying to win it.

What the re-scored comparison looked like

When the firm put the three proposals back through those four questions, the ranking changed — and, more importantly, the reasons for the ranking became things the MD could explain to her partners in one sentence each.

Proposal A, the cheapest, turned out to be cheapest partly because the scope was genuinely narrower: the category headings covered less than the other two once someone asked what sat under them. That is not a criticism of the provider. It is a correctly-priced smaller service, and for a firm with simpler needs it might have been the right answer. It was not the right answer for a firm whose workstations are specified equipment and whose project archives have to survive being reopened.

Proposal B, the largest firm with the longest document, gave the clearest answers on tooling and the weakest answers on the seams between tools. The firm's judgement — and this is a judgement, not a fact — was that a service assembled from five products would reproduce the exact failure they had already experienced, which was that nobody owned the gap between the products.

Proposal C, the one with the response-time table, improved once the clock definition was clarified in writing, which is itself worth noting: asking the question changed the proposal. A provider willing to restate a commitment precisely, in writing, when pushed, is demonstrating something useful about how they will behave at renewal and during an incident.

What separated three near-identical proposals

• Cheapest headline price. *What it actually indicates:* usually a narrower scope, sometimes a genuinely leaner operation, occasionally an intention to recover margin through out-of-scope billing. *How to test it:* ask what sits under each category heading, and ask for three examples of work that would be billed separately. *When it is right:* when your needs really are narrower, and you have checked rather than assumed.
• Biggest brand name. *What it actually indicates:* scale, process maturity, and usually a longer tooling list. *What to watch:* whether the service is one engine or several licensed products with unowned seams between them, and whether your fifty-person firm will be a priority account or a rounding error. *How to test it:* ask who specifically will be on your account and what happens when that person is on leave.
• Structural fit. *What it actually indicates:* that the provider has thought about how the service is built rather than only what it contains. *The four tests:* one engine with one audit trail rather than a stack of tools; a takeover that is a defined project with deliverables and a finish line; remote access that is consented, visible and logged in a way you can inspect yourself; and documentation, credentials and runbooks that are contractually yours. *The honest caveat:* structural fit is what Brocent optimises for, so treat this bullet as a stated position rather than a neutral finding — the value is in asking the four questions of everyone, including us.

Choosing, rather than being sold to

The firm in this story did not pick a provider because one of them won an argument. They picked one because, after six weeks of stalled comparison, they finally had four questions whose answers differed — and differed in ways that mapped onto problems they had actually experienced rather than onto risks a salesperson had described.

That is the transferable part. The evaluation criteria that are worth anything are the ones derived from your own failures. A consultancy whose workstations are specified equipment and whose archives get reopened needs different answers than a distributor whose website is the sales pipeline, and a generic checklist serves neither well.

If you are in the middle of a comparison like this one, the two useful things to do next are to read what a managed IT service is actually composed of rather than what it is called, and to check the published plan pricing so you have a reference point that does not depend on anyone's proposal. If you want the four questions asked of us specifically, get in touch — and ask them of the other two as well. That is the point.

Brocent has been running IT operations for businesses since 2007, starting in Beijing, with a Hong Kong office since 2016 and Singapore as the group's global headquarters since 2021. We are not going to tell you we would win your shortlist. We would rather your shortlist became decidable.

Frequently asked questions

How do we compare proposals that quote different things?

Stop comparing inclusions and start comparing structure. Inclusion lists are written by each provider in their own vocabulary, which is why three of them laid side by side produce no signal. Structural questions have answers that are directly comparable because they are about architecture rather than packaging: is this one system or several products, what is the transition plan and when is it finished, what can you see and audit about remote access, and what do you own at the end. Write those four questions out, send the same four to every provider on your list, and ask for the answers in writing. The differences will be obvious in a way the original documents were not.

What does a response-time SLA actually promise?

That depends entirely on what the clock measures, and it is the single most misread number in managed IT proposals. Some providers commit to acknowledging a ticket; some to a human beginning diagnostic work; some to resolution within a priority band. These are very different promises and they often carry similar-looking numbers. Brocent's own published commitment is a 15-minute first response for P1 critical incidents, with published tiers for lower priorities — but the number matters far less than the definition, so make every provider state theirs in writing and make sure you are comparing the same starting line.

Who owns our IT documentation and passwords?

Whoever the contract says, which is why this belongs in the contract rather than in a conversation. Ask specifically: on termination, do we receive the asset register, network documentation, runbooks, standard operating procedures, licence inventory and administrator credentials; in what format; and within how many days. A provider building a proper configuration management database during onboarding has all of this as a natural by-product, so a reluctant answer usually indicates either that the documentation does not exist in a portable form or that the provider regards it as leverage. Both are useful to know before you sign.

How long should switching providers take?

A structured takeover of a small professional-services environment is typically a three-month exercise, not a weekend — Brocent's own onboarding runs survey and audit, knowledge transfer and CMDB build, a shadow and re-shadow period, then go-live from month three, followed by a formal thirty-day review. Be suspicious of both extremes. A provider promising a switch in two weeks is either inheriting excellent documentation or planning to learn your environment through incidents; a provider unable to say when the transition ends has not scoped one. The mechanics of the switch itself, including handling an incumbent who is unenthusiastic about the handover, are covered separately in our provider-switching walkthrough.

What should onboarding include?

At minimum: a site survey and audit that produces a written picture of what you actually have; a configuration management database cataloguing assets, configurations and licences; documented standard operating procedures for recurring tasks; knowledge transfer sessions with your existing team or outgoing vendor; identified infrastructure weaknesses with remediation scheduled rather than noted; an escalation path with named roles; and a defined go-live with a post-go-live review. If a proposal's onboarding section cannot be read as a list of artefacts you will receive, it is describing an intention rather than a project.

How do we check a provider's remote-access controls?

Ask for a live demonstration from the end user's perspective, not a slide. Watch what a staff member sees when an engineer connects: is there a consent prompt, does it name the engineer, does a banner persist during the session, can the user see active sessions and the connected account at a glance. Then ask to see the audit record afterwards — who connected, to which machine, when, in what mode, against which ticket — and ask whether you can export it yourself. Also ask where that data lives and whether a third-party remote-control service sits in the path. Five minutes of demonstration tells you more than any paragraph about security posture.

Should we pick the cheapest?

Sometimes, genuinely — but only after you have established that it is cheap because the scope is smaller or the operation is leaner, rather than because the gaps are places you will be billed later. The test is to ask what sits beneath each scope heading and to request examples of work that would fall outside the monthly fee. A narrower service honestly priced is a legitimate option for a firm with narrower needs. A narrower service described in the same language as a broader one is a problem you will meet in month four.

What if we are mid-contract with someone else?

Read the termination clause before you do anything else, then read the data and documentation clause, then work backwards from your own project calendar. The useful question is not "can we leave" but "when is the least damaging window", and for a deadline-driven consultancy that is a scheduling decision as much as a legal one. A serious incoming provider will plan the transition around your submission dates rather than their own start date, and will ask to see the calendar before proposing one.