4Spaces Specification & Roadmap

Cloud access & digital-key platform — system overview, the 4Spaces / SRMS split, build status by module, and an interactive delivery timeline.

Spec & Roadmap

Rev. 3.0

4Spaces is the cloud brain of the platform: it connects to reservation systems, holds the guest and building model, and orchestrates every digital key and workflow. SRMS is a web application that can also run locally with no connectivity needed — it keeps the property issuing keys and writing cards when the cloud is unreachable, and doubles as the troubleshooting and base-model layer. 4Spaces interacts with SRMS through its API. In short: 4Spaces decides what access should exist; SRMS guarantees access can still be produced at the door regardless of network state.

01Process flow — 4Spaces (cloud)

1PMS / OTA synchronization — pulls reservations, guest and stay data from connected reservation systems.

2Digital twin creation — models the building, its spaces, access points and the business logic that governs them.

3Digital check-in — sits between sync and key issue; securely collects guest info, added guests, prepayment / authorization.

4Digital key creation & delivery — issues keys as QR, PIN or keycard; groups / de-groups into one credential.

5Workflows & rules — templates (grouped spaces), post-reservation access (sauna / spa / pool), key rotation, gating.

6Room control, statuses & logs — full or partial room control per building setup, with all statuses and audit logs.

7Distribution — the resulting configuration and credentials are pushed to Linker and made available to SRMS via its API.

02High-level architecture

Source

PMS

Source

OTA

Source

Reservations

sync

Cloud · System of record

4Spaces

Digital twin · Business logic · User data
Keys · Workflows · Check-in · Room control

push / API

Downstream

Linker

Web · Offline-capable

SRMS

Exposes API to 4Spaces
Writes keycards · Issues keys · Static rules

No connectivity needed — SRMS keeps issuing keys standalone at the property; 4Spaces interacts with it through its API.

Cloud Offline-capable

034Spaces vs SRMS — where the line sits

Dimension	4Spaces (cloud)	SRMS (offline-capable web app)
Runtime	Cloud, always-connected	Web app — can run locally, no connectivity needed
Connectors / PMS sync	Yes — full integration layer	None
User & guest data	Holds identity and stay data	No user data
Digital twin & logic	Full, dynamic, configurable	Minimal — more robust but static
Rules & workflows	Rich — templates, rotation, gating	Reduced, less dynamic set
Security	Cloud-grade	Reduced / local scope
Integration between them	Calls SRMS via its API	Exposes an API consumed by 4Spaces
Key & keycard issuance	Yes	Yes — core capability retained
Primary role	System of record & configuration	Continuity, failover & troubleshooting

04Why both are needed

Why 4Spaces

It is the only layer that can integrate, model and orchestrate. Connectors, guest identity, the building's digital twin and dynamic business logic only live where there is data, security and connectivity. This is where the property is configured and where the full, flexible guest journey is defined and controlled.

Why SRMS

A property cannot stop issuing access during an outage. SRMS is a web app that runs locally with no connectivity needed — the guarantee that keys and keycards can still be produced when the cloud or network is down. 4Spaces drives it through its API, and as a leaner static base model it also serves as the troubleshooting interface and resilient fallback.

05Product roadmap — build status by module

✓ LIVE shipped and in use → TO BUILD planned / not yet implemented Total estimate ≈ 200 MD

Effort shown in man-days (MD) — rough order-of-magnitude figures for planning only, not committed estimates.

M1PMS / Booking synchronization

✓ Live

Per-system sync — each booking system's rules implemented one by one
Hourly polling of any system, with new-vs-existing reservation mapping (legacy systems re-send everything, no change-push)
Inbound push from external systems into 4Spaces

→ To build

Self-serve onboarding — external systems log in, get an API key, test in a sandbox and integrate themselves (beyond static docs)20 MD

Subtotal20 MD

M2Integrations (connectors)

✓ Live

Bentral
Oracle (non-production)
Protel — local version
WinRASE

→ To build

Oracle — production6 MD
Protel Air — cloud version8 MD
Hotelinko6 MD

Subtotal20 MD

