Writing a contract for fleet work with a client
If you run fleets of accounts for other people, whether that’s marketplace listings, social profiles, or ad accounts, the contract is the part most operators write last and think about least. That’s backwards. A fleet contract isn’t paperwork you bolt on after the sale. It’s the document that decides who eats the loss when a platform bans a batch of accounts, and it’s the only place where you can honestly set expectations about what an antidetect stack can and can’t do.
I run proxy and cloud-phone infrastructure out of Singapore and manage account fleets for a living, so this isn’t theoretical. What follows is what I actually put in writing before I touch a client’s accounts.
Define the scope before you define anything else
Vague scope is where fleet contracts go wrong first. “Manage the client’s social accounts” means nothing. Write down the platform, the account count, the actions you’re authorized to take (posting, messaging, following, listing, bidding), and the actions you’re explicitly not authorized to take. If the client wants growth activity that pushes against a platform’s rate limits, say so in the contract, not in a Slack message six weeks in.
Scope also has to state who the accounts belong to. This matters more than it sounds. If the client is handing you access to accounts they already own and control, that’s a management engagement. If the client is asking you to create new accounts under identities or documents you didn’t verify, or wants you to take over accounts you didn’t onboard yourself, that’s a different risk profile and it needs its own clause: you only operate accounts the client can demonstrate ownership or authorization for. That single sentence protects you from being pulled into something you didn’t sign up for.
Ownership of credentials, devices, and infrastructure
Spell out who owns what at the end of the engagement. Accounts and their credentials belong to the client, full stop. But the infrastructure used to run them, the antidetect browser profiles, the proxy assignments, the cloud phone instances, is usually yours, because it’s the same infrastructure you use across multiple clients and it’s built around your own IP pool and device fleet.
This distinction matters for offboarding. When the contract ends, you hand back account access and credentials. You don’t hand over your proxy configuration or your device fleet, because a client running those accounts on infrastructure they don’t control and didn’t pay to build isn’t something either side actually wants. Write this split into the contract up front so nobody expects a full infra transfer at exit.
Be straight about what detection actually does
This is the section most contracts skip, and it’s the one that prevents the worst conversations later. Platforms don’t ban accounts because they’re “flagged.” They ban them because behavior and device signals stop matching what a real, independent user looks like. A device fingerprint (screen size, GPU renderer, font list, canvas hash), a network signal (IP reputation, ASN, whether that IP is shared across dozens of other accounts), and a behavior pattern (session timing, action velocity, navigation flow) all get scored together. When too many of a platform’s signals line up between accounts that are supposed to be unrelated, enforcement acts on the cluster, not just the outlier account.
An antidetect browser gives each account its own consistent fingerprint profile instead of the one your OS naturally exposes. A dedicated residential or mobile IP, one that isn’t shared with other tenants running the same activity, keeps the network signal from linking accounts together. A cloud phone adds a real mobile stack (a genuine IMEI, carrier-issued IP, real sensor data) for platforms that specifically check for mobile-native signals. None of this makes an account undetectable. It reduces the number of signals that tie your accounts to each other or to prior bans on the same infrastructure. That’s a meaningfully different claim, and it’s the one your contract should make.
Put a no-guarantee clause in plainly: you cannot promise an account won’t be banned, suspended, or limited, because enforcement decisions are made by the platform based on signals and policies you don’t control. Any operator who tells a client otherwise is either lying or hasn’t run a fleet long enough to watch a policy update wipe out a batch overnight.
Document the isolation setup per account
Because you can’t guarantee outcomes, you want the contract to reference a record of process instead. Keep a per-account log: which browser profile, which proxy or SIM, which device, and when it was assigned. This isn’t for the client to audit your infrastructure. It’s so that if an account gets banned, you can show the isolation was actually built correctly, that the account wasn’t sharing a fingerprint or IP with something else in the fleet, and separate “this fell to enforcement despite clean isolation” from “this fell because of a mistake in setup.” Reference this log in the contract as the basis for any dispute over whether the work was done to standard. Without it, every ban turns into a he-said-she-said argument about whether you did your job.
Structure payment around the real risk
Flat monthly retainers work until an enforcement wave takes out a third of the fleet and the client wants to know why they’re still paying full price. Milestone or per-account-active pricing handles this more honestly: pay for setup and warm-up as one line, pay an ongoing fee per account that stays active, and state clearly that replacement of banned accounts is a new setup cost, not a warranty repair. This keeps the incentive structure honest on both sides. You’re not paid a flat fee regardless of outcome, and the client isn’t expecting free replacements for something neither of you controls.
Put the warm-up timeline in writing
New accounts that get pushed to full activity immediately are the ones most likely to trip behavioral detection, because a brand-new account acting like a five-year-old power user is itself a signal. A realistic warm-up schedule, low activity for the first stretch, gradually increasing over weeks, needs to be in the contract as a timeline the client agrees to. This protects you from a client who wants results in week one and protects the client from the false idea that speed is free. If they want a faster ramp, that’s their call to make in writing, with the added risk stated next to it.
Termination and offboarding
State what happens when either side wants out: notice period, what’s handed back, what happens to in-progress warm-up accounts, and whether partial-month fees apply. Also state data handling: once accounts are handed back, you stop touching them from your infrastructure, and you say when that access is revoked. A clean handoff date avoids the awkward situation where an account gets flagged after offboarding and nobody’s sure whose infrastructure touched it last.
The short version
A fleet contract should nail down five things: exact scope of accounts and actions, who owns what infrastructure and credentials, an explicit no-guarantee statement on bans tied to how detection actually works, a per-account isolation record you can point to if something goes wrong, and a payment structure that doesn’t pretend account loss is impossible. Skip any of these and you’re one enforcement wave away from a dispute that didn’t need to happen.
If you’re building out the infrastructure side of this, from antidetect browser profiles to dedicated residential and mobile proxies and real cloud phones for account isolation, that’s what we cover on Multi Account Ops.
Head back to the homepage for more on the tools and setup behind this.
Get new guides and videos first — join the Telegram channel.