Two big things first, then the rest. I am being blunt because it is more useful to you than being polite. 1. Let us design the booking engine, or let us build our own on top of yours. The engine is our single weakest point of conversion, and I can see it in our analytics: people arrive on our landing page, read about the houses, explore several pages, enter their dates, get handed to the Little Hotelier engine and leave. The exit rate there is the highest on the whole journey, and it is down to how little we can change. Choosing colors is not customization. One example we get asked about every week: a one-bedroom house shows a person icon with "4", when the truth is two adults, one child and one infant. That icon creates confusion and emails, and we cannot edit it or explain it. What we need is either real design control, meaning custom HTML, CSS and code injection on the engine, or better still a headless booking API (search, quote, hold, book, pay) so we can build our own front end that feeds straight into Little Hotelier. Right now the design is mediocre enough that it makes properties like ours think about moving to another system so the leads we already worked hard for become bookings. 2. The API is not enough. Pulling live availability and rates is where it stops. There is no way to write a rate or a restriction, no webhooks when a booking lands, no iCal export and no reservations feed, and your terms forbid scraping, so there is no sanctioned way for an operator's own tools to act on the account. We built a script that polls your API every thirty minutes just to show live availability on our website, and every rate change still has to be clicked through the web UI by hand. My team works mostly through AI, Claude in particular, and so do most small operators now. We have moved fast by having AI build the systems that connect our PMS and POS, and Little Hotelier is the part that cannot be connected. A proper read and write API, webhooks and an official integration for AI assistants would let operators like me run the property far more efficiently, and it would make you the obvious choice for the customers you are actually selling to. 3. Virtual rooms. Selling several rooms as one unit, or one unit as several, is essential for a property like ours and Cloudbeds has done it for years. I was surprised to find it missing. 4. Closed rate plans show as "Sold out". When I stop-sell a discounted plan on certain dates, guests see that plan listed as "Sold out" beside the standard rate on the same house, so it looks like something is unavailable when nothing is. A plan that is closed for the dates searched should simply not appear. Related: there is no rule for "this rate plan does not apply to stays touching these dates", so the only tool is stop sell, channel by channel. The engine machine-translates our house names. When a guest's browser is set to Thai, "White House" becomes ทำเนียบขาว, the American president's residence, "Turquoise" becomes the color, and one of our translated descriptions has a fragment of Japanese in the middle of a Thai sentence. Proper names should never be auto-translated, and we need to review or override translations per language. 1. Bulk rate updates overwrite silently. The last rate saved on a date wins, so saving a base rate across a range wipes the weekend and festive overrides already sitting on those dates. There is no preview of what will change, no undo and no audit trail of rate changes. We now work in a strict three-round order to avoid destroying our own pricing, which no operator should have to learn the hard way. 2. Labels we cannot control. Every rate in the engine says "30% deposit required" because of a settings toggle, whether or not a payment gateway is connected, and there is no way to edit or hide it. Same family as the occupancy icon: the engine tells guests things we did not say. 3. Security is overdone for the people who use it every day. Constant logouts, forced password changes every few months, the same again on the app. Trusted devices, passkeys or longer sessions on known devices would keep the security without the daily friction. Frustrating, though not as costly as the points above. Two smaller ones. Airbnb length-of-stay discounts are not managed through the channel manager, so rate parity there is maintained by hand. And reporting is exports rather than insight: we ended up doing our own analytics to learn where bookings drop off, which is how we know point one is true. Thank you for asking. We like the product, which is why the booking engine and the API matter so much to us.