Produit / Intégrations

Laissez chaque système faire autorité. Ne connectez que ce qui améliore le séjour.

Tamaga peut fournir une base de réservation directe native de Drupal et placée sous la maîtrise de l’hôtel, ou travailler autour du PMS, du moteur de réservation, du gestionnaire de canaux, du RMS et du prestataire de paiement déjà utilisés. L’intégration commence par identifier qui répond de chaque fait, de chaque décision et de chaque écriture.

Présentez-nous vos systèmes Voir comment cela fonctionne

Choisir comment Tamaga intervient

Commencez par une base sous votre maîtrise ou par les systèmes qui traitent déjà le séjour.

Base native de Tamaga

Une base de réservation directe native de Drupal et placée sous la maîtrise de l’établissement, pour un hôtel sans moteur de réservation établi ou qui choisit délibérément un parcours maîtrisé par Tamaga.

Fournit : Un modèle hôtelier sous Drupal, un parcours client, Room Fit, des demandes encadrées, Host Attention et, en option, le CRM, Guest Memory et des couches d’intelligence limitées à l’établissement.
Conserve comme autorité : Les prestataires de réservation, de paiement et de distribution sélectionnés conservent les limites transactionnelles qui leur sont attribuées.
Limite en production : La démo publique s’arrête avant toute réservation réelle et tout paiement.

Voir comment fonctionne le produit

Tamaga connecté

Une couche encadrée de connaissances hôtelières et de demandes autour de systèmes transactionnels auxquels l’établissement fait déjà confiance.

Fournit : Des informations hôtelières encadrées, le contexte client, des demandes visibles, Host Attention, des éléments à l’appui dans les représentations et, en option, le CRM, Guest Memory et des couches d’intelligence limitées à l’établissement.
Conserve comme autorité : Le PMS, le moteur de réservation, le gestionnaire de canaux, le RMS et le prestataire de paiement conservent les fonctions dont ils ont la charge.
Limite en production : Les connexions se limitent à la plus petite opération de lecture, d’écriture ou de transmission étayée par des éléments suffisants.

Définir la répartition des responsabilités

Identifiez qui répond du fait, de la décision et de l’écriture avant de choisir comment les connecter.

Trois territoires montrent qui effectue la transaction, où le sens lourd de conséquences est encadré et où le client ou l’établissement décide. Seuls les systèmes réellement utilisés par l’établissement figurent dans la référence détaillée des responsabilités ci-dessous.

Un responsable identifié pour chaque fait lourd de conséquences.

Les disponibilités, le sens, l’état de la réservation et le règlement conservent chacun un système faisant autorité clairement nommé.

Aucun remplacement silencieux du système faisant autorité.

Un état absent, obsolète ou indisponible devient visible au lieu d’être remplacé par une réponse non étayée.

Chaque transmission laisse des éléments à l’appui qui peuvent être examinés.

Le contexte client, la responsabilité attribuée et le résultat externe restent disponibles pour la résolution et la revue.

Couches produit optionnelles

Relier les enregistrements sans confondre ce qui fait autorité.

Pont CRM

Le pont est asynchrone et isolé en cas de défaillance : une panne du CRM ne peut pas interrompre la réservation qui fait autorité. Une identité ambiguë exige un rapprochement par un opérateur, jamais une fusion silencieuse.

Guest Memory

Guest Memory sert uniquement un objectif opérationnel. Il n’existe ni promotion automatique ni portabilité entre établissements ; un périmètre absent ou obsolète entraîne un refus par défaut.

Tamaga Intelligence

Tamaga Intelligence lit les affirmations publiques de l’établissement, sépare les données par établissement avant de les classer, rejette à la lecture les affirmations obsolètes ou non publiées et réduit prudemment ses capacités en cas de dérive du fournisseur ou du modèle, sans basculement silencieux.

Un parcours connecté

Gardez visible le système qui fait autorité sur la transaction, de la décision à l’examen ultérieur.

Le client décide dans Tamaga, un système externe effectue la transaction, et la condition lourde de conséquences reste disponible pour être résolue et examinée.

Contexte Tamaga
1. Décider dans Tamaga
Le client voit Room Fit, les limites et un parcours de demande assortie de conditions.
Système externe faisant autorité
2. Effectuer la transaction à l’extérieur
Le système de réservation faisant autorité détermine les disponibilités, l’état de la réservation et le paiement.
Résolution humaine
3. Préserver et résoudre
Tamaga garde la condition compréhensible pour le client, l’établissement et tout examen ultérieur.

Transmettre le contexte ne signifie pas que la transaction a réussi.

