How Many Profiles Per Person: Sizing Your Team's Workload

GetAntik editorial team · October 16, 2026 · 10 min read

A practical formula for how many browser profiles one person can realistically handle, by task type, hardware limits, and team roles.

A manager buys a 100-profile plan, hires two people, and expects each to run 50 accounts. A month later both are drowning: missed notifications, mixed-up clients, forgotten warm-ups. The problem isn't the plan or the people — nobody calculated how many profiles one person can physically handle for a given task. This is the calculation that usually gets skipped between buying licenses and setting KPIs, and skipping it is costly: it determines whether the team burns out or not.

Why "how many profiles" is the wrong question

The number of profiles alone says nothing about workload. Twenty accounts that need a listing status check once a week is half an hour of work. Twenty accounts with live support chat is a full day and then some. Workload isn't a function of profile count — it's the product of three variables:

• Contact frequency — how many times a day or week the profile needs attention;
• Time per contact — from 30 seconds (check a metric) to 20+ minutes (write to a client, handle a ticket, tune a campaign);
• Cognitive cost of switching — how much context has to stay in someone's head: whose budget is whose, what tone each conversation needs, what was agreed yesterday.

If you only count the first two factors, the math is simple: total contact time per shift shouldn't exceed 80–85% of working hours (the rest goes to the unplanned stuff — rotating a proxy, resolving a block, answering in team chats). But the third factor — context switching — drains focus non-linearly: past 15–20 switches per hour, error rates climb sharply even when each individual task is short.

Typical ranges by task type

Below are reference points drawn from teams that manage profiles daily. These aren't standards — they're a starting point for your own calculation.

The 5–10x spread between rows is exactly why a single "profiles per person" number is meaningless without tying it to the task. If a team mixes task types, workload needs to be calculated separately for each group of profiles, not averaged across the whole pool.

The hardware ceiling

There's another hard limit, independent of skill or task type: machine resources. A Chromium-based antidetect browser opens each profile as an isolated window with its own process, and that's not free in terms of RAM and CPU.

Rough reference points for a work laptop:

• 8 GB RAM — comfortably handles 3–5 simultaneously open profiles with an active tab; more and things start lagging;
• 16 GB RAM — 8–12 profiles at once without significant degradation;
• 32 GB RAM and up — 15–25 profiles, assuming they're not heavy SPA interfaces like ad dashboards.

The key word is "simultaneously open." If someone runs 40 profiles but goes through them one at a time, closing the previous one, hardware won't be the bottleneck. The problem shows up when several windows need to stay open in parallel — comparing data across three ad accounts, say, or maintaining parallel conversations in different roles. In those scenarios, the hardware limit becomes tighter than the attention limit, and it's worth testing on a real machine before planning workload on paper.

How to calculate this in practice

A working process that resolves most "how many should we give this person" arguments:

1. Group profiles by task type, not by client or platform. Within a group, workload is homogeneous and easy to estimate from the table above or through time-tracking.
2. Measure actual time on 10–15 contacts per profile with a stopwatch, not by guessing. The gap between "feels like 2 minutes" and "actually 7 minutes" shows up constantly, especially when the process includes a warm-up step or checking a 2FA code.
3. Multiply average time by frequency and compare against available working hours, minus 15–20% for overhead — proxy swaps, dealing with blocks, communicating with a manager.
4. Add a context-switching buffer — 10–15% on top for low-cognitive-load tasks, 25–30% for high-load ones (messaging, sales, support).
5. Recalculate quarterly, because contact frequency changes: a new platform tightens activity requirements, a client asks for faster responses, a manual warm-up step gets added.

It's also worth planning for the day someone gets sick or quits. If all the workload sits with one person with no knowledge sharing, handing off profiles quickly won't be possible — this is covered in detail in the piece on closing access when an employee leaves. At the planning stage, it's sensible to set aside 10–15% of profiles as a "hot reserve" that a second person can pick up without a long ramp-up.

Roles and limits instead of manual tracking

Calculating workload in a spreadsheet is useful once, to get a sense of the right order of magnitude, but keeping it current manually is a bad idea: people change, clients get added, profiles migrate between employees. GetAntik has a role model for this — owner, admin, member, and a finance role, each with different permissions — and every member can have a profile limit and access to only part of the shared pool.

That turns workload calculation from a one-off spreadsheet into a standing constraint at the system level — an employee physically can't grab 80 profiles if their limit is set to 30. The shared profile pool stays visible to the whole team, and handing a profile between employees doesn't require rebuilding the environment: proxies, cookies, history, and 2FA keys don't need to be moved by hand. How to structure the pool itself so groups and tags don't get lost as profile count grows is covered in the article on organizing hundreds of profiles without chaos.

