Cutting an EU hotel group's agency staffing spend by 70%

Twistag built an AI staff-allocation platform for a European hospitality group that cut agency-temp spend by 70% against a €1 million-plus annual outsourcing problem, live in four months across 2,000-plus employees. The group ran multiple properties whose managers each scheduled staff on local data alone, so one hotel hired agency temps while another sat on idle capacity a few kilometres away. Twistag built a unified data layer that normalises occupancy and staffing data across different property-management systems, and a Google OR-Tools optimisation engine on top of it that recommends specific cross-property staff rotations with the projected saving attached to each one.

Each property scheduled its workforce independently, using its own bookings, headcount and demand forecast. A property at 45% occupancy could have housekeeping staff with three free shifts while a second property across the city ran at 95% and filled the same shifts through a staffing agency at premium last-minute rates. Neither manager could see the other. The group was spending more than €1 million a year on agency staffing for shortfalls that internal capacity could have covered. The client is a European hospitality group with over 2,000 employees and is not named publicly.

Twistag delivered the platform in four months, sequencing visibility before optimisation. First, a unified data layer that ingests booking, occupancy and staffing data from every property and normalises it into one canonical state — necessary because hotel groups typically run different PMS platforms across properties after acquisitions and brand changes. Second, an optimisation engine built on Google OR-Tools that calculates optimal staff rotations across properties subject to shift structures, role qualifications, geographic feasibility and employee preferences, and produces specific recommendations with the projected saving for each. Third, serverless infrastructure on AWS — App Runner for application services, Lambda for optimisation jobs that fire when occupancy data updates. The data layer was the harder half of the build, because the same fact arrives from each property in a different shape and has to be reconciled before anything downstream can run. Sequencing visibility before optimisation is what a strategy engagement delivered by the people who then build the thing looks like in practice: the analysis and the architecture were the same decision.

The optimiser is not what a general manager touches. What she touches is a recommendation: move these two housekeepers from the property at 45% occupancy to the one at 95% on Thursday, and here is what it saves. Named people, a named shift, a number attached, and a decision she can accept or reject. A constraint solver can equally well emit a schedule and impose it; the version that gets used tells a manager what to do next and lets her stay accountable for her own property.

Stack: Google OR-Tools, AWS Lambda, AWS App Runner. Services: AI-ready data platforms, AI agents and optimisation, product engineering.

A 70% reduction in agency-temp spend. The €1 million-plus annual outsourcing line became a small fraction of itself, with internal capacity covering most of what had been a permanent shortfall. Delivered in four months from kickoff to live, across 2,000-plus employees. The data layer proved to be the durable asset. Because occupancy and staffing data now arrives in one canonical state, further optimisation work does not start from scratch, and the recommendation reaches a general manager without anyone starting a job — optimisation jobs fire when occupancy data updates.

The optimisation layer is valuable. The data layer is what makes it possible.