Vision produit

Bell, c'est ce que serait un PMS s'il avait été conçu en 2026 pour le guest, pas pour le réceptionniste. On ne remplace pas le PMS — on devient la couche guest-facing qui manque à tous les PMS du marché.

Le problème qu'on résout

Un guest qui arrive dans un hôtel 4/5 étoiles aujourd'hui fait toujours la même chose qu'il y a 20 ans :

• Attente 5-15 min à la réception à l'arrivée
• Téléphone de chambre qui date des années 90 pour commander un room service
• Pas de moyen simple de savoir quand son linge sera rendu, ou si sa réservation spa est bien confirmée
• Communications staff par SMS ou WhatsApp sur le numéro perso du réceptionniste
• Zéro visibilité en temps réel sur l'état de ses commandes en cours

Côté staff :

• Réceptionniste scotché à son téléphone
• Cardex géré dans le PMS de l'hôtel (Mews, Opera) — interface de 2015
• Aucune vision transverse "qui est en train de discuter avec qui ?"
• Pas de data propre pour prioriser (qui est VIP ? qui vient de Booking ? qui reste combien de nuits ?)

Ce que Bell fait

Côté guest (PWA bell-app.hoaiy.com) — accessible sur invitation de l'hôtel uniquement :

• Pré-check-in digital avant l'arrivée (identité + paiement + upsells)
• Concierge IA disponible 24/7 pour toutes les demandes
• Room service, spa, laundry, restaurant bookings en quelques clics
• Suivi temps réel des commandes en cours
• Chat avec le staff physique quand l'IA ne suffit pas
• Pas d'app à télécharger : lien unique par mail, installable à l'écran d'accueil (PWA)

Côté staff (dashboard bell-staff.hoaiy.com) — desktop-first :

• Cardex unifié (guests actuels + à venir + historiques)
• Chats en temps réel, escalade vers tickets si besoin
• Calendrier arrivées/départs
• Analytics : occupation, RevPAR, revenus upsells, conversion par canal
• Configuration des intégrations (PMS, OTAs)
• Gestion multi-hôtels pour un GM portfolio

Côté infra :

• Agnostique du PMS : pattern adapter (Mews, Opera, Cloudbeds, ...)
• Hôtel sans PMS fonctionne aussi — Bell est master, le PMS est un satellite optionnel
• Multi-tenant strict (un hôtel = une organization, isolation totale des données)

Les 3 différenciateurs

1. Guest-first, pas admin-first

La plupart des PMS du marché (Mews inclus) sont des outils pour la réception. Leurs portails guest sont des afterthoughts. Bell inverse : on part du besoin guest, on s'intègre au PMS pour le staff.

2. Agnostique du PMS

Pattern adapter. Un hôtel Mews, Opera, Cloudbeds, ou sans PMS → on fonctionne. Zéro lock-in sur un vendor. On branche un nouveau PMS en ~1 semaine via le skill bell-pms-adapter.

3. Channel tracking via Mews (et OTAs futurs)

Sans intégrer aucune OTA nous-même (Booking.com, Expedia, Airbnb pas d'API publique accessible sans certifs longues), on détecte le canal de chaque réservation via ce que Mews agrège (champ CommanderOrigin). Résultat : un GM voit dans le cardex Bell "ce guest vient de Booking.com" sans qu'on ait touché à une seule API OTA.

Modèle économique (HOAIY)

• B2B SaaS abonnement mensuel par propriété (hôtel)
• Frais de service guest (1 % du total des upsells payés dans l'app) — transparent dans la facture guest
• Future : marketplace de services partenaires (restaurants, transferts aéroport, expériences locales) avec commission
• Future : HOAIY Loyalty cross-hôtels si adoption critique

Tous les détails business sont chez HOAIY, pas dans la doc technique.

Positionnement

Bell, c'est la couche guest-facing qui manque à tous les PMS du marché. On n'est pas un PMS. On n'est pas un channel manager. On n'est pas un concurrent Mews — on est le front-of-house digital de Mews (et des autres).

Prochaine étape

• Acteurs — qui utilise Bell et comment
• Spec fonctionnelle — features détaillées par module
• Flows — schémas mermaid des parcours critiques