Mission Control: the command center for VMS program managers

It’s 7:42 AM on a Monday. The program manager at a multi-hospital system opens her laptop and starts the same routine she’s been doing for two years. One tab to the VMS portal to see what shifts are still open. A second tab to a shared spreadsheet listing agency assignments by unit, last updated Friday by someone in another time zone. A third tab to Slack, where the night float charge nurse left a message about a no-show on a med-surg floor. A fourth tab to her inbox, where a supplier has emailed about a candidate who’s been waiting on credentialing for nine days. Stand-up is at 8:00. She needs to know which units are short, which suppliers are pulling weight, and which candidates are stuck. She has eighteen minutes.

The information she needs is spread across four tools. The VMS shows individual shifts, the spreadsheet tracks assignments, and messages explain what changed. She has to put the program’s current state together herself.

We built Mission Control to bring that work into one place.

The job to be done

A VMS program manager is responsible for one or many hospital systems’ contingent workforce programs. The daily job:

• Know which open shifts across every unit are at risk of going unfilled, and which suppliers are most likely to fill them.
• Know which active assignments need attention: extensions, replacements, performance issues, credentialing expirations.
• Watch supplier behavior. Who’s submitting on time? Who’s ghosting? Who is winning the most starts and on which units?
• Move candidates through the offer-to-start flow, unsticking the ones who stall.
• Communicate with the MSP, the suppliers, the facility partners, and the central program ops team.
• Report on program health: fill rate, time-to-fill, supplier mix, cancellation rate, dispute volume.

A program manager’s priorities change throughout the day: tonight’s coverage at 7:30, a supplier review at 10, and stalled offers at 2. The program stays the same, but the manager needs different views of it.

Organizing the product around the program lets a manager move between those views without reconstructing the context.

The product shift: organize around the program

The first design decision was the unit of organization. The early sketches looked like everyone else’s sketches: a left rail of features, a main panel of a chart, a right rail of notifications. We showed those to a half-dozen program managers and got back a polite version of this is the same product I already have, with nicer typography.

So we rebuilt around a single noun: the program. A program is the contingent workforce program for one hospital system, one MSP relationship, or an explicitly scoped subset of either. Mission Control opens to that program’s current state. Coverage, suppliers, candidates, tasks, and metrics all show through the program lens by default. A program manager who runs three programs switches between them at the top of the surface. A program manager who runs one never thinks about it.

What this changed, concretely:

• Filters became sub-views, not configurations. When “ICU at Facility B for the next 72 hours” is a frequent question, it shouldn’t be a filter the user reconstructs every time. It’s a sub-view of the program, savable, shareable, and persistent.
• Notifications became tasks. A supplier ghosting on a submission isn’t a notification to dismiss. It’s a task on the program, owned by someone, with a state.
• Metrics moved out of a separate “analytics” module. Fill rate, time-to-fill, and supplier mix sit inside the program view, next to the shifts and suppliers they describe.

This was a change from organizing the product around individual shifts, assignments, candidates, and reports. We needed to show how those transactions fit together within a program.

What we kept, what we dropped

We settled on four panels for the program view, with clear limits on what each would cover.

Kept	Dropped
Shift bookings. Live open/filled/at-risk shifts grouped by unit and shift type, default 14-day window, drill into a shift to see supplier notify and submit state.	A configurable widget grid. Configurability is where products go to become unusable.
Assignment status. Assignments needing program-manager attention first: ending in the next 21 days, flagged for performance or credentialing, or with open disputes. 21 days is the practical extension window.	A real-time activity stream. Three operators told us it added noise without changing what they did.
Metrics. Five metrics---fill rate, time-to-fill, cancellation rate, supplier mix, dispute volume---each with a trend line and a comparable benchmark.	The long tail of derived metrics from earlier dashboard designs. Most weren’t being looked at; the ones that were could be reconstructed from the five.
Tasks. A queue of program-scoped tasks (stalled offers, missed submission SLAs, aging credentialing items, disputes awaiting MSP review) with owners, states, and audit.	Per-shift commentary fields. Slack already exists, and a worse Slack inside a product is not a feature.

We chose a small set of tasks we understood well over a dashboard that users would have to configure for themselves.

The dashboard ops staff needed (that customers will never see)

Mission Control is the customer-facing surface. What makes it trustworthy in production is a second surface customers never see: the Active Admin integration-status dashboard, which our internal operations staff use to know whether every integration the product depends on is currently healthy.

Hospital contingent workforce runs on a stack of integrations: scheduling systems, time-and-attendance systems, credentialing systems, the VMS’s upstream and downstream connectors. Each integration is a contract with another team’s API, and contracts drift. A scheduling system upgrades a version. A credentialing system rotates a credential. A time-and-attendance system silently caps API rates on Mondays. When any one of these breaks, the consequences flow downstream into the customer surface in ways easy to misread as a Mission Control bug.

We shipped the Active Admin “Active Integrations” panel this month for one reason: the people doing customer support and onboarding need a live view of integration health that doesn’t require pinging an engineer. Before this panel existed, the question is the UKG sync running cleanly for this customer right now? required a Slack ping, a log query, and a developer. After the panel, it’s a glance.

The panel shows every active integration across the customer base, grouped by integration type. Integrating with UKG is one connector among many the dashboard watches, alongside other scheduling and credentialing systems in the hospital stack. Each tile shows integration type, customer, current health (green/amber/red), last successful sync timestamp, and a one-line reason on amber and red. Clicking through opens the recent sync history and the underlying error, if there is one.

We kept the operations view separate because the teams need different information. A customer needs to understand their program; our operations staff need to see integration health across customers. Active Admin gives them that broader view.

In-product communication, instead of email

The other piece we shipped this month is system message banners. Admins can push a message to all (or a subset of) Works web users, and it appears in the product the next time they load the surface. The use cases are concrete: planned maintenance windows, a policy change for a specific MSP relationship, a heads-up about a temporary integration issue, a reminder before a fee schedule changes.

Program managers already receive hundreds of emails a day. A message in the product can reach them while they’re working on the affected program. We scope banners to a customer, role, or program so people see messages relevant to their work.

Banners can be dismissed, have an audit trail, and expire. They’re intended for product notices such as maintenance and integration issues.