Skip to content
Muslu Yüksektepe

Otel iş akışı paneli

A hotel management panel for multi-property businesses, combining front office, sales, operations, reviews, ads and accounting.

The Hotel Workflow Panel is a comprehensive hotel management panel I built for businesses that operate more than one hotel. I developed it for Makdos, and it brings front office, housekeeping, technical service, food and beverage sales, purchasing, shifts, guest relations and accounting into a single application. On top of that, it continuously monitors guest reviews and advertising campaigns on external platforms, raises alerts according to defined rules, and offers a query screen for analysing the data.

Purpose

In hotels, the reservation software, accounting program, review sites, ad dashboards and messaging tools usually work in isolation from one another. A guest's complaint arrives on WhatsApp, the same guest's negative review lands on a review site, and a technical fault is written in a separate log. I built this panel to bring these scattered flows into one record structure and to let hotel management see what is happening from a single screen.

Another aim is to let a business with several hotels manage all of them from the same installation while keeping each hotel's data separate. Users are assigned to hotels and see only the data of the hotels they are authorised for. The panel's name, logo and colour come from the installation settings, so each customer uses it under its own brand.

How it works

Every hotel-related record in the panel belongs to a hotel, and every request is processed only after checking that the user has access to that hotel. If a room, guest, product or user identifier sent in a request belongs to a different hotel, the request is rejected. Permissions work along two axes. On the role axis, a viewer reads, an editor adds and edits, an admin deletes and approves, and the account owner can do everything. On the module axis, it is decided which departments, such as front office, housekeeping or purchasing, the user may access.

On the front office side, room types, rooms, agencies and guests are defined. Reservations are managed with a state machine, which means the transitions a reservation can make from one status to another are limited by rules. The number of guests cannot exceed the room type's capacity, a new reservation cannot start in the past, and a separate background job handles guests who do not show up. Sales and refunds during the stay are posted to the guest's folio, that is, the guest's account statement, and payments are linked to that folio.

I built a background job system that runs as a single loop. It synchronises external sources when they are due, uses database locks to prevent the same source from being processed twice, increases the waiting time after consecutive errors, and raises an alert if synchronisation keeps failing. Alert rules are evaluated only for newly arriving records, and the same alert is never created twice. Alerts are shown in the panel and can also be sent by email or Telegram.

Key features

  • The front office screens cover reservations, check-in and check-out, visitor registration and room status, and a guest's identity number is masked in lists and in the audit log.
  • Housekeeping and technical service keep records of faults, cleaning, complaints, requests and lost property.
  • Product and stock management tracks a critical stock threshold and raises an alert when stock falls below it.
  • Purchase requests and staff shifts are planned and approved through the panel.
  • Guest reviews from sources such as Google Business Profile, YouTube, TripAdvisor and Booking are fetched regularly through official APIs, and reviews can also be added by CSV or by hand.
  • Draft replies to reviews can be prepared with AI, but every draft goes through human approval, and promises of refunds, discounts or prices are blocked in the draft.
  • Daily metrics of Google Ads, Meta and LinkedIn campaigns are monitored, and pausing, starting or changing a campaign's budget is first tested in a dry-run mode.
  • Messages arriving through the WhatsApp Cloud API are collected in an inbox, AI analyses their intent and sentiment, rule-based automatic replies are suggested, and the conversation is handed over to a staff member when needed.
  • SMS and email can be sent, marketing messages go only to guests who have given consent, and consents are synchronised with İYS, the Turkish commercial message consent registry.
  • Expenses can be imported from CSV or Excel files and synchronised with accounting programs such as Logo, Netsis, Mikro and Paraşüt.
  • The analysis screen runs on a query engine whose sources, dimensions and measures are restricted by an allow list on the server, and it does not allow free-form SQL.
  • The accounting module includes the cash ledger, cheques, bank movements and currency conversion with Central Bank of Turkey rates.

Security

Credentials entered for connecting to external services are stored in the database encrypted with AES-256-GCM. They are never returned in any API response and are also stripped from error messages. Notifications coming from WhatsApp are not accepted without signature verification. I work with external platforms only through official APIs and the customer's own credentials, and I do not rely on scraping.

I set up the panel so that it can be sold to multiple customers. Each customer is tied to a package that limits the number of hotels it can open, and the customer's administrator is the account owner across all of its hotels. Makdos enters its own section through the same panel, where it manages customers, packages, support tickets and invoices, but it does not see customers' hotel, department, user or transaction data.

Technical stack

  • I wrote the server side in Go, using the chi library for routing.
  • I use PostgreSQL as the database, with pgx for connections and goose migrations embedded in the program for schema changes.
  • Money amounts are stored as numeric in the database and carried as text in JSON.
  • Sessions are managed with HttpOnly cookies and passwords are stored with argon2id.
  • I built the interface with React 19, Vite, TypeScript and Tailwind, and I use recharts for charts.
  • The event cards on the dashboard are updated over an SSE connection, through which the server pushes live notifications.
  • I wrote an end-to-end test that runs in headless Chrome, visits every screen and deliberately enters invalid values into form fields to test the validations.
  • The server takes a nightly backup, and once a week it automatically checks that the backup can actually be restored.

For accessibility, I aimed for a full Lighthouse accessibility score in both light and dark themes and reached that goal on the pages I measured.

Use cases

  • Hotel chains and groups with several properties can manage all of their hotels separately from a single panel.
  • It suits sales and marketing teams that want to follow guest reviews and social media feedback in one place.
  • Managers who want to see advertising spend and campaign performance per hotel can use the panel.
  • It helps guest relations teams that want to communicate with guests over WhatsApp, SMS and email in line with consent rules.

Status

All screens of the panel are live in the test environment. The multi-customer structure and the Makdos section are complete, and I am continuing to work on row-level security isolation for the hotel tables. Live verification of the external service connections with real accounts is also on the list of remaining work.

Category
Business panels
Year
2026

Technologies

  • Go
  • PostgreSQL
  • React
  • Hospitality
  • AI

Back to all projects