Choosing a Managed Infrastructure Partner in Vietnam: Asking About SLA, On-Call and Handover

Why you should standardise the questions before you compare quotes

When a company outsources infrastructure operations, most of the evaluation effort tends to land on price and on the service catalogue. Those are the easiest things to compare and among the least predictive of how the next two years will actually feel. The differences that matter live in harder places: where the response clock starts, who picks up the phone at two in the morning during the Tet holiday, and what you get back when the contract ends.

What follows is a vendor-neutral checklist. It is written to be used against every provider on your shortlist, and that explicitly includes HiTechCloud. If a question here makes a provider uncomfortable, that is useful information regardless of whose name is on the proposal. The goal is not to find the provider with the smoothest answer but to force every provider to answer the same questions so you can compare them on one surface.

One note on method. Send the questions in writing and require written answers. Answers given in a meeting are consistently more generous than answers that have to be typed, and only written answers have any chance of becoming a contract schedule.

Response and resolution are two different promises

Many service tables quote only a response time. Response means someone has acknowledged the incident; it says nothing about when the system runs again. A fifteen-minute response commitment sounds strong, but if the incident then sits for three hours waiting on the one engineer who understands the platform, it has not protected your revenue.

Ask for three separate figures: time to first response, time to engagement by someone with the access and the knowledge to act, and a target for resolution. If a provider will not commit to a resolution target, ask why and ask what replaces it. A reasonable answer is a commitment to continuous effort plus a fixed update cadence, for example a status update every thirty minutes at the highest severity. An unreasonable answer is silence.

Then ask when the clock starts: at detection by monitoring, at ticket creation, or at correct triage? Ask whether it can be paused, under what conditions, who may pause it, and whether you can see that history. Pausing while waiting on the customer is legitimate; pausing invisibly is not.

Severity definitions need to be tested, not read

The entire value of an SLA rests on how severity is assigned, because severity decides which commitment applies. If the definitions are vague, whoever does the classifying holds the real power. Ask for the severity matrix in writing, read it closely, then test it against your own scenarios.

Question to ask	Why it matters
Who assigns the initial severity?	That party effectively controls which commitment applies
Can the customer raise a severity unilaterally?	Stops a business-critical failure being logged as routine
Does degraded performance count as an incident?	A system ten times slower is still up under a narrow reading
Where does a broken staging environment sit?	Blocked releases are also business damage
Does severity auto-escalate with age?	Prevents medium issues from sitting untouched for days

The most effective test is to write several real scenarios from your own estate and ask each provider to assign a severity and the resulting commitments. The differences between providers become visible immediately in that exercise.

Coverage windows, public holidays and Tet

Ask exactly which hours apply to each severity level. Plenty of packages promise around-the-clock cover for the top severity and business hours for everything else, which can be perfectly acceptable if you know it in advance. The problem only appears when you assumed full cover and the contract says otherwise.

In Vietnam, the Lunar New Year period deserves its own question. Is the Tet rota staffed by the same engineers as the rest of the year or by a reduced crew, by how much does staffing drop, do committed response times change, how far in advance is the rota published, and who can approve exceptions to a holiday change freeze?

For retail, e-commerce, travel and financial services, Tet is often peak season rather than a quiet period. If that describes you, say so during evaluation and ask for peak-period commitments in writing rather than assuming the on-call team will absorb it.

Who is actually on call, and where escalation stops

This question is often answered with an org chart instead of with facts. Ask specifics: how many people are on a shift, in which time zone, and are they employees of the provider or subcontracted? Does the first-line engineer have the access to act on your systems, or only the ability to triage and wake someone else?

Then ask for the escalation path as a diagram with named roles, a time limit at each tier, and contact methods. If first line cannot resolve within thirty minutes, who is second line and how quickly are they committed to appear? Who is authorised to approve high-risk actions such as a failover, a restore from backup, or shutting down a service to protect data? Who is the executive contact once an incident passes a defined duration?

