From Messy Hotel Bookings to Business Intelligence: Building the Tembo Hotel & Suites Dashboard

A practical journey from raw data and SQL cleaning to DAX, Power BI storytelling, and actionable hotel insights.

There is something satisfying about taking a dataset that initially looks like a collection of rows and columns and turning it into something that can actually answer business questions.

That was the idea behind my Tembo Hotel & Suites Business Intelligence Dashboard.

This project started with hotel booking data containing information about guests, rooms, bookings, payments, services, ratings, dates, and revenue.

But the goal was never simply to create a dashboard that looked good.

The goal was to answer questions such as:

• How much revenue is the hotel generating?
• Which room types contribute the most revenue?
• Which room types receive the most bookings?
• How long do guests typically stay?
• How are guests paying?
• How many bookings are cancelled or marked as no-shows?
• Which services are actually being used?
• Where are Tembo's guests coming from?
• How are guests rating their experience?
• What can management learn from the data?

And most importantly:

Can I turn raw hotel booking data into a business story?

This project became my answer.

The Project

Project: Tembo Hotel & Suites — Hospitality Business Intelligence Dashboard

Tools used:

• PostgreSQL
• DBeaver
• SQL
• Power BI
• DAX
• Data Visualization

The project followed this workflow:

Raw Hotel Data
      ↓
Data Cleaning & Quality Checks
      ↓
PostgreSQL / SQL
      ↓
Clean Analytical Table
      ↓
Power BI
      ↓
DAX Measures
      ↓
KPIs & Visualizations
      ↓
Dashboard Storytelling
      ↓
Business Insights

The final Power BI report contains three analytical pages:

1. Executive Overview
2. Guest & Experience Intelligence
3. Operations & Revenue Intelligence

Each page has a different purpose.

That distinction was important.

I didn't want three pages containing the same charts in different positions.

I wanted the dashboard to tell a story.

1. Starting With the Data

The original dataset was a hotel booking dataset containing 286 rows and 20 columns.

However, after checking the booking identifiers, I found that there were 285 unique bookings.

That immediately raised the first question:

What happened to the extra row?

This is one of the reasons I prefer beginning analytical projects with data quality checks instead of immediately opening Power BI.

A dashboard can look beautiful while being completely wrong.

If the underlying data is wrong, the visualization simply makes the wrong answer easier to look at.

So before building anything, I worked on the data foundation.

2. Cleaning the Data With SQL

The raw data was loaded into PostgreSQL and worked on using DBeaver.

I used a staging approach:

tembo_hotel_raw
        ↓
cleaning & transformation
        ↓
tembo_hotel_clean
        ↓
quality checks
        ↓
Power BI

The raw table was kept separate from the cleaned analytical table.

This made it possible to distinguish between:

• the original source
• the transformed dataset
• the final dataset used for reporting

That separation may seem small, but it makes an analytical workflow much easier to understand and reproduce.

What I Checked

The cleaning process included checks for:

• Duplicate booking IDs
• Missing values
• Invalid dates
• Inconsistent text formatting
• Room-type inconsistencies
• Booking-status inconsistencies
• Payment-method inconsistencies
• Invalid nights stayed
• Guest-rating issues
• Missing service information
• Revenue consistency
• Phone-number formatting

I also standardized categorical values so that the same category would not appear as multiple categories simply because of differences in spelling, spacing, or capitalization.

For example, analytical categories need to behave consistently.

"Deluxe"
" deluxe "
"DELUXE"

should not accidentally become three different room categories.

3. Missing Data Is Not Automatically Bad Data

One of the lessons I wanted this project to reinforce was that:

Missing data and bad data are not the same thing.

After cleaning, some fields still contained NULL values.

For example, service-related fields were naturally sparse because not every booking used an additional hotel service.

The cleaned dataset contained:

• 285 bookings
• 274 non-null total_amount values
• 11 missing total_amount values
• 97 service bookings
• 188 records without service information
• Guest-rating information with some missing values

Instead of blindly replacing every NULL with zero, I treated missingness according to the meaning of the field.

This is an important distinction in real-world analytics.

A missing service value may simply mean:

No service was recorded for that booking.

That is very different from saying:

The service generated KSh 0 because the source explicitly recorded zero.

Data cleaning is therefore not just about making NULLs disappear.

It is about understanding what the NULL means.

4. Quality Control Before Power BI

After cleaning, I performed quality checks before moving the data into Power BI.

The purpose was simple:

Make sure the dashboard would be built on a dataset I could trust.

This included checking:

