The operator panel: from one person to a team

The problem#

Operational tooling grows faster than the need, because each piece looks obvious. Filters, queues, assignment, permissions, dashboards. For one person who already knows what to do, most of it is cost without return.

The right question is not "what does an admin panel need" but "how many people make decisions, and do they have to account to each other".

Three stages#

Minimum version#

• A seller screen with their products, orders, payouts and decision history.
• An order screen with items, payment, returns and shipping.
• A list of things needing attention, even as a plain listing.
• Search by order number, email and seller name.

What not to build yet#

• Configurable per-resource permissions.
• A dashboard with charts, before somebody asks a question a chart answers.
• Internal notifications and a task system.
• Spreadsheet exports for every view.

Plan ahead#

Context rather than aggregate#

Operator work is answering questions about a specific object: this seller, this order, this return. A screen that gathers that in one place is worth more than ten filtered lists.

Seller data isolation as a rule, not a view#

A seller must see only their own data, and that has to come from the data access layer rather than from what the interface shows. A filter in a view is easy to bypass with the first new screen.

An author field wherever a decision is made#

Same point as in the moderation chapter, and it returns here because it applies to every operator action: an order state change, a manual payout, a stock correction.

Triggers#

• a second person gets access to the panel;
• somebody asks who changed a record;
• a repetitive task takes more than a quarter of an hour a day;
• somebody appears who should see only part of the data;
• the same seller question comes back every week.

Next stage#

After the first and second triggers together: a decision author and internal notes. After the third: a bulk action for that one task, not for all of them. After the fourth: roles, the simplest possible. After the fifth: exposing the answer to sellers, so the question stops returning.

Common mistakes#

What works in practice#

In the panel, contextual screens turned out to be far more useful than lists. Answering a seller question almost always requires their orders, payouts and decisions in one place, rather than searching separate views.

Seller data isolation is the one thing in this area that cannot be added painlessly later. Every screen written before the rule became the default has to be reviewed separately afterwards.

Checklist#

• Contextual screens exist for the seller and the order.
• Seller data isolation comes from the access layer, not the view.
• Every operator decision has room for an author.
• There are no queues or roles until there is a second person.
• Search covers order number, email and seller.