The Prime Day Command Center: One Dashboard Across Every Account

Every agency that manages more than a handful of Amazon accounts has the same experience during a peak event. The strategy was fine. The prep was fine. What went wrong is that at 2pm on day one, nobody could say which of the thirty accounts needed attention next, so attention went to the client who emailed rather than to the account that was quietly burning.

This year Prime Big Deal Days will be a 48 hour window on October 6 and 7.  The constraint isn't changing. Two days in which a month of decisions arrives at once, across every account you manage, simultaneously.

A command center is the answer most agencies reach for. Most of them build it as a spreadsheet, discover on day one that nobody has time to refresh it, and go back to reading accounts one at a time. What follows is how to build one that survives the event: the exact columns worth carrying, how to decide your refresh interval, and how to get a ranked list of which account a human should open next.

Quick answer

• What it is. A single view rendering the current state of every account on your roster at once, refreshed on a schedule you set, with enough per-account context that a strategist can tell in one pass which client needs a human.
• What it changes. Attention gets allocated by which account is furthest from plan rather than by which client emailed. Across a 96 hour window, that is most of the difference between a peak event you managed and one that managed you.
• It is two layers. A dashboard that reports state, and a second layer that reads that dashboard and ranks where to look first. Thirty rows of accurate data still leaves you guessing where to start.
• Six fields earn their place: spend against plan so far today, pace state, efficiency against the account's own target, deal and promo state, inventory cover on the deal ASINs, and last human touch. The column spec below is copyable.
• Refresh interval is a design decision. Hourly pacing is achievable through Amazon Marketing Stream. Sales and conversion figures keep settling after the fact, so label those columns with their own latency.
• Build it before the date is announced. The roster, the per-account plan numbers, and your definition of off-plan are all things you can have in place before Amazon publishes anything.
• The hard part is not technical. If your agency does not currently agree on what off-plan means for a given client, a dashboard will surface that disagreement at the worst possible moment.

The roster is what breaks during peak week

Any single account is manageable during Prime Day. You know the client, you know the promo plan, you know which ASINs matter. One person can hold it.

What does not scale is the switching. Thirty accounts means thirty sets of context, and during a 48 to 96 hour window a strategist is asked to reload that context every time somebody pings. Reading an account is cheap. The expensive part is that the twelfth reload is worse than the first, and by the second night the standard you would apply to account one is not the standard you are applying to account twenty-six.

The second failure is coverage. Attention gets allocated by who is loudest rather than by who is furthest from plan. Our own Prime Day advertising budget guide notes that Day 1 of Prime Day 2025 drove the largest share of Sponsored Products sales, with the remaining days landing meaningfully lower. If your senior people spend the first six hours on the two accounts that happened to call, you spent the highest-value hours of the event on a sample of your roster chosen by chance.

Neither of those is fixed by working harder during the event. They are fixed by having a view built before it.

What one screen has to tell you about thirty accounts

The instinct is to put everything on the dashboard. Resist it. A cross-account view is read at a glance by a tired person, and every column you add costs a fraction of a second per account, times thirty accounts, times every refresh.

The column spec: six fields, and what goes in each cell

This is the set that has held up for a peak event. Build it in whatever you already use. The point of writing it out as a spec rather than a wish list is that the source and the refresh rate are decisions you have to make per column, and making them late is how a dashboard ends up with three columns nobody trusts.

That last row is the field agencies skip and then miss most. During a fast-moving window, "nobody has opened this account in nine hours" is often more actionable than any performance number on the row, and it is the only column that has to be written by a person rather than pulled from an API.

Two notes on the "flag it when" column. Every threshold in it is per account rather than shared, which is the whole reason the dashboard is worth building: a 45 percent ACoS account and a 12 percent ACoS account both look wrong against a house benchmark. And the efficiency row is the one to set carefully, because conversions attribute back to the hour of the click, so the most recent hour always looks worse than it turns out to be.

Refresh interval is a design decision, not a setting

Decide how fresh the view needs to be before you decide what goes on it, because the answer changes the build.

