Architecture, Team and Delivery Model You Can Audit

Architecture diagram showing multi-tenant aparthotel platform on Russian hosting with isolated organisation tenants and 152-FZ consent flow
Russian hosting, multi-tenant isolation and consent flows built into authorisation — not bolted on afterwards.

Architecture and Data Protection by Design

Where guest and resident data is stored

The platform runs on Russian hosting infrastructure and meets the requirements of Federal Law 152-FZ on personal data. Every operator works inside an isolated tenant, so service apartment data from one property never crosses paths with another. The processing of guest and resident personal data in aparthotel contexts is documented at contract level — operator and processor roles are defined explicitly.

  • Hosting jurisdiction: Russian data centres, no cross-border transfers
  • Tenant model: multi-tenant SaaS with strict logical isolation per organisation
  • Regulatory basis: 152-FZ compliant SaaS for hospitality operators
  • Audit posture: documented controller and processor roles per organisation

Consent built into the workflow

Consent to process personal data is part of every authorisation flow — the Telegram bot, the web chat, and the resident onboarding code. A resident receives an access code from reception at check-in and activates their account before any request is recorded. No silent data collection, no manual paperwork on the desk.

  • Bot and web chat: explicit consent step before the first message is processed
  • Resident activation: code-based onboarding with logged confirmation
  • Knowledge base scope: the assistant answers strictly from your documents, never invents facts
Editorial portrait composition representing a founder duo combining IT and IP legal expertise with platform engineering for hospitality software
Two domains rarely combined in one team: hands-on platform engineering and 16 years of IT and IP law.

The Family Team Behind the Platform

Victoria Briem — founder and managing director

Victoria leads BriemChain AI and owns the commercial and legal foundation of the product. The reason data protection sits inside the architecture from day one — rather than being patched on later — is that the legal model was drawn before the first line of code. This is what distinguishes the platform from purely technical aparthotel tools.

  • Experience: 16 years in IT and IP law, digital project protection
  • Scope: 152-FZ compliance, contracts, operator and processor model in a multi-tenant platform
  • Client support: ongoing guidance on regulatory matters

Walter Briem — platform architect and lead developer

Walter is the author of the platform architecture and personally configures every new property during launch. The dispatch logic, the multilingual assistant grounded in a per-property knowledge base for staff, and the automated assignment by specialisation all come from his engineering work. He has been in IT since 2015, with professional education and certification obtained in Germany.

  • Specialisation: business process automation and web development
  • Background: German engineering school, certified curriculum
  • Hands-on role: architects the core and configures each property personally at launch

Why this combination matters

Legal and engineering live under one roof — the same family. Decisions about how to store guest data, how to model controller and processor roles, and how to design the assistant's knowledge base are made together. The result is one coherent product, not a stitched-together set of tools, and it shows in the operational dispatch quality on every property.

Calendar-style illustration of a three-day white-glove onboarding for an aparthotel dispatch platform with knowledge base, routing and go-live milestones
We configure your virtual organisation. You receive a working operational cockpit — no staff training required.

White-Glove Delivery: Live in 2–3 Days

What white-glove actually means here

We do not ship a constructor and walk away. White-glove rollout for a service apartments operator means we load your property documents, define the categories that match the way you operate, set up specialisation roles for technicians and reception, and connect your branded Telegram bot. You receive a ready operational instrument on day three.

  • Day 1: kick-off, knowledge base intake, categories and specialisation map agreed
  • Day 2: tenant configuration, automated assignment by specialisation, SLA thresholds set
  • Day 3: branded Telegram bot live, reception activation codes issued, go-live
  • Training: not required — the team operates through the Telegram interface they already use

See pricing and timing →

How a ticket flows once you are live

A guest or resident writes into the bot or web chat in their own language, or taps a category button. The request becomes a typed entity — lead, task or ticket — and is routed to the least loaded specialist of the required role. The ticket runs through clear statuses (new, accepted, in progress, on site, awaiting access, completed) with an SLA attached. Before-and-after photos are attached on completion, and the client confirms the result with a rating. If the issue is not solved, the ticket is reopened.

  • Channels in: branded Telegram bot, web chat, web form, email
  • Routing: category → required specialisation → least-loaded specialist, with fallback cascade to dispatcher
  • Evidence trail: status history, SLA timer, before-and-after photos, client confirmation and rating
  • Resident onboarding: code-based activation at check-in, then access to their own tickets

What it adds to your operation

The scattered channels and quietly lost requests from the earlier story turn into a documented stream of accountable work orders. New and seasonal staff find answers in the knowledge base instead of in colleagues' heads. The resident lifecycle — from activation to repeat requests — runs inside one system, on Russian hosting, under one operator account.