After Go-Live: How HQ and Thailand Teams Can Share IT Support Responsibilities
How HQ, the Thailand team and vendors can share IT support after go-live: named owners, one front door, severity, hours, escalation and reviews.
By UNIXDEV Team · 5 min read
Published
Someone has to answer the first password reset in a new Thailand office, notice a failed backup and decide whether a slow system is an incident. If HQ, the local team and vendors have not agreed who does what, those questions land on whoever is nearby.
This guide picks up where the IT readiness checklist for opening an office in Thailand ends.
Three parties, clear roles
HQ usually sets standards and owns global platforms such as identity, email and core business systems. The Thailand team knows local users, the office and the business calendar. Vendors and partners deliver services within a contracted scope.
Give every service a named owner
List the services the office depends on: sign-in, email and collaboration, network, endpoints, business applications and backups. Each needs one named owner who is accountable for its health, changes and documentation.
One front door for requests
Users need one place to report problems, such as a portal, shared mailbox or service desk number. Behind it, tickets are routed to HQ, the local team or a vendor.
Severity and priority are different
Severity describes impact: how many people are affected and how badly. Priority sets the order of work, considering urgency and deadlines. A severity 2 fault in a reporting tool can rank below a severity 3 issue that stops one finance user closing the month on deadline day.
| Severity | Example impact | Example handling |
|---|---|---|
| 1 — Critical | Office or key system unavailable, no workaround | Escalate at once, regular updates |
| 2 — High | Major function degraded or a team blocked | Service owner engaged |
| 3 — Normal | One user affected or workaround available | Handled in queue order |
| 4 — Low | Request, question or minor fault | Planned work |
Response time is not resolution time
Response time is how long it takes a qualified person to acknowledge a ticket and start work. Resolution time is how long it takes to restore the service or complete the request. A quick response can still mean a slow fix when the fault depends on another party. Agree the two separately, and decide whether the clock runs only during business hours.
Business hours and time zones
Thailand runs on UTC+7 with no daylight saving, so the overlap with HQ shifts when HQ changes its clocks. Map the overlapping hours for each season and schedule handovers inside them. Public holidays on either side reduce the overlap further.
What happens outside agreed hours is decided by contract, not assumed. Do not assume anyone covers evenings, weekends or public holidays unless it is written down.
Escalation and change approval
For each severity, the escalation path names who is contacted next, by which channel and when, on both sides of the time difference.
Define which changes are pre-approved and which need the service owner’s approval. A local firewall change can break an HQ system, so changes that affect HQ-owned services need HQ’s approval.
Access, monitoring and backups
Joiners, movers and leavers: HR raises the request, the Thailand team tracks it, and each system’s owner grants or removes access. Remove access promptly when someone leaves, including vendor accounts and shared credentials. Confirm data-protection and other legal obligations with the company’s legal advisers.
Monitoring: for each alert, name who receives it and who acts. An alert nobody acts on is noise.
Backups: name who checks backup results and who runs scheduled restore tests.
An example responsibility split
Adapt this example to your services and contracts. Owns means accountable and decides; Supports means does assigned work; Informed means kept updated. Ownership should follow the service-owner list above.
| Activity | HQ | Thailand team | Vendor/partner |
|---|---|---|---|
| Identity and global applications | Owns | Supports | Informed |
| Office network and endpoints | Informed | Owns | Supports |
| Ticket intake and routing | Supports | Owns | Supports |
| Joiner/leaver requests | Supports | Owns | Informed |
| Access changes in global identity | Owns | Informed | Informed |
| Monitoring of global systems | Owns | Informed | Supports |
| Monitoring of office network | Informed | Owns | Supports |
| Backup checks and restore tests | Owns | Informed | Supports |
| Service reviews | Owns | Supports | Supports |
A worked incident example
This is a hypothetical, illustrative scenario: a European HQ in winter, six hours behind Bangkok. It is not an SLA and not a UNIXDEV customer result.
- Intake: at 16:40 Bangkok time (10:40 at HQ), staff cannot sign in to the HQ-hosted ordering system. The local IT lead logs one ticket and links duplicate reports.
- Severity and priority: the ordering system is unavailable to the whole office with no workaround, so it is severity 1. The month-end order run makes it top priority.
- Triage: internet and other HQ systems work, so the local lead escalates the ticket to the application’s HQ owner.
- Response: the HQ application team acknowledges the ticket and starts work. That is the response, not the fix.
- Handover at Thai close: at 18:00 Bangkok time the local lead updates the ticket and hands it to HQ, which keeps working during its day. Users are told when to expect the next update.
- Resolution: HQ restores access that afternoon and records the cause and fix. That is the resolution.
- Closure: the next Bangkok morning, the local team confirms with users that ordering works and closes the ticket.
- Review: at the next service review, both teams check whether escalation, handover and updates worked.
Documentation and service reviews
Keep runbooks for common tasks, current diagrams and a contact list with names, roles, time zones, holiday calendars and out-of-hours numbers where cover is agreed. Store them where both teams can reach them during an outage.
Hold a regular service review of tickets, incidents and changes, looking for repeat faults, slow handovers and owners who have changed.
UNIXDEV can help review a support model and the operations behind it, through DevOps and managed services or digital workplace and collaboration platforms. Coverage hours, response targets and escalation are agreed in the service scope.
Discuss your Thailand project
Tell us where your team is based in Thailand, your timing, the systems you use today and the help you need. You do not need a finished specification.
Discuss your Thailand project →