Page two

The app, as I read it from outside.

There's no sign-up, so I can't log in and look. What I can do is read your features page and your job posting carefully, and draw the staff screen I think the studio actually needs. Treat this as a candidate showing their reasoning, not as a redesign of your product.

Sketch · staff view · not a real screen

One morning at a studio

Everything below comes from your own feature list: firings, pickups, memberships, supplies, classes, reservations, private events, waitlists, agreements, POS. I only decided what a manager should see first.

Amber marks only the things a person has to decide. Nothing else on the screen is allowed to use it. That's the whole rule.

I'm a minimalist off the screen too — I travel light and I own little — and it shows up in work like this. Fewer parts, more room, nothing on the page that isn't earning its place. A studio manager at 9am doesn't need decoration; they need to see what's wrong in one look.

Why it's arranged this way

Four decisions

Exceptions first, totals second
A studio manager opening this at 9am has one question: what's broken. Four failed cards matter more than $14,890 that will collect itself on Friday. So the count of things needing a person sits in the top bar, and the only coloured number is the one you can act on.
Kilns and shelves are the physical layer
Your own copy says staff answer "when will the kiln be done?" over and over, and that pieces pile up on shelves. Those are the two places software touches a physical constraint, so they sit above billing even though billing is the product's revenue engine.
Shelves are shown by age, not by member
By member it's a list of 154 names. By age it's four rows, and the bottom two are the only ones that need a decision. Same data, one screen instead of a scroll.
Every row ends in a next step
Not a status — a step. "2 on last retry, nudge" tells a new staff member what to do; "failed" does not. This is the difference between a dashboard people check and one they close.

What I'm guessing at

I don't know your data model, your kiln integration, or whether firing fees are computed from member-submitted measurements at submission or at unload. I don't know how much of the above already exists — most of it probably does. If I'm wrong about the shape of the problem, that's a useful thing for both of us to find out in the first conversation rather than the third month.