• Row counts
• Unique booking counts
• NULL patterns
• Numeric ranges
• Date validity
• Category consistency
• Revenue values
• Rating ranges
• Booking statuses

The final analytical table was:

hotel_data.tembo_hotel_clean

with:

285 unique bookings

Only after the data passed these checks did I move into Power BI.

5. Building the DAX Layer

Once the cleaned data was loaded into Power BI, the next stage was turning raw columns into meaningful business metrics.

This is where DAX became particularly useful.

Instead of relying on automatically generated aggregations for everything, I created measures representing the questions I actually wanted the dashboard to answer.

Some of the measures included:

• Total Bookings
• Total Revenue
• Average Booking Value
• Average Guest Rating
• Average Stay
• Cancellation Rate
• Completed Revenue
• Cancelled Bookings
• No Show Bookings
• Service Revenue
• Service Bookings
• Service Attach Rate

For example, a basic total bookings measure can be represented as:

Total Bookings =
DISTINCTCOUNT('tembo_hotel_clean'[booking_id])

And an average booking value can be calculated conceptually as:

Average Booking Value =
DIVIDE(
    [Total Revenue],
    [Total Bookings]
)

The important lesson here is that a measure is more than a number.

It represents a business question.

6. The Numbers Behind the Dashboard

The completed dashboard currently surfaces several headline metrics.

Overall performance

Total Bookings: 285

Total Revenue: KSh 8.47M

Average Booking Value: KSh 29.71K

Average Stay: 3.00 nights

Average Guest Rating: 3.02 / 5

Cancellation Rate: 8%

On the guest intelligence page, the dashboard also identifies:

Service Bookings: 97

Service Attach Rate: 34%

Completed Revenue: KSh 7.29M

Top Guest Nationality: Kenyan

Top Guest City: Nairobi

These numbers become much more useful once they are connected to visual analysis.

7. Page One — Executive Overview

The first page was designed as the dashboard's executive overview.

The idea was to answer:

"If someone only had a few minutes to understand Tembo Hotel's performance, what would they need to see?"

The page contains:

• Six KPI cards
• Check-in date filter
• Room type filter
• Booking status filter
• Payment method filter
• Revenue trend
• Revenue by room type
• Booking status
• Payment method
• Service performance

The KPI Strip

The six headline KPIs provide an immediate summary:

Total Bookings
Total Revenue
Average Booking Value
Average Stay
Guest Rating
Cancellation Rate

Rather than filling the dashboard with decorative numbers, each KPI was chosen because it answers a specific business question.

For example:

Total Revenue

How much revenue was recorded?

Average Booking Value

What is the average monetary value associated with a booking?

Average Stay

How long do guests typically stay?

Cancellation Rate

What proportion of bookings were cancelled?

This made the KPI section a starting point for analysis rather than just decoration.

8. Why the Revenue Trend Matters

One of the main visuals on the overview page is the Revenue Trend.

It uses:

• check_in_date
• Total Revenue

The purpose is not simply to create a line.

It allows us to observe how recorded revenue changes over time.

A trend visual can reveal:

• periods of stronger revenue
• periods of weaker revenue
• spikes
• slow periods
• changes in revenue concentration

This is where a dashboard starts becoming more analytical.

Instead of asking:

"How much revenue?"

we can also ask:

"When is the revenue being generated?"

9. Revenue by Room Type

The Revenue by Room Type visual looks at how revenue is distributed across different room categories.

This answers:

Which room categories contribute most to hotel revenue?

This is different from simply counting bookings.

A room type may have fewer bookings but generate significantly more revenue per booking.

That distinction matters.

For example:

Booking Volume ≠ Revenue Contribution

This is one of the reasons I included both revenue analysis and booking-volume analysis in the report.

10. Booking Status

The booking-status analysis separates:

• Checked Out
• Cancelled
• No Show

This provides another layer of operational context.

A hotel does not simply have "bookings."

Bookings can have different outcomes.

Understanding those outcomes helps management investigate:

• completed business
• cancelled demand
• missed bookings
• potential revenue leakage

11. Page Two — Guest & Experience Intelligence

The second page changes the perspective.

Instead of asking:

"How much money did the hotel make?"

we ask:

"Who are the guests, what do they use, and how do they experience the hotel?"

The page includes:

• Average Guest Rating
• Average Stay
• Service Attach Rate
• Service Bookings
• Completed Revenue
• Top Guest Nationality
• Top Guest City

Alongside these KPIs, I included visuals for:

• Guest Nationality
• Guest City
• Guest Rating Distribution
• Rating by Room Type
• Service Popularity
• Service Revenue

