Twee grote punten eerst, dan de rest. Ik ben eerlijk omdat dat voor jou nuttiger is dan beleefd zijn. 1. Laat ons het boekingsysteem ontwerpen, of laat ons er zelf een bouwen bovenop dat van jullie. Het systeem is ons zwakste punt in conversie, en ik zie dat terug in onze analytics: mensen komen op onze landingspagina, lezen over de accommodaties, bekijken meerdere pagina's, voeren hun data in, worden doorgegeven aan het Little Hotelier-systeem en vertrekken weer. Het uitvalpercentage daar is het hoogste in de hele reis, en dat komt doordat we zo weinig kunnen aanpassen. Kleuren kiezen is geen personalisatie. Een voorbeeld dat we elke week krijgen: een huis met één slaapkamer toont een persoon-icoon met "4", terwijl de werkelijkheid twee volwassenen, één kind en één baby zijn. Dat icoon zorgt voor verwarring en e-mails, en we kunnen het niet aanpassen of uitleggen. Wat we nodig hebben is ofwel echte ontwerpcontrole, dus aangepaste HTML, CSS en code-injectie op het systeem, of beter nog een headless boekings-API (zoeken, offerte, vasthouden, boeken, betalen) zodat we onze eigen front-end kunnen bouwen die rechtstreeks feedt in Little Hotelier. Op dit moment is het ontwerp zo matig dat accommodaties zoals de onze overwegen over te stappen naar een ander systeem, zodat de leads waar we hard voor gewerkt hebben, omgezet worden in boekingen. 2. De API is niet genoeg. Het ophalen van live beschikbaarheid en tarieven stopt daar. Er is geen manier om een tarief of restrictie te schrijven, geen webhooks wanneer een boeking binnenkomt, geen iCal-export en geen reserveringsfeed, en jullie voorwaarden verbieden scrapen, dus er is geen geautoriseerde manier voor de tools van een operator om op het account te handelen. We hebben een script gebouwd dat elke dertig minuten jullie API peilt om live beschikbaarheid op onze website te tonen, en elke tariefwijziging moet nog steeds handmatig via de web UI worden doorgevoerd. Mijn team werkt vooral met AI, vooral Claude, en dat doen de meeste kleine operators nu ook. We zijn snel gegaan door AI systemen te laten bouwen die onze PMS en POS verbinden, en Little Hotelier is het onderdeel dat niet verbonden kan worden. Een goede read/write API, webhooks en een officiële integratie voor AI-assistenten zouden operators zoals ik in staat stellen het eigendom veel efficiënter te beheren, en het zou jullie de duidelijke keuze maken voor de klanten aan wie jullie daadwerkelijk verkopen. 3. Virtuele kamers. Het verkopen van meerdere kamers als één eenheid, of één eenheid als meerdere, is essentieel voor een accommodatie zoals de onze en Cloudbeds doet dat al jaren. Ik was verrast dat het ontbreekt. 4. Gesloten tariefplannen worden weergegeven als "Uitverkocht". Wanneer ik een afgeprijsd plan stop-verkoop op bepaalde data, zien gasten dat plan vermeld als "Uitverkocht" naast het standaardtarief op hetzelfde huis, waardoor het lijkt alsof iets niet beschikbaar is terwijl dat niet zo is. Een plan dat gesloten is voor de gesuchte data zou gewoon niet moeten verschijnen. Gerelateerd: er is geen regel voor "dit tariefplan geldt niet voor verblijven die deze data aanraken", dus de enige tool is stop-verkoop, kanaal per kanaal. Het systeem vertaalt automatisch de namen van onze accommodaties. Wanneer een gast browser op Thais staat, wordt "White House" ทำเนียบขาว, de residentie van de Amerikaanse president, "Turquoise" wordt de kleur, en een van onze vertaalde beschrijvingen bevat een fragment Japans midden in een Thaise zin. Eigen namen moeten nooit automatisch vertaald worden, en we moeten vertalingen per taal kunnen reviewen of overschrijven. 1. Bulk tariefupdates overschrijven stilzwijgend. Het laatste tarief dat wordt opgeslagen op een datum wint, dus het opslaan van een basisprijs over een bereik wist de weekend- en feestdagen-overschrijvingen die al op die data stonden. Er is geen preview van wat er zal veranderen, geen ongedaan maken en geen audit trail van tariefwijzigingen. We werken nu in een strikte drie-ronden volgorde om onze eigen prijzen niet te vernietigen, iets wat geen operator op de harde manier zou moeten leren. 2. Labels die we niet kunnen controleren. Elke tarief in het systeem zegt "30% aanbetaling vereist" vanwege een instellingen-schakelaar, ongeacht of een betaalgateway is verbonden, en er is geen manier om dat te bewerken of te verbergen. Zelfde familie als het occupancy-icoon: het systeem vertelt gasten dingen die wij niet hebben gezegd. 3. Beveiliging is overdreven voor de mensen die het dagelijks gebruiken. Constant uitloggen, verplichte wachtwoordwijzigingen elke paar maanden, hetzelfde op de app. Vertrouwde apparaten, passkeys of langere sessies op bekende apparaten zouden de beveiliging behouden zonder de dagelijkse frictie. Frustrerend, maar niet zo kostbaar als de bovenstaande punten. Twee kleinere punten. Airbnb-langdurige kortingen worden niet beheerd via de channel manager, dus de tariefpariteit wordt daar handmatig gehandhaafd. En rapportage is export in plaats van inzicht: we hebben onze eigen analytics ontwikkeld om te leren waar boekingen wegvallen, en zo weten we dat punt één waar is. Bedankt dat je het gevraagd hebt. We vinden het product goed, daarom zijn het boekingsysteem en de API zo belangrijk voor ons.