A talent acquisition lead in Singapore opens Monday with four jobs to fill: a store manager in Kuala Lumpur, two engineers in Jakarta, and a compliance hire in Hong Kong. The roles are different.
The harder problem is that one team has to run them under four sets of rules, in four languages, through four sets of candidate habits, without separate hiring processes.
Most ATS buying guides answer a narrower question: which tool is best. This one is about the operating model underneath. Pick the strongest system in the world and you still have to decide what stays the same across markets and what has to bend to each one.
Get that split right and the tool choice gets easier. Get it wrong and every new market adds manual work instead of scale.
What changes when you hire in more than one market
A single-market team can run one language, one set of templates, one approval chain. Add markets and five things multiply at once:
- Language. Job ads, screening questions, and candidate messages need local versions, and your AI screening has to read resumes in more than one language.
- Candidate channels. Where people reply differs by market. In much of Southeast Asia that is WhatsApp rather than email, and the job boards that matter include JobStreet, JobsDB, and LinkedIn.
- Data rules. Each market has its own law on candidate data and cross-border transfer (covered below).
- Legal entities and approval chains. A regional group often hires through separate legal entities, so sign-off paths and offer templates differ by country.
- Time zones and collaboration tools. Interviews and approvals span offices, so scheduling and alerts have to work across time zones in the tools managers already use, such as Lark or Microsoft Teams.
If any one of these is handled per market by hand, it becomes the bottleneck the moment hiring volume rises.
Four markets at a glance
A quick orientation for the four markets many regional teams start with. Treat the compliance column as a pointer, not legal advice, and confirm the current text of each law before you rely on it.
| Market | Where candidates reply | Main job boards | Application language | Data law to check | Hiring note |
|---|---|---|---|---|---|
| Singapore | WhatsApp, email | LinkedIn, JobStreet | English | PDPA | |
| Malaysia | JobStreet, LinkedIn | English, Malay | PDPA 2010 (amended 2024) | 2024 amendments add DPO and breach-notification duties | |
| Indonesia | JobStreet, LinkedIn | Bahasa Indonesia | Law No. 27 of 2022 (PDP) | ||
| Hong Kong | WhatsApp, email | JobsDB, LinkedIn | English, Chinese | PDPO (Cap. 486) |
The point of the table is not to memorize law. It is to see that a template built for one market will not simply copy across.
Centralize or localize: the operating model
The teams that scale cleanly decide this once, in the open, rather than letting it happen by accident. The rule of thumb: standardize the parts that define hiring quality and governance; localize the parts that touch the candidate and the local entity.
| Standardize at HQ | Localize per market |
|---|---|
| Job architecture and level definitions | Job-ad language and tone |
| Competency scorecards and rubrics | Candidate channels and message templates |
| AI screening criteria per role family | Approval chain per legal entity |
| Reporting definitions (time to fill, cost per hire) | Data retention period and consent wording |
| Data governance and access policy | Offer templates and local terms |
When scorecards and screening criteria live at HQ, a candidate for the same role is judged the same way in Jakarta and Kuala Lumpur, and your regional reporting actually compares like with like. When channels, language, and approval paths live locally, each market still runs the way its candidates and its entity require. Teams that centralize everything frustrate local recruiters; teams that localize everything lose the ability to compare markets at all.
What your ATS has to support
Once the model is clear, it tells you what to test in a demo. Ask the vendor to show each of these live, on your own setup, not on a slide:
- Region and role-based permissions. A Jakarta recruiter sees Jakarta pipelines; a regional lead sees all four. Ask them to switch between the two views.
- Per-market workflows and approval chains. Different sign-off paths per legal entity. Ask to see two different chains running side by side.
- Multi-language job ads and candidate messages. Ask to post one requisition in two languages.
- Local candidate channels. WhatsApp and the job boards your markets use. Ask them to send a WhatsApp message and post to JobStreet or JobsDB in the demo.
- Data residency and per-country retention. Ask where candidate data is stored and whether retention can be set per market.
- Cross-time-zone scheduling. Interviews booked across offices in Lark or Teams, with the right local time shown to each party.
- One regional dashboard. The four markets in one view, with per-market filters.
If a vendor can only show these on a reference slide, treat the capability as unproven.
Roll out one market first, then clone it
A four-market launch on day one usually means four half-configured setups. A better sequence: pick one pilot market, get the workflow, templates, approval chain, and channels working there, then turn that configuration into a template and clone it to the next market with local adjustments. Each clone is faster than the last.
Measure each market on its own numbers rather than a blended regional average: time to fill, cost per hire, and candidate reply rate per market. A low regional average can hide one market that is badly stuck. During the demo, ask the vendor how many weeks each additional market takes to go live, and who on their side runs it.
What this looks like in practice
Traveloka runs hiring across nine APAC markets on Moka AI, with WhatsApp, the HackerRank assessment tool, and Lark connected into one flow. On that setup the company has run 28,400+ resumes through AI screening and had 5,900+ interviews assisted by AI (Moka AI Traveloka case study). The detail that matters for a multi-market team is not the volume alone. It is that the local channel, the assessment tool, and the collaboration tool all feed one system of record, so the regional team sees every market in one place.
Build your multi-market setup
Decide your centralize-versus-localize split first, write it down, then score ATS vendors against it. Bring one live role in two of your markets to every demo and ask the vendor to configure both in front of you. A system that runs your real two-market test gives you more evidence than any regional feature list.
If you hire across Southeast Asia and Hong Kong, that is the test to run with Moka AI: one open role, two markets, your own resumes.
FAQ
Do we need a separate ATS for each country?
Usually no. The goal is one system of record with per-market workflows, languages, channels, and data settings inside it. Separate systems per country re-create the fragmentation you are trying to remove and make regional reporting almost impossible.
A recruiter in one country reviews a candidate from another. How is that data handled?
That is a cross-border transfer, and each market sets its own rules for it (see the table above). At a high level, confirm where candidate data is stored, whether retention can be set per country, and who can see which market's data. Treat this as a go/no-go item in your vendor review, and confirm the current legal requirements for each market with your own counsel.
Author
Moka AI Editorial Team
The Moka AI Editorial Team creates insightful, practical, and engaging content on HR, recruitment, and AI innovation. We explore emerging trends, share industry insights, and turn complex ideas into actionable knowledge to help HR professionals navigate the evolving world of work.
