My MSc dissertation at St Mary's University examined the impact of digital systems on operational efficiency in residential property management — specifically, whether introducing digital booking, management, and analytics tooling produced measurable improvements in occupancy and revenue outcomes, and whether that relationship held across different market contexts.
The methodology was a systematic literature review combined with a machine learning classification framework: I collected 47 international case studies, extracted structured feature data from each, and applied a Random Forest model to identify which factors were most predictive of positive operational outcomes. This is a reflection on what that actually involved — not the clean version you write in a methods section.
Where the data came from and why it was messy
The 47 case studies came from a range of sources: academic journals, industry reports, conference proceedings, and a small number of primary sources gathered through the Chrispo engagement (which gave me direct access to real booking and revenue data from a Ghanaian property). The academic and industry sources varied enormously in how they reported outcomes — some gave precise occupancy percentages before and after digitisation, others gave qualitative descriptions that I had to convert into numerical features using a defined coding scheme.
That coding process was where most of the difficulty lived. When a case study says a property saw "significant improvement in booking efficiency," that means different things to different authors. I had to make explicit decisions about how to interpret ambiguous language, document those decisions, and apply them consistently across all 47 cases. This is the part of systematic literature reviews that papers tend to underreport — the human judgment calls that go into turning qualitative text into a structured dataset.
The conflicting methodologies problem
Several papers I included used different baseline periods and different definitions of "operational efficiency." One paper measured efficiency as average time-to-booking confirmation. Another measured it as staff hours per reservation. A third used occupancy rate as the sole proxy. These are all legitimate measures, but they're not the same thing, and a model that treats them as equivalent features is going to learn something confused.
I handled this by categorising features at a higher level of abstraction — rather than using the raw metric each paper reported, I coded each case study for whether it showed improvement across a defined set of operational dimensions (booking volume, revenue per available unit, staff workload, guest satisfaction). This introduced its own subjectivity, but it made the feature set more coherent across cases that had used very different measurement approaches.
The hardest part of applied ML research isn't the model. It's deciding what your features actually mean when the data comes from 47 different sources with 47 different assumptions.
The cross-validation framework
With a dataset of 47 cases, standard train/test splits weren't appropriate — any random split would leave too few samples in either partition to draw reliable conclusions. I used k-fold cross-validation (k=5), which let me evaluate model performance across all the data while still maintaining separation between training and evaluation folds.
The Random Forest model performed well on the classification task — predicting whether a given combination of digitisation factors was associated with measurable operational improvement — but I was careful not to overinterpret this. With 47 cases and a relatively small feature set, you can get high cross-validated accuracy that still reflects the specific characteristics of your data sample rather than a general truth about the world. I spent significant time in the write-up being honest about the limitations of the sample size and the generalisability of the findings.
What the results actually showed
The most consistent finding was that the integration of systems mattered more than the presence of any individual system. Properties that had implemented booking, payment, and reporting tools that communicated with each other showed stronger outcomes than those that had added digital tools in silos. This wasn't surprising in theory, but seeing it hold across different markets — Ghana, the UK, Southeast Asia — gave it more weight.
Feature importance analysis (one of Random Forest's useful properties) consistently ranked integration depth and staff adoption rate as the top predictors of positive outcomes. The type of technology used — whether a property used a bespoke system or an off-the-shelf platform — ranked lower than I expected.
What I took from it
The dissertation reinforced something I already suspected about applied ML: the work that determines whether your results are trustworthy happens before you fit the model. The feature engineering, the coding scheme, the decisions about how to handle ambiguous data — these are where the real intellectual effort goes, and they're largely invisible in the final paper.
It also gave me a much clearer sense of what "uncertainty" means in a research context. Not knowing whether your results are right is uncomfortable. Knowing exactly what you don't know, and being precise about it in your writing, is the thing that makes research honest. That's the standard I tried to hold myself to, and it's the standard I try to apply when I'm building systems now.