Amazon's standard reporting is not a live feed, and report figures continue to settle after the fact. Amazon Marketing Stream exists specifically for this problem: it pushes hourly campaign performance and budget-consumption messages in near real time to advertisers and agencies integrated with the Ads API, rather than making you pull a report and wait. We wrote up the mechanics in our guide to Amazon Marketing Stream.

Be honest about the tradeoff in your own build. An hourly view of spend and pacing is achievable and useful. A view that treats sales and conversion figures from the last hour as final will make somebody act on a number that moves later. Label the columns with their own latency and the argument at 11pm gets shorter.

A spreadsheet gets you the view once

Before reaching for anything new, walk what you already have. Each of these is a reasonable answer to part of the problem, and most agencies are running two or three of them right now.

The native console and manager accounts. Amazon's manager account structure does real work here: one login, nested structure, switching between advertiser accounts without re-authenticating, permissions managed centrally. What it gives you is access to thirty accounts. What it does not give you is thirty accounts on one screen with your definition of "off plan" applied to each.

Bulk exports into a spreadsheet. This is the most common command center in the category and it works, once. Somebody pulls the files, pastes them into the model, and the view is genuinely good. Then it is two hours later and the view is stale, and the person who knows how to refresh it is on a client call.

A BI dashboard on warehoused data. If your agency already pipes marketplace data into a warehouse, this is the strongest option on the list for reporting state, and it refreshes without a human. Its limit is that it reports numbers rather than judgment. It will show you that account nineteen is at 140 percent of pace, and it will not know that account nineteen front-loads deliberately every year and that is fine.

A general-purpose AI tool with your exported data pasted in. Genuinely good at reading one messy export and telling you what stands out. Two problems at roster scale: you are the integration layer, pasting exports one account at a time, and asking the same question twice does not reliably return a comparable answer, so you cannot lay this hour's read next to last hour's and see what moved.

The break point is the same in all four: producing the view is not the hard part, producing it again is. A command center that needs a person to rebuild it every hour will get rebuilt twice on day one and then abandoned, which is exactly when you needed it.

One skill, one roster, one pinned dashboard

The build that holds up during an event is one where the view rebuilds itself.

Qore is where you take a review you currently do by hand, write it down as an inspectable standard, and have it run on a schedule instead of when somebody remembers. For a peak event, the thing you write down is the column spec above: what goes in each cell, where it comes from, and what "off plan" is for this client specifically.

Three properties matter for roster work:

Per-account instances of one skill. You author the read once, then run it as an instance per account on your roster. Each instance carries that account's own targets and thresholds, so account nineteen's deliberate front-loading is encoded as account nineteen's plan rather than showing up as a red cell every year. When you change the read, you change it in one place.

A pinned dashboard. The output lands somewhere persistent rather than in a chat thread or a file somebody has to find. During the window, the command center is a URL that is already open on a second monitor, not an artifact someone regenerates.

Reproducibility. Same inputs return the same output, and the logic is inspectable. That sounds like a nice-to-have until 3am on day two, when the read changes and the first question is whether the account moved or the read moved. If the logic is visible and stable, you can answer that in a minute.

What this does not do: it does not replace your bid engine, and it does not decide your strategy. Codifying the read requires the read to exist. If your agency does not currently agree on what "off plan" means for a given client, a dashboard will surface that disagreement at the worst possible moment rather than resolve it. That work happens in the dry run, not during the event.

The second skill reads the dashboard so a person does not have to

A dashboard reports state. It does not tell you which state is worth an hour of a senior strategist's time. At thirty accounts, that gap is the whole problem: the view is right there and still nobody knows where to start.

So chain a second skill onto the first. It takes the dashboard output as its input and produces one ranked list: the accounts a human should open next, in order, each with the reason it made the list and what to check when you get there.

The reason line is the part that earns its keep, and it is worth specifying rather than leaving to whatever the skill writes. Five parts, in this order: the account, what is off, by how much and at what hour, the context that changes the read, and the first thing to check.

So: "Account 12, pacing 168 percent of plan at hour 4, deal live, cover thin on two of three deal ASINs, check cover before you cut budget." A strategist can act on that without opening anything else first. "Account 12: spend high" sends them into the console to work out what you already knew, and a red cell does neither.

