Multi-Accounting for Tender Agencies: Client Portals Done Right

GetAntik editorial team · October 7, 2026 · 11 min read

How bid management agencies keep dozens of client procurement accounts separate, secure, and deadline-proof using isolated browser profiles.

A bid management agency rarely works with a single client. A typical portfolio runs 15–40 companies: some bid on public procurement a few times a quarter, others submit to commercial sourcing platforms every week. Each client has a separate portal login, their own digital signature or hardware token, their own registration details, and sometimes a different region of incorporation. A specialist at the agency ends up logging in and out of different accounts — often several times within one working day.

The problem is that most procurement portals (government e-tender platforms, industry b2b marketplaces, corporate supplier portals) don't just check login and password. They log IP address, browser fingerprint, and sometimes the device a bid was submitted from. If a specialist logs into five client accounts back to back from the same browser and the same IP, that's not a legal violation — platforms generally don't forbid an authorized agent acting on a client's behalf under a power of attorney. But it creates operational risk: anything from accidentally sending a document to the wrong account to an account getting flagged because the client's IP suddenly doesn't match their registered business address.

What actually breaks without separation

In practice, what fails in tender agencies isn't strategy — it's day-to-day routine:

• Sessions bleed into each other. A specialist opens Client A's portal in one tab, Client B's in another. Cookies from one account sometimes leak into the other context, especially if the platform uses shared subdomains or a single sign-on across a group of services.
• Signatures and logins are stored haphazardly — in notes, in a shared spreadsheet, in chat messages. When a team member leaves, figuring out who had access to what takes half a day, and sometimes it turns out only the departed employee knew the password.
• Geolocation stops matching. A platform sees a login under a client from a region that doesn't match the company's registration address and requests additional verification right before the submission deadline.
• There's no action history. If a bid goes out with a typo or gets submitted to the wrong lot, the only way to reconstruct who did it and when is by memory.

None of this is about fraud — the agency is acting legally, under a power of attorney, in the client's interest. But without infrastructure to keep accounts separated, small mistakes accumulate, and as the client portfolio grows they become systemic.

One profile, one client

The working model is simple: each client gets an isolated browser profile with its own set of cookies, history, extensions, and network settings. This isn't a new idea for agencies — SEO agencies and accounting firms apply the same principle because they also have to keep dozens of client portals in order (we covered this in a piece on multi-accounting for accountants and lawyers, and the logic there is nearly identical).

For a tender agency, profile isolation solves three problems at once:

1. It technically prevents session mixing. Cookies, local storage, and history for one client are physically invisible inside another client's profile — even if a specialist works in several windows at once.
2. It removes geolocation mismatches as a source of false alarms. The proxy is matched to the client's registered region, so the platform sees a login from the expected location rather than from the agency's office in a different city.
3. It gives the team clean access control by role — more on that below.

Proxies: not a luxury, a match for the registration address

On many e-tender platforms, a suspicious IP triggers manual document review, which can cost an agency a day or two right in the middle of bidding season. If a client is registered in one city and the login comes through a datacenter IP on another continent, it's not a disaster, but it's an unnecessary risk.

The practical approach is to keep proxies at the profile level, matched to the client's region, and check them before every important submission. In the proxy manager you can see the status and exit country for each profile at a glance, instead of guessing which IP Client X is currently connected through.

Tender work usually calls for static residential or mobile proxies tied to one region for the entire duration of the client relationship — rotation isn't needed here and can even hurt, because the platform gets used to seeing one consistent IP and requests fewer confirmations. Different proxy types and when to use each are covered in detail in the article on proxy types for multi-accounting.

Digital signatures and 2FA — a separate headache

