Focal Revenue
How MEV Integrated Multiple Hotel PMS Systems into One Analytics Platform
Client:
Focal Revenue
Focus:
Hotel PMS integrations / Legacy export and cloud API ingestion / PMS data normalization
Technologies:
Python / AWS Lambda / Amazon S3 / AWS SES / Amazon EventBridge / AWS Step Functions / Amazon Athena / AWS Glue Data Catalog / Apache Parquet / PostgreSQL
[ about the client/ ]
Focal Revenue developed myRevenue, a business intelligence platform used by hotel management companies to understand performance across individual properties and larger portfolios.
The platform depended on data from hotel property management systems, but those systems exposed data through different interfaces, delivery methods, and file formats.
What Needed to Be Done
Hotels did not all use the same property management system. Focal Revenue needed to connect its analytics platform to both legacy and cloud PMS products, including Opera v5, Opera Cloud, Stayntouch, and SMS|Host.
The sources delivered data through REST APIs, SFTP, emailed reports, and uploaded files. Depending on the PMS, the platform had to handle XML, CSV, JSON, TXT, XLSX, and zipped DBF exports.
MEV needed to add new integrations, stabilize existing ones, and ensure that each source ultimately produced data the same analytics platform could process.
The sources delivered data through REST APIs, SFTP, emailed reports, and uploaded files. Depending on the PMS, the platform had to handle XML, CSV, JSON, TXT, XLSX, and zipped DBF exports.
MEV needed to add new integrations, stabilize existing ones, and ensure that each source ultimately produced data the same analytics platform could process.
Why It Mattered
Each PMS represented hotel reservations, allotments, property identifiers, and reporting periods differently. Some systems offered modern APIs, while others depended on scheduled exports or multiple files that arrived at different times.
Without a common integration and normalization layer, downstream analytics could not treat the data consistently. Every new PMS or hotel group would require additional source-specific handling throughout the product, making property onboarding and portfolio-level reporting harder to maintain.
Without a common integration and normalization layer, downstream analytics could not treat the data consistently. Every new PMS or hotel group would require additional source-specific handling throughout the product, making property onboarding and portfolio-level reporting harder to maintain.
What MEV Built
MEV built and stabilized integrations for legacy and cloud hotel systems, including Opera v5 exports, Opera Cloud/OHIP, Stayntouch APIs, and SMS|Host feeds.
The integration layer accepted data through APIs, SFTP, email, and S3. AWS Lambda functions identified the property, file format, and integration type. Files were converted to Parquet or CSV where required, while older integrations could continue using CSV or JSON.
Amazon EventBridge and AWS Step Functions routed each source through the appropriate workflow. Amazon Athena and the AWS Glue Data Catalog queried the processed files, and Python functions applied both common rules and PMS-specific transformation logic.
The normalized output was written into the analytics database in a format shared by the rest of the product.
The integration layer accepted data through APIs, SFTP, email, and S3. AWS Lambda functions identified the property, file format, and integration type. Files were converted to Parquet or CSV where required, while older integrations could continue using CSV or JSON.
Amazon EventBridge and AWS Step Functions routed each source through the appropriate workflow. Amazon Athena and the AWS Glue Data Catalog queried the processed files, and Python functions applied both common rules and PMS-specific transformation logic.
The normalized output was written into the analytics database in a format shared by the rest of the product.
Technical Flow
01:
Receive PMS data
Hotel data arrived through REST APIs, SFTP accounts, email reports processed through AWS SES, and files uploaded to Amazon S3.
02:
Identify the property and integration
An S3 event triggered AWS Lambda. The function mapped the source property to the corresponding myRevenue hotel ID and detected the PMS and file format.
03:
Convert the source files
The integration handled formats such as Oracle XML extracts, CSV files, and zipped DBF exports. Newer integrations used Parquet as the preferred processing format, while some existing data streams continued to use CSV or JSON.
04:
Select the PMS-specific workflow
Amazon EventBridge triggered the scheduled processing flow. The system selected the AWS Step Functions workflow configured for the relevant property and integration.
05:
Query and normalize the data
Amazon Athena and the AWS Glue Data Catalog queried processed files in S3. Python functions then applied common transformation rules together with logic required for the specific PMS.
06:
Store data in a common analytics format
Normalized records were written to the SQL analytics database and used to generate reporting snapshots. From that point, the same analytics application could work with data from different hotel systems.
Outcome
Focal Revenue gained a repeatable integration approach for bringing legacy exports, modern APIs, and source-specific hotel data into one analytics platform.
The work enabled the company to:
- add new PMS integrations without creating a separate analytics product for each source
- stabilize and extend existing integrations
- support both independent and branded hotel data feeds
- convert inconsistent source data into a common analytics model
- use the normalized data for property and portfolio reporting
This integration layer supported the platform as it expanded from an early deployment of 50 hotels to about 400 hotels across 15 hotel management groups. The client reported that the integrations continued to meet customer demands as the platform grew.
This case is part of the full case study
MEV Built Focal Revenue’s Hotel Revenue Intelligence Platform[ portfolio/ ]
