Outsourced Support: Multi-Accounting Across Zendesk and Intercom
How support outsourcing agencies isolate client Zendesk and Intercom accounts, pass shifts safely, and pass client security audits with GetAntik.
A customer support outsourcing company rarely works with a single client. The typical picture: an agency with 20–40 agents serving 10–15 brands at once, each with its own Zendesk, Intercom, Freshdesk, or Help Scout instance, its own escalation rules, and its own SLA. One agent can switch between five or six such accounts in a single shift. And that's exactly where problems start that a regular Chrome browser with a few user profiles can't solve.
Why tabs and browser profiles don't cut it
Helpdesk platforms watch sessions more closely than social networks do. Zendesk and Intercom both run anti-fraud checks: a suspicious login from a new device or a different country triggers re-verification, a temporary lock, or a notification to the client's admin. If an agent is based in Manila and the client's account is configured for US-only access (a common requirement for companies worried about data leaks), a login through a shared office IP will look suspicious to half the client accounts on that machine.
Add to that the risk of session bleed — one client's cookies occasionally leaking into a neighboring tab because of shared localStorage or an overly permissive extension — and you get situations where an agent accidentally replies to Client A's customer while signed in as Client B. This isn't hypothetical; in support work, incidents like this are a frequent reason agencies lose a contract.
Chrome profiles (without an antidetect layer) solve the problem of visually separating tabs, but they don't solve:
- fingerprint conflicts from frequent logins under different accounts on the same device;
- geolocation requirements tied to a specific client's contract;
- secure storage of 2FA codes for a dozen or more client accounts on a single laptop;
- an audit trail of who logged into which client's account and when.
If you're still unsure whether plain profiles are enough for your situation, the distinction is covered in detail in Chrome profiles vs. an antidetect browser.
What profile-level isolation actually changes
In an antidetect browser, each client account lives in its own profile: its own set of cookies, its own history, its own browser fingerprint (OS, version, screen, fonts, WebGL), and — most importantly for support work — its own proxy with the required geolocation and time zone.
The practical benefits come down to a few concrete things:
1. Fewer false positives from client security systems. If a contract requires logging into a client's Zendesk from the US, a profile with a proxy that provides the right region's IP and time zone passes checks without extra captchas or "suspicious login detected" emails. Different proxy types for different support tasks are covered in choosing proxy types for multi-accounting.
2. No accidental leaks between brands. Profile A physically cannot see Profile B's cookies or localStorage. An agent tired at the end of a shift won't send a reply meant for one client's chat into another client's thread — not a theoretical risk when six to eight tabs of the same browser are open at once.
3. 2FA within reach, but not scribbled in a notebook. The two-factor authentication vault is tied to the profile: the code is generated right where the account is open, so there's no switching between an authenticator app on a phone and a dozen browser tabs.
4. Session stability through warm-up. A long-lived Zendesk session means fewer repeat logins and less chance of hitting a verification prompt at an inconvenient moment — in the middle of an escalation with an angry customer, for instance. Scheduled cookie warm-up keeps a profile "warm" even if the account hasn't been opened for a couple of days; the mechanics are explained in account warm-up for antidetect profiles.
Shift handoffs and oversight without excess trust
Support work runs on shifts. The morning shift closes tickets; the evening shift picks up what's left open. If a profile with access to a client's account is simply "handed off" through a shared password in the team's Telegram chat, that violates almost any client contract around data access — and creates a lingering risk that a former employee still remembers the password a year later.
A workable setup is built on roles and in-team profile handoff, without ever exposing passwords:
- Owner/admin — project lead or team lead: sets up profiles per client, assigns limits.
- Member — shift agent: sees only the profiles they've been granted access to, never sees the client's raw password.
- Finance — if the agency bills clients by hours worked in their account, this role only needs visibility into activity, not access to the profiles themselves.
- lev opened Airdrop zkSync 07
- artem closed FB · US · BM-14
- maya is watching artem
- lev transferred TikTok Shop 03
Handing a profile to the next agent during a shift change takes seconds: the profile moves to the next person without passing a login and password through a messenger app. It's the same principle covered in team roles and profile handoff — only for support it matters more because of how often it happens. Two or three handoffs per day for a single client account are routine for round-the-clock coverage.
A separate feature that genuinely saves agencies money on training new agents is live view and remote control of a teammate's browser. A team lead can watch a trainee work inside a client's account and step in before a ticket gets escalated over a wrong answer.
Access audits: what clients actually ask for
Larger clients of support outsourcers — fintech, e-commerce handling personal data, healthcare-adjacent services — increasingly require proof of access control as part of the contract or as part of their own SOC 2 / ISO audits. The questions sound like: who has access to our support account, when was the access list last changed, how fast is access revoked when an agent leaves.
A profile activity log answers this without manually maintained spreadsheets: it shows who logged into a client's profile, when, and for how long. For an agency this isn't paperwork for its own sake — it's a concrete argument at contract renewal time, when the client is comparing you against a competing outsourcer.
Spend, 30 days
When an agent leaves a project or the company, access is closed at the team level — the profile stays with the agency, and client passwords never end up on a former employee's personal device. The process is covered in detail in offboarding and closing team access, and for support work this procedure needs to be especially fast: client data in Zendesk often includes correspondence containing end-user personal information, and a delay of even a few days after termination is already a compliance gap.
How many profiles and proxies you actually need
A common mistake is setting up one profile per client and calling it done. In practice it's better to think in two dimensions: the number of client accounts and the number of agents working in them at the same time.
| Agency size | Clients | Agents online at once | Profiles | Proxies |
|---|---|---|---|---|
| Small agency | 5–8 | 2–3 | 8–10 | 5–8 (per client) |
| Mid-size agency | 15–20 | 8–10 | 20–25 | 15–20 |
| Large BPO | 40+ | 25+ | 50–70 | 40+ |
The logic is simple: if two agents work on different tickets for the same client at the same time, they don't need two profiles of that client — most helpdesk platforms handle multiple agents inside one company account just fine (each agent has their own login inside Zendesk). The profile should be scoped to "client + device," not "client + agent," unless the client's contract explicitly requires per-person access binding.
It's usually more cost-effective to assign proxies by geo-requirement rather than one-per-client across the board. If three clients don't require a specific country, they can share a proxy pool and cut costs. If a client insists on access only from its own country, that proxy gets assigned separately, for that exact region. A proxy manager with checks and rotation links saves hours of manual work here, especially when one client's proxy suddenly gets flagged and needs a fast swap.
Common mistakes support agencies make
A shared client password across the whole department. Convenient until the first security incident. During a breach investigation, the client will ask for a specific name, and all you'll have is "someone from the evening shift."
One profile covering all of a client's tools (email + Zendesk + CRM). Mixing different services of the same client in one profile lets cookies and fingerprint data pile up chaotically, and handing access to another agent means handing over everything at once instead of granular access to just the service they need.
Ignoring geolocation requirements before signing the contract. This usually surfaces after the fact, when the client blocks a login from the "wrong" country mid-shift and the agency has to scramble to buy a proxy for the right region.
Storing 2FA backup codes in notes on an agent's phone. If the employee leaves or loses the phone, restoring access to a client's account turns into a multi-day project.
No single place showing who's in which account right now. Without a shared dashboard, a team lead only finds out about two agents colliding on the same ticket once the client is already annoyed by duplicate replies.
It also helps to plan the profile and group structure early, before the client count grows past a dozen — the principles are covered in organizing profile pools at scale.
The bottom line
For a support outsourcing agency, an antidetect browser isn't about getting around helpdesk platform rules — it's about meeting clients' access security and geolocation requirements without manual chaos. Cookie and fingerprint isolation removes false positives from Zendesk's and Intercom's anti-fraud systems, roles and profile handoff solve shift changes without passing passwords around, and the activity log gives a ready answer to a client's audit question: "who has access to our account?"
If you're setting this structure up for the first time, it's reasonable to start with the free plan for 3 profiles — enough to test role-based separation across two or three real client accounts before rolling it out to the whole team. More on setting up team access is on the team features page, and on encryption and the 2FA vault on the profile security page.
FAQ
Does this violate Zendesk's or Intercom's rules? No, as long as it's legitimate access by agency staff to a client's account, with the client's knowledge and under contract. Profile isolation and fingerprint management don't create fake accounts — they separate the real working sessions of real employees handling different clients.
Does every client need a separate proxy? Only if the contract requires a specific login geolocation or the client's own anti-fraud system is sensitive to the IP's country. For other clients, a shared proxy pool works fine and keeps costs down.
How fast can access be closed when an agent leaves? The profile stays with the team; that specific person's access is switched off at the role level. Since the client's password was never exposed to the employee directly, revoking access takes seconds rather than requiring the client to reset their password.
What if a client insists on just handing over a login and password with no isolation? It's worth explaining that separated access with an activity log actually protects the client during an audit or incident investigation. In practice, most clients handling personal data end up asking for controlled access themselves once they learn it doesn't complicate the workflow.