Product / Tamaga Hospitality

Direct booking, hotel knowledge, and guest context, built around one accountable House Record.

Tamaga gives independent hotels an owned Drupal-native direct-booking foundation, or connects governed hotel knowledge, guest relationships, explicit Guest Memory, and House-scoped intelligence around the systems already running the stay.

See how it works Explore the Hotel Demo

One product. Two equal deployment patterns. Explicit authority.

Four working surfaces

Govern the meaning, help the guest decide, give conditions an owner, and inspect the evidence.

01
House Record
Keep approved truth accountable.
Approved facts, conditions, provenance, authority, and review status stay explicit.
02
Guest View
Help the guest understand honestly.
Room Fit and Ask the House explain approved truth; conditional requests remain distinct from confirmation.
03
Host Desk
Give responsible work an owner.
CRM-linked Guest Context, current Guest Memory, and review-only staff assistance support a responsible human.
04
Channel Lens
Inspect representation evidence.
Compare what the House approved with what each selected representation says; it is not distribution or automated repair.

Follow one promise through the system

Three continuity layers

Keep the person, the stay, and the answer distinct.

Enduring identity, without silent matching.

CRM connects people to stays.

Drupal CRM Contact is enduring identity. Tamaga links it to a source-authoritative stay without equating Contact, Drupal User, Commerce profile, or reservation. Ambiguous identity stays visible for operator review.

Explicit context, scoped to the House.

Guest Memory remembers less on purpose.

Only explicit, provenance-bearing context that still applies to this House and stay can be reusable. A Stay Request never becomes a preference automatically; unknown and review-due context is not current.

Governed answers, never invented authority.

Tamaga Intelligence answers from governed truth.

House-scoped retrieval, deterministic Room Fit explanation, request preparation, and review-only staff drafting remain bounded by the House Record. A model never makes a promise, confirms, books, sends, or reads CRM or Guest Memory; public answers retain state_change=false.

Two deployment patterns

Choose an owned direct-booking foundation or connect the stack already running the stay.

Tamaga-native direct booking

An owned Drupal-native path for hotels that want Tamaga to provide the direct-booking foundation.

Tamaga provides: Hotel and room content, availability, Room Fit, booking context, governed conditions, Host Attention, and optional CRM, Guest Memory, and House-scoped intelligence layers.
Authority: Tamaga owns the experience and product model; an appropriate payment provider remains authoritative for authorization and settlement.
Start here: Start with one property, its room model, and the direct-booking decisions guests must make correctly.
Evidence boundary: The fictional Hotel Demo demonstrates the hotel model, search, availability evaluation, Room Fit, room selection, conditional requests, and authorized host resolution. A live property implementation remains pilot-stage.

Explore the Hotel Demo

Connected Tamaga

A governed hotel-knowledge and request layer around an established transactional stack.

Tamaga provides: House Record, guest context, request state, Host Attention, representation evidence, and optional CRM, Guest Memory, and House-scoped intelligence around existing systems.
Authority: The PMS, booking engine, channel manager, and payment provider remain authoritative for the functions they already own.
Start here: Start with one consequential promise and the smallest evidenced read, handoff, or integration contract needed to preserve it.
Evidence boundary: Authority and handoff patterns are documented and demonstrated. Property-specific access, connector work, and write-back require a scoped pilot.

Explore Integrations

Property fit

A clear fit is more useful than a universal claim.

Tamaga is designed for independent properties where room differences, guest conditions, and responsible human judgment materially affect the stay.

Strong fit

Direct booking and an owned guest relationship matter.
Room fit, access, arrival, meal, parking, or policy questions recur.
Important knowledge is fragmented across systems, messages, documents, and staff memory.
The property wants either an adaptable Drupal-native path or a governed layer around its current stack.

Deliberate non-fit

Enterprise chains seeking a global CRS replacement.
Buyers seeking only a visual redesign or isolated booking widget.
Operators expecting Tamaga to replace accounting, POS, housekeeping, revenue management, payments, and every distribution system.

Maturity ledger

Demonstrated, qualified, pilot-stage, in development, and later are different promises.

Demonstrated

Tamaga-native foundation and House Record

The fictional implementation demonstrates the hotel and room model, availability evaluation, Room Fit, governed conditions, and booking context.

Demonstrated

Guest View, Stay Requests, Host Attention, and Channel Lens

Guest decisions, conditional request state, responsible human resolution, and deterministic representation comparison are inspectable in the public Demo.

In active development

CRM and Guest Context

The product model keeps enduring contact identity distinct from the source-authoritative stay and makes ambiguous association a reviewable decision; a public Hotel Demo release does not yet prove live CRM operation.

Pilot stage

Live property implementation and connectors

A real property requires a scoped pilot, its own authoritative systems, access, data contract, and operational acceptance.

In active development

Guest Memory

Guest Memory remains in active development for the next Tamaga Hospitality release and requires explicit establishment, provenance, scope, retention, and human review.

Qualified, activation gated

Tamaga Intelligence

Qualified, activation gated. Public activation remains deferred until the governed Demo release and operational gates are complete; no live promise, confirmation, booking, sending, or CRM/Guest Memory access is implied.

Later

Live channel acquisition and automated repair

No live connector portfolio, autonomous channel acquisition, or automated repair-task claim is made today.

Choose the next proof

Go deeper according to the question you need answered.

How it works
Understand the end-to-end path from approved hotel meaning to guest decision, host action, and representation evidence.
Follow the promise path
Integrations
Understand authority, handoffs, and the connected-property deployment pattern.
Review integration patterns
Hotel Demo
Inspect the fictional working implementation from the guest and host sides.
Explore the Hotel Demo
Seven-Version Snapshot
Request the current human-reviewed service for one consequential hotel promise.
Request a Snapshot

Commercial questions

Choose the deployment pattern before choosing the integration work.

Does Tamaga replace my booking engine?

Tamaga-native deployment provides an owned Drupal direct-booking foundation. Connected deployment preserves an established booking engine or PMS as the authority for the functions it already owns.

Are live connectors already available?

Integration contracts, authority patterns, and controlled handoffs are demonstrated. A real connector depends on the property, vendor access, required direction of travel, and a scoped pilot; Tamaga does not claim a universal live connector portfolio.

Where should my property start?

Choose the deployment pattern, then start with one room decision or hotel promise that a guest cannot afford to misunderstand. The Hotel Demo shows the product; a Seven-Version Snapshot is the current human-reviewed service.

Choose a starting point

Start with one hotel promise that deserves accountable handling.

Inspect the product, choose the deployment pattern, and identify the first room decision, condition, or representation that should remain clear.

Request a Seven-Version Snapshot Contact Tamaga