Un lien profond ne vaut pas confirmation de réservation.

Renvoyer une référence ne constitue pas une écriture universelle dans le système source.

Un échec externe ne peut pas être présenté comme une réussite.

Référence de mise en œuvre

Choisissez la connexion étayée la plus étroite pour les systèmes réels de l’établissement.

Les détails techniques restent disponibles sans concurrencer le modèle de responsabilités ni le séjour connecté.

Référence complète des responsabilités

Seuls les systèmes réellement utilisés par l’établissement figurent dans cette carte des responsabilités.

Sujet	Système faisant autorité par défaut	Relation avec Tamaga
Informations sur la chambre, fait qu’elle convienne et limites	Tamaga House Record	Encadre et projette
Tarifs, restrictions et disponibilités en temps réel	PMS, CRS ou moteur de réservation	Consulte ou conserve une référence
État de la réservation	PMS, CRS ou moteur de réservation	Synchronise ou transmet lorsque des éléments suffisants l’étayent
Distribution du stock de chambres sur les OTA	Gestionnaire de canaux	Ne duplique pas la distribution
Recommandations tarifaires	RMS	Peut recevoir ou conserver le contexte ; ne remplace rien silencieusement
Autorisation du paiement et règlement	Prestataire de paiement	Transmet et enregistre un état de référence sûr
Demande assortie de conditions propre au séjour	Flux de travail Tamaga	Préserve l’état et la responsabilité
Confirmation lourde de conséquences	Personne responsable	Rend visibles l’action et son résultat
Comptabilité, POS, entretien des chambres et opérations spécialisées	Système spécialisé existant	Reste hors de Tamaga sauf intégration étroitement délimitée
Identité du contact	CRM Drupal	Jamais rapprochée ni fusionnée silencieusement ; toute identité ambiguë exige la revue d’un opérateur
État de la réservation et du séjour	PMS source, Commerce ou BEE	Continue de faire autorité tandis que Tamaga projette le contexte hôtelier minimal
Association entre le séjour et le contact	CRM Tamaga	Relie le contexte sans devenir l’autorité de réservation
Préférence opérationnelle réutilisable	Guest Memory	Limitée à l’établissement, établie explicitement et appliquée après examen de sa pertinence
Réponse publique fondée sur les connaissances	House Record et Answer Policy	Le fournisseur d’IA formule la réponse, mais ne fait jamais autorité
Consentement marketing	Enregistrement du consentement propre à la finalité et au canal	Reste distinct de l’usage opérationnel et n’est jamais déduit

Configurations courantes

Réservation directe native de Tamaga

Autorité conservée: Tamaga maîtrise le modèle hôtelier et le parcours client ; les prestataires de production sélectionnés conservent les limites transactionnelles qui leur sont attribuées.
Tamaga ajoute: Une même base Drupal encadrée pour les informations sur la chambre, le fait qu’elle convienne, les conditions, les demandes et Host Attention.
Point de départ le plus sûr: Définissez les limites de l’établissement pour la réservation, le paiement et la distribution.
Limite d’accès: Les décisions opérationnelles de l’établissement et les accès des prestataires sont requis avant toute mise en production.

Suite tout-en-un pilotée par le PMS

Autorité conservée: La suite conserve les disponibilités en temps réel, les tarifs, l’état des réservations et les fonctions qu’elle traite déjà.
Tamaga ajoute: Des informations encadrées sur la chambre, le contexte client, l’état des demandes et une intervention humaine dont la responsabilité est attribuée.
Point de départ le plus sûr: Commencez par la plus petite lecture ou transmission autour d’une promesse lourde de conséquences.
Limite d’accès: Les accès de l’établissement et du fournisseur déterminent si le périmètre peut fonctionner en direct, par export ou manuellement.

PMS modulaire + moteur de réservation + gestionnaire de canaux

Autorité conservée: Chaque système conserve sa responsabilité documentée pour l’état de la réservation, le parcours de réservation et la distribution.
Tamaga ajoute: Un House Record et un contexte reliant le client à l’établissement qui survivent au passage entre ces systèmes.
Point de départ le plus sûr: Faites correspondre un identifiant de chambre, de tarif ou de demande lors de la transmission nécessaire.
Limite d’accès: Des identifiants stables et l’accès à chaque contrat pertinent sont requis.

PMS + gestionnaire de canaux + RMS