12. Understanding the Guest

The dashboard shows Kenyan as the top guest nationality and Nairobi as the top guest city in the current dataset.

This provides a starting point for understanding the hotel's guest profile.

But I intentionally avoided turning these results into assumptions about the entire hotel market.

Why?

Because this is an important analytical principle:

A dataset tells you about the population represented in the dataset.

It does not automatically tell you everything about the hotel's entire customer base outside that dataset.

The dashboard therefore presents these results as observations from the available booking data.

13. Guest Ratings

The average guest rating currently stands at:

3.02 / 5

But an average alone does not tell the entire story.

That's why the dashboard also includes a Guest Rating Distribution visual.

The distribution allows us to ask:

• Are ratings concentrated around the middle?
• Are there many high ratings?
• Are there low-rating bookings?
• Is the average being influenced by a small number of extreme values?

This is a good example of why one KPI should rarely be treated as the complete story.

14. Rating by Room Type

Another question I wanted the dashboard to answer was:

Do guest ratings differ across room categories?

The Rating by Room Type visual compares the average rating across room types.

This creates a connection between:

Room Type
      ↓
Guest Experience
      ↓
Rating

That can help guide deeper questions around room quality, expectations, pricing, and guest experience.

The dashboard itself doesn't claim causation.

It simply makes the relationship visible enough to investigate.

15. Services: The Extra Revenue Story

Hotels do not only earn from room bookings.

Additional services can create another revenue stream.

The dashboard therefore looks at:

• Service Popularity
• Service Bookings
• Service Revenue
• Service Attach Rate

The current dataset records:

97 service bookings

and a:

34% service attach rate

This means the service data deserves its own analytical space rather than being treated as a footnote.

16. Page Three — Operations & Revenue Intelligence

The third page is where the dashboard becomes more operational.

I designed this page around the question:

What is happening underneath the headline numbers?

The page focuses on:

• Total Revenue
• Revenue per Booking
• Completed Revenue
• Service Revenue
• Cancelled Bookings
• No Shows
• Service Attach Rate
• Average Stay

It then moves into deeper operational analysis.

Room Demand

One of the things I deliberately avoided was creating a fake occupancy KPI.

Many hotel dashboards contain something like:

Occupancy Rate: 78%

It looks impressive.

But analytics is not about making a dashboard look impressive.

The dataset I worked with did not contain reliable room inventory or room-availability data.

Without knowing how many rooms were available during each period, I could not responsibly calculate:

Occupancy Rate =
Occupied Rooms / Available Rooms

So I did not invent one.

Instead, I used measurable indicators such as:

• Booking volume
• Room type
• Nights stayed
• Revenue
• Stay patterns

This is one of the most important decisions I made in the project.

A dashboard should never manufacture precision simply because a KPI looks good on a screen.

17. Payment Analysis

The operations page also examines payment methods.

The dataset contains payment categories such as:

• M-Pesa
• Cash
• Card
• Bank Transfer

This provides a simple but useful operational question:

How are customers paying?

Payment analysis can become particularly valuable when combined with other dimensions such as:

• room type
• booking status
• revenue
• guest location
• time

The dashboard therefore provides the foundation for deeper analysis without forcing conclusions that the dataset cannot support.

18. Service Revenue

The Service Revenue visual looks beyond whether a service was used.

It asks:

Which services actually contribute revenue?

That distinction matters.

A service may be popular but generate relatively little revenue.

Another service might be used less frequently but contribute more money per booking.

Therefore:

Service Popularity
        ≠
Service Revenue

Both measurements tell different stories.

19. Designing the Dashboard

I also wanted the visual design to feel different from a typical beginner Power BI dashboard.

I moved away from a gold-heavy hotel aesthetic and developed a darker, more modern visual system.

The main palette was:

Element	Colour
Background	#07131A
Card Background	#0D1D24
Main Emerald	#00C896
Bright Emerald	#20D9A0
Secondary Green	#158F73
Main Text	#F2F7F5
Secondary Text	#8FA5A0
Cancellation	#FF6B6B
Highlight	#F3B562
Divider	#1A3036

The intention was to create a visual identity rather than simply changing chart colours.

Emerald became the dashboard's visual signature.

Red was reserved for cancellation/warning information.

Amber was used for no-shows and selected highlights.

The result is a dark hospitality dashboard with a subtle technology aesthetic.

20. Why I Used Three Pages

One of the biggest design decisions was separating the dashboard into three analytical layers.