M3Outbound API & documentation

✓ Live

Public OpenAPI documentation for external systems
api.4spaces.io/openapi

→ To build

Interactive developer portal + sandbox (pairs with M1 self-serve onboarding)8 MD

Subtotal8 MD

M4Digital keys

✓ Live

Genealogy-based user data + overlap rules (may / may-not overlap) across staff vs guest codes
Multiple credentials per reservation — many cards, PINs, QR codes
STID mobile integration — issues a token into the guest's STID app
Per-client / per-setup key configuration

→ To build

Staff-code parity — staff codes are QR-only today; extend to cards / PIN / all types6 MD
Add extra access (e.g. sauna) to an existing synced reservation without re-templating — today it must be created as separate access, forcing data re-entry8 MD

Subtotal14 MD

M5Setup & onboarding

✓ Live

Per-client configuration of every setup

→ To build

Connector marketplace — end users see integrations and self-connect (e.g. "Connect to Bentral") with guided setup16 MD
Unified implementer interface — define space names + physically installed access points once, pushed automatically into SRMS and 4Spaces; replaces the error-prone static Excel handoff and unlocks setup at scale16 MD

Subtotal32 MD

M6Digital check-in

✓ Live

Web-form link to the guest; submitted data surfaces on the exact reservation for staff to copy into a tourism / police or PMS system

→ To build

Direct write into PMS (they usually don't accept check-in data today)10 MD
Document / photo validation with OCR (none today)12 MD

Subtotal22 MD

M7Key delivery & communications

✓ Live

Codes generated and sent as email attachments
Access code rendered with its access name in high-quality HTML that clears most mail providers
Secure URL delivery — download / view keys via link, bypassing booking-system attachment blocking on aliased sender emails (e.g. name@booking.com)
Configurable — show codes directly, or only after the check-in form is completed

→ To build

Payments & invoicing — pay-to-issue-key or pay-for-reservation flows (no payments at all today)18 MD

Subtotal18 MD

M8Reservation & key management

✓ Live

Edit any reservation / key — cancel, prolong, change dates, add physical cards, add / change PINs
Resend codes to entered emails; every action logged and shown as a management history

→ To build

Staff key flexibility — assign a key to a specific staff username / team, add cards for staff, automatic key rotation. Today keys are just generated and handed to staff outside the system: no staff registration needed, but shared codes can't be tracked (e.g. one staff member passing a code to another)10 MD

Subtotal10 MD

M9Reservation views & search

✓ Live

Reservation listing with search by date parameters and by reservation name
Real-time booked-room view — instantly see booked / free rooms and status, from PMS or SRMS (incl. Sensorix presence sensors when SRMS has them)

→ To build

Filter by room (minor)2 MD
Calendar / timeline view across all rooms8 MD

Subtotal10 MD

M10Monitoring & diagnostics

✓ Live

4Spaces app monitoring — alerts on downtime, queue-link mechanism, request spikes, failures and errors
API error handling — auto-queue + retry (10 attempts over 5 min), with email on failure

→ To build

Shared 4Spaces ↔ SRMS diagnostics — infra level (which system is down, readable by first-line support) and feature level (trace a key end-to-end, e.g. 4Spaces created & sent the code but SRMS didn't provision)16 MD
Richer state model beyond raw error states6 MD

Subtotal22 MD

M11Usage tracking & billing

✓ Live

Logging + transaction-capable data model — the prerequisite for metering is already in place

→ To build

API-call metering as the commercial basis — charge per integration (e.g. Bentral), quota models (e.g. 100k tokens), track & enforce limits13 MD
Billing, payments and the metering mechanism itself11 MD

Subtotal24 MD

06Roadmap timeline — interactive planner

Set team capacity, edit each item's MD, and reorder by priority — change the rank number or use the ▲▼ buttons. The schedule and Gantt recalculate instantly, and your changes are saved in this browser.

Developers

Hours / dev / month

Hours / MD

Team capacity · backlog

Backlog — priority order (drag rank to re-prioritize)

Delivery timeline — combined team throughput

+ Add new request