bm-portal — admin & client dashboards

One request object, two views. The client's "My requests" and your all-client board are the same rows filtered differently — not two features. That is what keeps the client's status honest: they see the real column their work sits in, so "where is this?" stops being an email.

"Waiting on you" is the column that earns its keep. Most agency delay is actually the client owing an asset or an approval. Naming that as a status — visible to them, with the upload button right there — moves the blame conversation into the product. It is the single most valuable column on the board.

The calendar shows dates, not availability. Due dates, report sends, invoice dates — derived from existing work. Making it a booking calendar means scheduling logic, conflicts and time zones, which is a different product. If you want clients booking calls, link Calendly.

Status and security are read-only panels here. Uptime comes from UptimeRobot, attacks from Compliee. bm-portal aggregates and never owns that data — the same boundary the monitoring doc argues for. "Attacks blocked: 312" on the client dashboard is the same number as the weekly digest.

The existing schema has campaigns, deliverables, invoices, dates, kpis, activity and profiles. The gap is the whole point of this mockup: there is no requests/tasks table. Everything on the kanban needs one, plus comments and attachments. Roughly: one migration, a request form, a board that both roles read, a client detail page for you, and the three read-only status panels.

Not in this mockup, deliberately: time tracking (that is Dashee's ruling, and the billable-hours build), drag-and-drop reordering (a nice-to-have that doubles board complexity), and client-to-client visibility of any kind. Say if any of those should be in v1.