Fifty Amazon Client Accounts, One Monday Morning: How Agencies Decide Where to Look First

> ✨ **AI-assisted research, automated editorial review by Avanta Global EOOD.** [Learn more](/disclosure)

An agency managing fifty Amazon seller accounts has fifty dashboards, and that is precisely the problem.

Every tool in this category is built for one seller looking at one account. Point it at fifty and it does the obvious thing: it gives you fifty of itself. The account switcher becomes the most-used control in the product, and the agency's real question — *which of my fifty clients needs me this morning?* — is answered the only way it can be, by a person opening accounts one after another until something looks wrong.

That is not a tooling gap anyone talks about, because it does not look like a bug. Each individual account view is correct. The reports are accurate. Nothing errors. The failure is that the ranking across accounts exists only in someone's head, gets rebuilt from scratch every Monday, and degrades quietly as the client list grows.

## Triage is a different problem from reporting

A seller with one account does not need triage. They know their catalogue, they remember what they changed last week, and the ten minutes they spend in a dashboard are enough to notice anything unusual.

An agency does not have that. Fifty accounts is fifty catalogues, fifty ad structures, fifty fee profiles. Nobody holds that in their head, and the accounts that quietly break are — by construction — the ones nobody opened. The client who emails is not the client with the worst problem. They are the client who noticed.

So the ranking has to run across the whole book:

- Not "here is client nine's account health", but **"among all fifty, this is the worst thing right now"**.
- Not "your ACoS is 34%", but **"this term took £96 in thirty days and returned no orders"**.
- Not a number, but a number **with the account it belongs to attached**.

That last one sounds trivial. It is the part most cross-account views get wrong, because aggregating fifty accounts into one figure is easy and aggregating them into one *ordered list* means committing to a comparison.

## Why every line has to name its source

Here is the constraint that shapes everything else: an agency forwards these findings to clients.

A seller reading their own dashboard can take an unexplained number on faith, because the consequence of being wrong is that they waste an afternoon. An agency putting a number in front of a paying client cannot. The first question is always *where did that come from* — and "the tool said so" is the answer that ends the relationship.

So the useful form of a cross-account finding is not a score. It is a sentence with its provenance attached. The two examples below use invented client names and illustrative figures — they show the shape, not anyone's account:

> **critical** · Marigold Stationery · "discount water bottle" spent 96.61 over 30 days, no orders
> *measured from: that account's search-term history*

> **warning** · Belmont Grills · BELM-204: Amazon fees are 58% of revenue
> *measured from: settlement line items, 60 settled days*

The second line is not decoration. It is what makes the first line defensible in an email to a client, and it is what lets an account manager decide whether they agree. A finding that cannot say where it came from should not be in a report with your agency's name on it.

There is a second, less obvious reason to carry the basis: it makes gaps visible. If a client has not connected their Advertising account, the honest output is *"ad spend could not be read for this account"* — not a quieter number that reads like good news. Silence and health look identical on a dashboard, and telling them apart is most of the value.

## What Amazon's own words are worth

One specific habit is worth stealing regardless of what tooling you use: when Amazon tells you a listing has a problem, quote Amazon.

We learned this by getting it wrong. An early version of our own cross-account check flagged listings whose status column was not `ACTIVE` — which produced 201 criticals out of 209 listings, an alarming number that meant nothing at all. That column never holds `ACTIVE`; it carries Amazon's offer-status set, where `BUYABLE, DISCOVERABLE` is the healthy state. The check was reading a field it had assumed the shape of.

Reading the listing's actual health issues instead — the error and warning strings Amazon itself writes — turned 209 listings into 7 real signals. Those seven were worth a phone call. The 201 were an invented threshold wearing a red badge.

The general rule: **prefer the marketplace's own judgement to a threshold you invented.** Amazon already decides whether a listing is suppressed, whether an account is at risk, and what tier it is in. A homemade bar dressed up as a finding is how a tool teaches its users to ignore it.

## Then someone has to actually do something

Triage is only half of it. Finding the wasted spend on client nine is useful; the change still has to be made, and the agency still owns the consequences of making it.

This is where a lot of agencies stop short of automation, and they are right to. The offer on the table is usually "hand us the keys and the algorithm will manage your bids", which is an unattractive trade when the account is not yours. An optimiser that pauses the one campaign quietly carrying a client's revenue is not a technical incident, it is a client call.

The shape that survives that objection is narrower: let the software — or an AI assistant — **draft** the change, and require a person to approve it before anything reaches Amazon. The important part is that the separation is structural rather than a setting. In our own implementation, the token an assistant uses to file a draft cannot authenticate against the approval endpoint at all; a leaked connector can propose whatever it likes and change nothing. We wrote about that design in detail in [AI drafts, you approve](/blog/ai-drafts-human-approves-amazon-ppc-airlock).

For an agency the approval step is not friction. It is the audit trail — the record of which human agreed to which change on which client's account, on what evidence.

## The failure mode nobody sees coming: acting on the wrong client

If you take one thing from this piece, take this one, because it is the mistake that costs an agency a client and it produces no error message at all.

Twenty clients on amazon.de is twenty accounts and **one marketplace**. Any system that resolves "which account do I write to" by marketplace will find twenty matches and pick one — usually the oldest, because that is what an unordered query returns first. The change is then applied successfully, to the wrong client, and Amazon accepts it. No exception is raised. Nothing turns red. The first signal is a client asking why their bid changed.

We found exactly this shape in our own code and it is worth describing plainly, because if you are evaluating or building agency tooling you should ask about it directly. A resolver keyed on `(user, marketplace)` is correct for a single seller and silently wrong for an agency — and it stays latent until the day a customer connects a second account on the same marketplace. The fix is not a better default. It is refusing to have one: when more than one account could match, the system must **ask which client you meant** rather than choose.

The question to put to any vendor: *what happens when two of my clients sell on the same marketplace?* If the answer is a shrug, you have found the bug before it found you.

## What this does not solve

Three honest limits, because an agency evaluating any of this deserves to hear them before a demo rather than during one.

**Your client cannot log in.** A cross-account view is built for the agency's team. A branded workspace each client signs into is a different product — hierarchy, permissions, billing, isolation — and we have not shipped it. Your team uses the tool; your client reads the report.

**It does not replace your data layer.** If a warehouse connector already feeds your BI, keep it. Deciding what to *do* about the numbers is a separate job from storing them, and the two are not competing.

**Onboarding capacity is finite.** Amazon grants a fixed number of third-party authorisations to an application that is not yet published in its Appstore, which puts a real ceiling on how many agencies can connect at once. Ours is submitted and under review. Any vendor who cannot tell you their current authorisation state is telling you something.

---

We built the cross-account version of this for our own use and are opening it to a handful of agencies. If you run Amazon accounts for clients and want to try it on real ones, the details are on the [agencies page](/agencies) and the tiers are on [pricing](/pricing). We would rather have your feedback than sell you another dashboard.