Every agency that runs LinkedIn outreach at scale eventually has The Conversation. A client account goes from “performing well” to “restricted” overnight. The team scrambles, the client emails, and somebody on Slack types the sentence we’ve all read: “I don’t understand, we weren’t doing anything different.”
Almost always, you were doing something different. The difference is just that you couldn’t see it.
This piece is for agency owners and ops leads running 5+ LinkedIn accounts and trying to avoid that conversation. It’s not a “be careful” article — those are useless. It’s the actual operational playbook the agencies that don’t get restricted run on.
What “restricted” actually means
LinkedIn restrictions come in three tiers, and conflating them is one of the reasons the topic is so confusing.
Tier 1: Soft warning. The “You’re sending too many invitations” banner. The account is still functional; LinkedIn is telling you to slow down. This is your free pass — if you respond by pausing or reducing, the account heals in 3–7 days. If you ignore it, you escalate to Tier 2 within a week.
Tier 2: Temporary restriction. Connection requests are blocked for 24 hours to 30 days, depending on the severity. The profile is still browseable, messaging often still works, but outbound is gone. Most agencies’ “we got restricted” stories are at this tier.
Tier 3: Permanent restriction / account suspension. Connection requests and sometimes profile access are blocked indefinitely. Recovery requires LinkedIn customer support and, in practice, succeeds maybe 30% of the time. This is rare and almost always the result of either ignoring multiple Tier 1 warnings or doing something genuinely outside policy (scraping, fake profiles, paid endorsement schemes).
The agency goal is straightforward: never let a Tier 1 warning escalate to Tier 2, and structure operations so Tier 1 warnings are rare in the first place.
The four ways agencies actually get restricted
After three years of customer postmortems, the failure modes cluster into four buckets. Almost every restriction we’ve investigated traces back to one of these.
1. Shared infrastructure
The single biggest cause. Either:
- The agency uses an automation tool that pools IP addresses across customers, and LinkedIn fingerprints the shared exit node
- Or the agency uses one residential proxy for multiple accounts they manage internally
- Or the team logs into client accounts from the agency office Wi-Fi, then from home, then from the office again
LinkedIn’s anti-abuse model treats a single IP serving multiple distinct logins as a strong signal that something automated and coordinated is happening. It’s correct, mostly — that’s exactly what’s happening, even if it’s legitimate.
The fix: every LinkedIn account gets its own dedicated residential IP, geo-matched to where the account holder actually is, and that IP doesn’t rotate. Not a shared pool, not a datacentre IP, not a VPN endpoint shared by 200 other customers of the same tool.
2. Inhuman behaviour timing
Real humans don’t send 40 invitations at 9:00:00, 9:00:01, 9:00:02. They don’t operate 24 hours a day. They don’t send identical message text to 50 people in the same minute.
Most automation tools — the ones built for individual freelancers — get this wrong by default. They batch-send during off hours because that’s when most people set their campaigns to run, which means LinkedIn sees obvious time-clustered activity from accounts whose owners are supposedly working a 9–6.
The fix: randomised send windows that mirror real working hours in the account holder’s timezone. Randomised micro-delays between actions (15 seconds to 3 minutes). Randomised gaps between sessions. Time-of-day windows that include lunch breaks and end-of-day drop-offs. The tooling that gets this right doesn’t just have “send between 9 and 5” — it has a behaviour profile per account.
3. Ignoring per-account ceilings
We wrote a separate piece on the real LinkedIn weekly invitation limit, but the short version is: each account has its own dynamic ceiling between 80 and 200 invitations/week, and treating every account as if it can handle 150 is how new accounts get restricted in their first month.
Agencies make this mistake structurally. The campaign manager sets a default volume in the tool, the tool applies it everywhere, and the youngest account on the roster gets crushed.
The fix: per-account weekly caps that adapt based on each account’s age, engagement, and observed throttle signals. The newest account on a 10-account roster might be running at 60/week while the most established is at 180. Manually managing this is feasible at 2–3 accounts and basically impossible at 10+.
4. Ignoring verification prompts
LinkedIn occasionally pushes a security verification — a captcha, a phone code, sometimes a request to confirm identity with ID. These are not strictly punishments; they’re sanity checks the system runs when behaviour looks slightly off.
The way agencies get into trouble: their automation tool sees the verification prompt, doesn’t know what to do with it, and either retries the action repeatedly (which compounds the “this is automated” signal) or quietly logs the account out and keeps trying to operate, generating more failure signals.
The fix: a hard stop on the specific account the moment a verification prompt appears. No retries. Notify the agency operator. The agency completes the verification through the client’s actual login. The system resumes from where it paused. Other accounts on the same workspace are unaffected.
What this looks like in practice
The agencies we work with that operate cleanly at 10+ accounts have, almost without exception, the same four operational habits:
- One IP per account, kept warm. They don’t rotate proxies. They don’t share. If a client account is meant to be a Manchester-based founder, the IP looks like Manchester and stays that way.
- Onboarding ramps. New accounts start at 30–40 invitations/week for the first two weeks, then 60 for two weeks, then 90, then settle wherever the account’s ceiling lands. They never start a fresh account at the volume an established account is running.
- Weekly account-health review. Someone — usually an ops lead — looks at acceptance rates, reply rates, and any throttle signals across the whole roster every Monday. Accounts in the warning zone get backed off proactively.
- A documented response plan for restrictions. When Tier 1 lands, the playbook is: pause that account, notify the client, wait 5–7 days, ramp back at 50% of previous volume. When Tier 2 lands, the playbook involves an apology email and a clear expectation reset. Having the playbook ready beats inventing it under pressure.
The agencies that get into trouble do most of this informally, then forget. Then the team grows, the account count grows, and the informal habits break first.
The tooling question
We’re biased — Badgr exists specifically to handle this set of operational problems at multi-account scale. But the honest version of the tooling advice is:
If you run 1–3 LinkedIn accounts, you can manage safety manually with most tools on the market. Pick one that gives you dedicated proxies, pay for them, and follow the ramp-up rules above.
If you run 5+ accounts, look for three specific things:
- Dedicated 1:1 residential proxies per account (not a pool, not datacentre IPs)
- Per-account throttling that adapts to observed signals
- A hard kill-switch on verification prompts — not retry logic
Most tools built for individual users have one or two of these. Tools built for agencies — Badgr, HeyReach, Meet Alfred — have all three to varying degrees. The pricing model usually tells you who the tool is built for: per-seat pricing means it’s a tool for individuals being sold to agencies, flat per-account pricing means it’s built for agency operations.
A worked example
Last quarter we onboarded a UK lead-gen agency running 14 LinkedIn accounts for 11 clients. They came to us after losing two accounts to Tier 2 restrictions in a single month. Their existing tool was a popular per-seat product that, on paper, did everything they needed.
The audit took an afternoon. What we found:
- All 14 accounts were running through 3 shared residential IPs.
- The weekly cap setting was identical (140) across every account, regardless of age — including two accounts under 60 days old.
- The tool’s verification handler was set to “retry after 30 minutes,” which had been quietly retrying through 6+ failed verifications on one of the restricted accounts before the restriction landed.
- No one had been running a weekly health review since their old ops lead left in February.
We migrated them in a week. New per-account proxies, per-account ceilings set from observed history, kill-switch on verification, weekly review back on the team’s Monday agenda. They’ve onboarded four more clients since and haven’t lost an account.
Almost none of this is unique to Badgr — most of it is operational discipline. Tooling makes it cheap and consistent across 10+ accounts; it doesn’t replace the discipline.
The summary, if you skipped to the bottom
- Restrictions are mostly preventable. They cluster around four causes: shared infrastructure, inhuman timing, ignoring per-account limits, and ignoring verification prompts.
- Per-account discipline is the differentiator. Treating every account as if it’s the same is the most common mistake.
- Per-account dedicated proxies, behaviour-randomised actions, adaptive throttling, and a hard kill-switch on verification are the four operational pillars worth designing around.
- If you’re running 5+ accounts, weekly health reviews are not optional.
- If you’re running 10+, tooling that does this without you having to remember becomes load-bearing.
If you want the four pillars handled automatically across every account you run, Badgr starts at £39/month with everything included — no per-seat tax, no “safety is an add-on”, no shared proxies even on the cheapest tier.