Wizz

The challenge

Operators running many properties live inside several systems at once: a channel manager, a booking platform, a maintenance tool. The hub had to sit above those, summarise what matters, and make the integrations visible rather than hiding them in settings.

What I did

I led with a four-figure summary - properties, services, reservations, new properties - each carrying its movement. Reservations analytics sit beside a completion and damage report, and integrations are given a dedicated panel on the main dashboard rather than being filed under configuration, because for this user a broken integration is an operational emergency rather than a settings detail.

The outcome

A dashboard that surfaces integration health alongside operational figures, with a notification stream that keeps multi-property operators ahead of issues instead of discovering them from guests.

Integrations belong on the dashboard

Most products treat connected services as configuration: set once, forget, find it under a gear icon. For an operator whose bookings arrive through those connections, a silent failure is lost revenue.

Putting connected services on the main screen with visible status turns a buried setting into a monitored system. It is a small placement decision with a disproportionate operational effect.

Two charts, two questions

The reservations curve answers how business is trending. The completion and damage donut answers whether operations are holding up. Those are genuinely different questions and merging them into one visualisation would answer neither.

Keeping them adjacent but distinct lets an operator check demand and quality in the same glance without the chart having to compromise.

Notifications as a working queue

A notification panel that only announces events is noise. One that lists items with enough context to act is a queue.

Each entry carries its subject and timing so the operator can triage from the dashboard rather than opening every item to find out whether it matters.