Page 1 — Executive Overview

What is happening?

Page 2 — Guest & Experience Intelligence

Who are the guests and how are they experiencing the hotel?

Page 3 — Operations & Revenue Intelligence

What is driving the hotel's financial and operational performance?

This structure prevents the dashboard from becoming a wall of charts.

It also creates a natural analytical journey:

Overview
   ↓
Guest Understanding
   ↓
Operational Investigation

That is the difference between a collection of visuals and a dashboard designed for storytelling.

21. What I Learned

This project taught me that Power BI is actually only one part of the job.

The dashboard is the final layer.

The difficult work happens before the dashboard.

Lesson 1 — Clean data before visualizing it

A beautiful chart built from unreliable data is still unreliable.

Lesson 2 — Understand the meaning of missing values

NULL does not automatically mean zero.

The correct treatment depends on what the missing value represents.

Lesson 3 — A KPI needs a business question

Instead of asking:

"What other number can I put on this page?"

ask:

"What decision or question does this number help answer?"

That simple change makes dashboards much more purposeful.

Lesson 4 — Don't calculate what the data cannot support

The occupancy example was a major reminder.

If inventory data isn't available, don't invent occupancy.

If staff information isn't available, don't invent staff performance.

If a dataset cannot establish causation, don't present correlation as causation.

Good analytics includes knowing what not to claim.

Lesson 5 — Visualization is storytelling

The three dashboard pages aren't just three screens.

They represent three stages of investigation:

What happened?
      ↓
Who is involved?
      ↓
What is driving it?

That structure makes the dashboard easier to navigate and easier to explain.

22. What I Would Explore Next

Although the dashboard is complete, there are several directions that could extend the analysis.

For example:

• Revenue forecasting
• Customer segmentation
• Booking lead-time analysis
• Repeat-guest analysis
• Seasonal demand patterns
• More detailed service profitability
• Room-level pricing analysis
• Cohort analysis
• Predictive cancellation modelling

However, each of these would require either additional data or another analytical layer.

And that is another lesson from this project:

The next analysis should be driven by the next question—not by adding charts simply to make a dashboard bigger.

23. Final Dashboard Structure

The final report can therefore be summarized as:

TEMBO HOTEL & SUITES
        │
        ├── Page 1
        │   └── Executive Overview
        │
        ├── Page 2
        │   └── Guest & Experience Intelligence
        │
        └── Page 3
            └── Operations & Revenue Intelligence

Together, the three pages turn a hotel booking dataset into an interactive analytical experience.

Final Thoughts

This project started with rows of hotel booking records.

It ended with a business intelligence dashboard capable of answering questions about:

Revenue.

Bookings.

Rooms.

Guests.

Ratings.

Services.

Payments.

Cancellations.

Stay patterns.

But perhaps the biggest lesson wasn't about Power BI, SQL, or DAX.

It was about thinking like an analyst.

A good analyst doesn't simply ask:

"What chart can I make?"

They ask:

"What does the data actually allow me to say?"

That distinction shaped this entire project.

From the initial data-quality checks in PostgreSQL, to the cleaned tembo_hotel_clean table, to the DAX measures, to the three-page Power BI report, every stage was designed to move from raw information → reliable metrics → meaningful questions → visual storytelling.

And that is ultimately what I wanted this project to demonstrate:

Business intelligence is not about making data look beautiful. It's about making data useful.

Tools Used

Database: PostgreSQL

SQL Environment: DBeaver

Visualization: Microsoft Power BI

Analytics Language: DAX

Dataset: Hotel booking data

Project Takeaway

285 unique bookings.

KSh 8.47M recorded revenue.

KSh 29.71K average booking value.

3.00-night average stay.

3.02/5 average guest rating.

8% cancellation rate.

97 service bookings.

34% service attach rate.

KSh 7.29M completed revenue.

Kenyan guests represented the top nationality in the dataset.

Nairobi represented the top guest city in the dataset.

But beyond the numbers, the real outcome was a repeatable analytical workflow:

Clean → Validate → Model → Measure → Visualize → Interpret.

That is the workflow I will carry into my next data project.

Thank You for Reading

If you're learning data analytics, I hope this project demonstrates something important:

You don't need the most complicated dataset to build a meaningful portfolio project.

You need to be able to:

1. Understand the data.
2. Clean it properly.
3. Validate your assumptions.
4. Ask useful questions.
5. Build appropriate metrics.
6. Visualize the answers clearly.
7. Communicate what the data can—and cannot—tell you.

That's where the real analytical work begins.

Until the next dataset.