The activity log shows how many times a day someone actually opened a profile and how long they spent there — far more accurate than self-reporting, and it lets you recalculate workload based on what actually happened, not what was planned.

Automation reduces workload but doesn't eliminate it

Some routine contacts — checking status, pulling metrics, warming up a session — can be taken off a person's plate using the local automation API with Puppeteer, Playwright, or Selenium over CDP. This works especially well for the tasks at the top of the table: price monitoring, listing availability checks, scheduled cookie warm-ups.

But automation doesn't remove the human where judgment or a genuine written response is required: shifting tone in a conversation, reacting to an unusual client request, sorting out a moderation dispute. A common mistake when moving to automation is trying to automate everything and setting an unrealistic plan — "since scripts handle the routine, one person can run 200 profiles." In practice automation removes 30–50% of time from a task group, not the whole workload; what's worth automating and what isn't is covered in the piece on automating profiles with Puppeteer and Playwright.

Common planning mistakes

Counting profiles instead of hours. "We have 300 profiles and 3 people, so 100 each" is arithmetic that ignores the fact that 100 profiles with active conversations and 100 with passive monitoring require very different headcounts.

Not building in a buffer for incidents. An account block, an expired proxy, a captcha — all of this eats time beyond the plan. Teams that calculate workload too tightly fall apart at the first mass proxy provider outage.

Ignoring time zones. If a profile is tied to a proxy with an exit IP in another country while the employee works in their own time zone, activity on the profile can land at an "unnatural" time for that geolocation — this isn't just a discipline issue, it's a factor platforms weigh when evaluating an account. Time zone and interface language in the antidetect browser are pulled from the proxy's exit IP automatically, but the person's work schedule still needs to account for it.

Assigning profiles on a first-come-first-served basis. Without grouping and limits in the system, workload skews over time: the faster-reacting employee keeps picking up more profiles, while a less experienced one gets fewer, and the gap in client knowledge only widens.

Not revisiting limits when a platform raises its requirements. A platform adds extra verification or asks for activity confirmation more often — time per profile goes up, but the workload plan stays the same for another month until someone notices the backlog.

How this relates to plan limits

The profile limit on a plan and the profile limit per employee are different things, and shouldn't be confused when planning. The plan caps how many profiles can exist in the company account at all; the per-employee limit caps how many of those one person can actually handle.

The ratio of "profiles in the plan" to "people on the team" is always greater than one — some profiles sit idle, some are run in parallel by several people through the shared pool, some are kept in reserve. If your workload calculation shows that a team of 5 physically needs 400 active profiles simultaneously, that's a signal not to buy a bigger plan right away, but to first check whether contact frequency is artificially inflated — for example, by the absence of automation for routine checks. The economics — what a profile actually costs once you factor in proxies, licensing, and employee time — are easier to work out separately, as covered in the article on multi-accounting unit economics and team profile budgets.

Before upgrading a plan, it's worth checking current terms on the pricing page and reviewing what team features are available at the tier you need — role, limit, and profile handoff details are on the team features page.

FAQ

How do I know an employee is overloaded if they're not complaining? Check the activity log: the average idle time between scheduled profile touches grows, scheduled warm-ups get skipped, and the share of "urgent" after-the-fact fixes increases. This is more objective than waiting for someone to say they can't keep up.

Can I temporarily give an employee more profiles than their usual limit during a peak period? Yes, the per-member limit in the system is adjustable — raise it for a launch or a promotion and lower it back afterward. Just don't forget to lower it, or the temporary fix becomes permanent overwork.

Do different task types need machines with different hardware, or doesn't it matter? What matters is the number of simultaneously open windows, not the task itself. If someone keeps three or four windows open with active work at once, give them a machine with more RAM headroom regardless of whether the task is support or advertising.

How fast can a new employee pick up part of someone else's workload? Fastest path: hand off a profile within the shared pool without rebuilding the environment, and use live view of a colleague's browser for the first few interactions so context transfers without lengthy verbal explanation.

Should workload be calculated separately for manual and automated profiles? Yes. An automated profile doesn't need constant attention — just periodic checks that the script hasn't broken and handling exceptions. That's a different kind of workload in character, and mixing it with manual work in the same estimate isn't a good idea.

team managementworkload planningantidetect browserprofile managementmulti-accounting