Three follow-ups are routinely forgotten: whether you have an out-of-band contact route if the provider’s own ticketing system is what is down, how often they rehearse their call-out process, and how priority is decided when two customers have a severe incident at once.

Reporting cadence and reporting content

Reporting is the only way you learn what you are buying in the months when nothing breaks. Ask to see a redacted sample report rather than a description of one. A real sample reveals a great deal about operational maturity.

• Cadence: a monthly operations report and a quarterly service review, confirmed in the contract rather than in conversation.
• SLA attainment per severity level, with every miss and its reason.
• Incident summary: volume, distribution by cause, and repeat offenders.
• Root cause analysis for severe incidents, with named owners, due dates, and the status of actions carried over from earlier periods.
• Patch and security update status, including systems that were not patched and why.
• Restore test results, not merely a report that backups completed.
• Changes made in the period, change failure rate and rollback count.
• Capacity and cost trends with recommendations for the next three to six months.
• A current list of the accounts and privileges the provider holds in your environment.

The provider’s access model and least privilege

A managed infrastructure partner is one of the largest security exposures you take on deliberately, simply because they need elevated access to do the work. How that access is governed tells you more than any certificate logo.

Ask whether their engineers sign in with individual identities or with shared accounts. Shared accounts make attribution meaningless. Ask whether elevated rights are standing or granted on request with an expiry, who approves them, and whether you can see the approval log. Ask where session and command logs live, who holds them, how long they are retained, and whether you can query them directly rather than requesting extracts.

Then cover the people process. When an engineer leaves the account, how quickly is access revoked and who verifies it? Is access performed from managed or personal devices? Is multi-factor authentication enforced on every entry point, including emergency routes? Is there a break-glass credential, and are you alerted when it is used?

Finally, ask who holds root and owner rights on the cloud accounts and the domain registrations. In most arrangements the healthier answer is that your company holds the root and grants operating access to the provider, not the other way round.

Who owns the documentation

Documentation is the asset everyone forgets about until the day it matters most. Establish at the outset that architecture diagrams, incident runbooks, operating procedures, automation scripts and infrastructure code written for your estate belong to you, and that you receive them continuously rather than once at the end.

Ask where the documentation is stored. If it lives inside the provider’s internal wiki and you cannot reach it, you do not own it in any practical sense. The healthier pattern is a repository you control, to which the provider has write access, with a change history.

Extend the question to tooling. If the provider uses their own monitoring, configuration management or automation platform, what do you lose on the day you leave? Can alert definitions, thresholds, dashboards and metric history be exported in a reusable format? This is not a trick question; it is how you price the true cost of a future transition.

Transition-in and transition-out obligations

Handover runs in both directions and both belong in the contract. Transition-in needs a plan with dates, exit criteria, and above all clarity on when the SLA actually starts applying. An SLA that takes effect on signature, before anyone understands the systems, is not a real commitment.

1. Transition-in deliverables: an asset inventory, a verified architecture diagram, a risk register, a monitoring plan, and runbooks for common failure scenarios.
2. The criteria for moving into steady-state service, who signs that off, and whether transition-in effort is included in the fee.
3. Transition-out: a minimum assistance period after termination, measured in months rather than days.
4. What is returned: data in open formats, current documentation, automation code, and dedicated time for engineer-to-engineer knowledge transfer.
5. Transition assistance must apply to every termination reason, including the unhappy ones.

One simple test question works remarkably well: if we gave notice next month, exactly what would you hand over during the following ninety days, who would do it, and what would it cost us? A provider with a real process answers that immediately.

How HiTechCloud can help

HiTechCloud provides managed infrastructure services for systems running on AWS, Google Cloud and in-country infrastructure, as an AWS partner and a Google Premier Partner. If you are assembling selection criteria, we are willing to answer every question in this article in writing so you can place our answers in the same comparison table as everyone else, and to discuss how to structure the SLA schedule, escalation path and handover plan for your particular environment.