Two things to hold onto here. First, the triage skill is judgment you wrote down, so it inherits your blind spots, and it will rank confidently either way. Review the ranking against what mattered in hindsight after the event and change the standard.

Second, the approval gate. Actions in Qore start gated on a person's sign-off, and how much stays that way is a setting you tune. The tuning belongs before the window rather than during it, and it is worth doing: the overnight shift is one on-call person covering thirty accounts, so a routine move you have watched a skill make correctly for a month, inside a ceiling you approved, is better applied automatically at 4am than left in a queue until someone wakes up. Tighten the rules until the clear-cut cases need no supervision, keep sign-off on anything consequential, and then freeze both settings when you freeze the read. Qore reads the account, analyzes it, and makes the approved change no matter what runs the bids, so it works alongside whatever bid manager of record you already have, or with no automation platform at all. If a third-party tool later overwrites a change you approved in Qore, that is a constraint of that tool's own execution model, and it is worth knowing which of your tools behaves that way before the window opens.

On the changes themselves, in-event bidding and budget mechanics are their own subject and we cover them separately in the Prime Day playbook. The command center's job is to point.

How a three-person team covers thirty accounts for 96 hours

The dashboard and the triage list are only useful inside a rhythm. This is the shape that has worked for teams running a full roster through a peak window.

Two rules make the rotation work. The person on shift reads the triage list top down and does not skip to the account they like. And every touch gets logged into the "last human touch" field, because the next shift's most valuable input is what the previous shift already handled.

What to build before the freeze, and what to leave alone during it

Build before: the roster itself, the per-account plan numbers, the definition of off-plan for each client, the refresh schedule, the approval settings on any action, and one full dry run against live data. Anything that requires a decision about what "good" means for a client belongs here.

Leave alone during: the read itself. Changing the standard mid-event destroys the one property that makes the dashboard useful, which is that two reads an hour apart are comparable. Write the change down, apply it after the window. The same discipline applies to the account audit routine you run the rest of the year, which we lay out in the PPC account audit workflow, and to your everyday pacing standard in the budget pacing SOP.

One scope note. This is a single-marketplace, many-Amazon-accounts view. Reconciling numbers across Amazon, Walmart, and your other channels is a different problem with different data definitions, and we handle it separately in unified cross-channel reporting. Do not try to make the peak-event command center do both jobs at once.

Build the command center before the date is announced

The next peak window is the fall event. Amazon ran Prime Big Deal Days as a 48 hour window on October 7 and 8 in 2025, and the 2026 dates were not published when this was written, which is exactly the argument for building now. A roster, a set of per-account plan numbers, and a dashboard that rebuilds itself are all things you can have in place before Amazon tells you the date. Our Amazon peak season calendar tracks the dates as they land, and if you manage accounts for a living, the agency side of the platform is where the roster lives.

A command center does not make decisions for you. What it changes is where the hour goes when a strategist has one hour and thirty accounts. That is a small change in how attention is allocated, and across a 96 hour window it is most of the difference between a peak event you managed and one that managed you.

The bottom line for agency teams

• Build the roster and the plan numbers first. A dashboard with no per-account definition of off-plan is thirty rows of numbers.
• Use the column spec above and resist a seventh field. Every extra column costs a fraction of a second per account, times thirty accounts, times every refresh.
• Decide the source and refresh rate per column, in advance. Making those calls late is how a dashboard ends up with three columns nobody trusts.
• Include last human touch. "Nobody has opened this account in nine hours" is often more actionable than any performance number on the row, and it is the one column a person has to write.
• Judge each account against its own target. A 45 percent ACoS account and a 12 percent ACoS account both look wrong on a shared threshold.
• Specify the reason line. Account, what is off, by how much and when, the context, and the first thing to check. A red cell tells a strategist nothing.
• Dry run at T minus 7 days, then freeze the read. Changing the standard mid-event destroys the comparability that makes it worth having.
• Set your approval gates before the window too. Overnight is one on-call person covering thirty accounts, so decide in advance what runs unattended.

If you would rather see a roster dashboard and a chained triage skill running against real accounts first, book a walkthrough.