A digital signature usually lives on a physical hardware token or as a signed file, and an antidetect browser doesn't replace that layer — it's a hardware or cryptographic component the browser doesn't touch directly. But there's always a cluster of related things around a signature that are convenient to keep in a profile: saved login pages for the platform, bookmarks with client-specific instructions, two-factor codes for a related account (not the signature itself, but say the client's email or a service portal tied to the bid).

A per-profile 2FA key vault removes one of the most common causes of missed deadlines — a forgotten second-factor secret that only one employee knew and took with them when they left. More on how the encryption and recovery process works in the piece on profile security and the 2FA vault.

Team: who sees what, and who gets to hit "submit"

In a tender agency, speed matters less than control at the moment right before submission — a mistake there means losing a bid entirely. It makes sense to split roles:

• Specialist (member) prepares the bid inside the client's profile: fills out forms, attaches documents, checks completeness.
• Project lead (admin) reviews the profile before final submission — this can be done through a live view of a teammate's browser, without asking for screenshots or taking over their workstation.
• Finance (finance) sees accounts where bid security amounts and bank guarantees are relevant, but doesn't touch the actual submission.

This kind of permission and limit split is covered in more detail in the article on team roles, limits, and profile handoff. For a tender agency, profile handoff matters especially: a specialist goes on vacation, the client's profile gets passed to a colleague without changing the password and without calling the client to ask for access again.

If an employee leaves the agency entirely rather than just switching projects, the process is a separate topic we covered in our checklist on closing access after an offboarding: profiles get reassigned, client portal passwords are changed immediately, and access to the 2FA vault is revoked first.

Cookies and re-logins right before a deadline

Many procurement platforms have short session lifetimes, and re-authentication often requires an SMS code or a captcha. If a bid is being prepared an hour before the lot closes and the platform suddenly asks for re-verification, there may not be time to deal with it. A warmed-up profile that gets logged into regularly, even if rarely, raises fewer flags than an account that only logs in once every three months from a brand-new IP.

Scheduled cookie warm-up at the profile level is a simple fix: log in every one to two weeks, briefly check the account, log out. This cuts down on emergency verification prompts on submission day. The logic is the same as warming up advertising accounts, just with a different goal — not avoiding a ban, but avoiding an inconvenient verification request at the wrong moment. General warm-up principles are covered in the article on preparing profiles before active work.

Table: three ways to organize client portal access

For an agency handling 30–50 clients, the third option usually ends up being the only one that doesn't require buying a fleet of laptops or ending up with a zoo of passwords scattered across chat apps.

Common mistakes

Using one agency-wide login for every client wherever the platform technically allows it. Some platforms let an agent work through a single access point with representative rights across multiple organizations. That's convenient right up until the first mistake picking the wrong entity from a dropdown — and with dozens of active bids running in parallel, that kind of mistake is statistically inevitable. A separate profile per client specifically guards against this kind of human error.

A one-size-fits-all proxy with no match to the client's region. One shared proxy for every account saves money on the plan, but creates a constant reason for verification requests and makes the agency's behavior look atypical to the platform.

Storing signature files and passwords on a shared cloud drive with no access control. If the drive is accessible to the whole team, one employee leaving means changing access for everyone — that's slower than revoking permissions for a single person in a system with proper roles.

No activity log. When a client asks why a bid went out late, it helps to have more than "I think John did something wrong" — a concrete log of who logged in, when, and what changed.

Mixing work and personal browsing. A specialist handling personal tasks in the same browser where client portals are open risks accidentally logging into the wrong account or leaving a session open on screen during an unrelated demo.

The economics

For an agency with 20–30 active clients, a 100-profile plan is usually enough, leaving room for backup and test profiles that aren't tied to a specific client. As the portfolio grows toward a hundred clients and beyond, it makes sense to move to a 300-profile plan, keeping in mind that some profiles are always tied up training new hires or handling one-off bids. How to calculate these costs systematically, without stockpiling profiles "just in case," is covered in the article on multi-accounting economics and team budgeting.

If the client portfolio has already grown past fifty and profiles were created haphazardly — no groups, no clear naming convention, no assigned owner — it's worth cleaning up the structure before onboarding more clients. There's a separate piece on organizing a large profile pool without chaos: how to organize hundreds of profiles without drowning in them.

Setting this up in practice

1. Create a profile for each client in GetAntik, naming it after the client's legal entity and the platform it works with.
2. Connect a proxy matched to the client's registered region through the proxy manager and check it before the first login.
3. Set up a cookie warm-up schedule — every one to two weeks, no active actions, just enough to keep the session alive.
4. Store 2FA keys for related services (client email, internal portal) in the profile vault.
5. Assign roles and limits across the team: who prepares the bid, who reviews before submission, who sees financial data.
6. Document an internal handoff policy for when an employee is on leave or leaves the company — this isn't a technical setting, it's a team agreement, but the technical part won't help without it.

Profile data is encrypted on the device with the account password — the server has no access to the contents, which is a real argument in favor of this setup when client trade secrets and the terms of their bids are involved. More on the approach to encryption on the security page.

FAQ

Is it legal to manage multiple client accounts from a single workstation? Yes, as long as the agency is acting under a power of attorney or contract with each client and follows the rules of the specific platform. An antidetect browser isn't a tool for getting around restrictions here — it's a way to organize already-legal work so that client accounts don't technically overlap.

Can bid submission be automated? Monitoring new lots, collecting documentation, checking statuses — yes, that's reasonable to automate with Puppeteer or Playwright over CDP. Actually submitting the bid is something most agencies leave to a human: the cost of a formatting mistake or an attached file is too high.

What if the platform still asks for identity verification at login? That's normal platform behavior, not a sign of a misconfigured profile. Isolation and a stable IP reduce how often this happens, but they don't eliminate it entirely — it's a feature of how procurement platforms handle agent access, not a bug.

Do profiles need to be separated if the agency only has two or three clients? Technically you can skip it at the start. But even with three clients, separation saves time switching between accounts and removes the risk of accidentally mixing up documents — setting it up once is cheaper than dealing with the fallout of a mistake right before a submission deadline.

tender agenciesmulti-accountingantidetect browserproxy managementteam access control