Autorité conservée: Le PMS, le gestionnaire de canaux, le RMS et les systèmes spécialisés conservent leurs décisions opérationnelles distinctes.
Tamaga ajoute: Des informations encadrées et le contexte de décision sans remplacer silencieusement les décisions tarifaires ni l’état des systèmes spécialisés.
Point de départ le plus sûr: Commencez en lecture seule autour de la décision dont le contexte se perd.
Limite d’accès: L’accès du fournisseur et une répartition explicite des responsabilités sont requis avant toute écriture.

Systèmes à accès limité ou manuels

Autorité conservée: Les enregistrements existants et les personnes responsables continuent de faire autorité.
Tamaga ajoute: Une couche d’informations revue, un état de demande visible et une transmission humaine contrôlée.
Point de départ le plus sûr: Utilisez un export/import revu ou une transmission manuelle documentée.
Limite d’accès: Si l’accès du fournisseur n’est pas disponible, la dépendance est documentée au lieu d’être remplacée par un connecteur inventé.

Méthodes de connexion

Utilisez la connexion la plus étroite qui rende la prochaine décision du client ou de l’établissement plus sûre.

API ou webhook

Utilisez un contrat stable de lecture ou d’écriture avec des règles explicites de nouvelle tentative, d’idempotence et de rapprochement.

Sélectionné uniquement lorsque l’accès et le comportement en cas d’échec sont étayés.

Export/import revu

Utilisez un traitement par lots revu lorsque l’accès en temps réel est indisponible ou inutile.

Utile pour une migration par étapes, une actualisation encadrée ou une preuve en lecture seule.

Lien profond prérempli

Transmettez le contexte au système qui porte l’action lourde de conséquences, sans prétendre qu’elle est accomplie.

Une transmission, pas une confirmation de réservation.

Parcours intégré

Gardez la décision proche du parcours client tandis que le système intégré continue de faire autorité.

Nécessite un contrat de transaction et de défaillance au périmètre délibérément défini.

Transmission humaine contrôlée

Rendez visible l’intervention de la personne responsable lorsqu’aucune connexion technique sûre n’est disponible.

Valable pour les pilotes, les exceptions et les systèmes à accès limité.

Connecter avec honnêteté, rendre les échecs visibles.

Une transmission sûre vaut mieux qu’une fausse réussite.

Lecture indisponible

Affichez le dernier état connu avec un libellé clair, ou bloquez l’action.

Écriture indisponible

Utilisez le mode lecture seule ou transmettez la tâche.

Résultat de transaction inconnu

Exigez un rapprochement.

Correspondance de chambre ou de tarif absente

Refusez l’opération par défaut.

Source faisant autorité obsolète

Ne produisez aucune nouvelle projection lourde de conséquences.

Accès du fournisseur indisponible

Documentez la dépendance au lieu d’inventer une intégration.

Identité de contact ambiguë

Exigez un rapprochement par un opérateur ; ne fusionnez pas les contacts silencieusement.

Synchronisation CRM indisponible

Préservez la réservation qui fait autorité et rapprochez le contexte ultérieurement.

Périmètre ou revue de Guest Memory indisponible

N’appliquez pas la mémoire.

Qualification de l’intelligence ou dérive du fournisseur

Utilisez un repli déterministe, une réduction de capacité ou une indisponibilité temporaire ; ne basculez jamais silencieusement.

Décrire uniquement le périmètre étayé.

Tamaga ne publie actuellement aucun catalogue universel de connecteurs.

Un statut décrit un périmètre étayé précis. Il n’implique jamais une prise en charge de chaque établissement, flux de travail ou version d’un fournisseur.

Production: Fonctionne en direct dans le cadre d’un contrat étayé et d’un comportement en cas de défaillance vérifié.
Pilote: Évalué dans un périmètre nommé, avec des conditions de revue et de retour arrière.
Adaptateur disponible: Un adaptateur technique réutilisable existe ; la connexion de l’établissement exige encore une validation.
Connexion sur mesure: Une mise en œuvre au périmètre délibérément défini est requise pour l’établissement ou le fournisseur.
Transmission: Tamaga transmet le contexte au système ou à la personne responsable de l’action.
Lecture seule: Tamaga peut examiner ou expliquer l’état sans modifier le système source.
Accès du fournisseur requis: La progression dépend d’un accès contrôlé par le fournisseur, de son approbation ou d’un contrat.

Poursuivre le maillage

Suivre la prochaine relation utile.

Partir des systèmes réels

Connectez le périmètre minimal qui résout un problème lourd de conséquences.

Présentez à Tamaga les systèmes, la répartition des responsabilités et la promesse faite au client. La première étape consiste à décider ce qui doit continuer de faire autorité, plutôt qu’à tout remplacer.

Présentez-nous vos systèmes