Corporate Booking Portal
A corporate client relocating a 24-person team to London runs the whole programme on email, phone, and a shared spreadsheet. No single surface holds the programme, so the buyer cannot answer the only question that matters, are we under budget and is everyone OK, without emailing an account manager who spends an estimated six to ten hours per programme on coordination.
I designed the surface the buyer logs into: a self-serve programme dashboard for HR and mobility teams. The structural move is that Programme is the first-class object, not Booking. My first version got that backwards, and fixing it is the spine of this case study. Concept project, 2026. Every number below is a labelled target, not a shipped result.
Programme, not booking
Version one followed the kit's e-commerce grain and made Booking the first-class object. A 24-person cohort became 24 table rows, support tickets floated free of any parent, and the total spend figure the buyer cares about had to be added up by hand. The reframe demotes Booking to a child of Programme, so spend, status, tickets, and people all roll up to one object, the Acme Q3 London onboarding: 24 employees, 24 stays, one budget envelope.
An overview that answers the buyer's question
Out went orders, conversions, and generic revenue tiles. In came spend against budget, stays in progress, employees hosted, and programmes at risk. I also cut a feature I loved, a live spend-forecast chart, because the data to drive it honestly does not exist at booking time. A confident-looking line built on guesses would poison the one thing this surface must earn, the buyer's trust in the figures. Actuals only, with committed-but-unbilled spend shown as its own clearly labelled band.
Support tickets with the booking attached
A ticket about a broken heater shows the employee, the booking reference TSQ-25475, the property, the programme, the account manager, the SLA clock, and the latest reply, the seven things a buyer needs to triage without leaving the row. In the prototype, approving an employee's extension request takes about 90 seconds. In the email threads I reviewed, a comparable approval ran to roughly four messages over 36 hours.
Shipping inside a fixed kit
I constrained the build to a single UI8 admin kit and added no new components, because that is how a resource-tight team would actually ship it. The design contribution sits in the taxonomy, generic modules renamed to the corporate-stays domain, in a booking status vocabulary (Inquiry, Held, Confirmed, Checked-in, Checked-out, Cancelled), and in the object model, where every view can deep-link to any related object. Locked once, applied across all 25 screens.
Honest targets, not shipped numbers
Targets with a measurement plan: a fully confirmed 24-stay cohort in under five working days instead of about three weeks, account-manager hours per programme under two instead of six to ten, and ticket resolution under eight hours instead of about 36. Before any build, a five-user test with HR and mobility managers checks the assumption this design is most exposed on: that spend approval routes through HR before Finance. If that is wrong, the permission model changes, which is exactly why it gets tested first. This portal is the buyer's half of a two-surface story; the guest's app is the previous case study, sharing booking TSQ-25475.