Six months of running a Maasai Mara lodge on AI-native software, by the numbers
Mara Hilltop's first six months on KaribuKit, in the system's own numbers. Bookings are counted per group, cancellations included.
Since 27 March, the lodge I started and run in the Maasai Mara, Mara Hilltop, has put 600 bookings, 311 tax invoices and 63 tour operators through KaribuKit, the hotel software we build in Kenya. In August I wrote up three bugs our own front desk caught. This is the wider picture at the six-month mark, including the parts that still don't work.
When I say AI-native I mean four rules.
- Anything a person can do on a screen, a model can do through the same system, on that person's own key. About ninety operations today.
- Every price a model says out loud comes from the rate table for real dates, never from memory.
- A person is on every send. Nothing reaches a guest without one of us.
- Every write leaves an audit trail, and the model isn't allowed round it.
The scoreboard, 27 March to 17 September
| What | Count |
|---|---|
| Bookings created | 600, counted per group |
| Arrived through the OTA sync | 204: Booking.com 148, Expedia 42, Hostelworld 5, Trip.com 2, plus 7 unlabelled. 122 of them later cancelled |
| Direct | 239, of which 73 through the booking engine on our own website |
| Through tour operators | 157, from 63 operators |
| Tax invoices issued | 311, with 16% VAT and the 2% tourism levy on every line |
| Money received | about 15% by M-Pesa, 31% by card, 17% cash, 13% bank transfer, the rest across other methods |
| Operations a model can run | about 90 |
Nobody typed a Booking.com reservation into a calendar in six months, and nobody released a cancelled one either. The 122 cancellations are what free cancellation looks like from the lodge side: guests book three places and drop two, and each drop has to give its room back the same minute or you double-sell it in high season. The one time that got awkward, an OTA booking that fit in no single room, is in the August post.
Every one of the 311 invoices was filed with KRA through eTIMS straight from the folio, with no separate accounting step, and came back carrying KRA's receipt number and signature.
WhatsApp is the channel that matters here. In July we measured every message the lodge had sent or received since March, about 19,000 across 721 chats, and the median time to a first reply was four minutes, on three people's phones. That number was already breaking when we measured it: two minutes in May, thirteen in the first week of July, when high season landed on the same three people. Since early August every WhatsApp message and every email to hello@ lands in KaribuKit's inbox, normally within five minutes, where a model reads the thread, writes a one-line summary and tags what we owe: a quote, a transfer time, a payment link, a voucher. The reply is still a person's.
The chat on the website had 190 conversations by 11 August. Its first three months produced twenty-four full quotes with dates and prices and one confirmed booking; by August a second guest had booked inside it, at least three leads it saved had become stays, and three others had sat untouched for weeks until I went looking, which was on us, not the bot. It can check real availability, quote a stay from the same rate table as the desk, and hold a room as tentative. It can't confirm, cancel or discount anything.
What the four rules look like at a front desk
The rates for all of 2027 went in one afternoon in July, through a chat window: about a hundred writes across every season and room type. I didn't approve them row by row. I told it which mistakes were cheap ("as long as it's not crazy pricing like $100 for the Lux room") and checked the result afterwards. On the way through it noticed that our most expensive three weeks, 21 December to 10 January, had no luxury-tent override at all and were quietly selling at $320 a night instead of $340. Every operation a screen offers is also available to a model on my key, with my permissions. A boring hundred-row job takes an afternoon, and the model reads every row while it's in there, which is more than I do.
The second rule came out of a failure. In August we ran the website chat against its own instructions, and in one run out of four it quoted a visitor the base rate for an October stay, $95 above the October price, even though the no-quoting rule was written into its instructions in two places. A prompt holds most of the time, and most of the time isn't good enough for money. So the rule is now structural. Every price the chat states has to come from a lookup for the exact dates in that same conversation, and the trip planner goes further: its model never sees a price at all, the pricing engine fills the numbers in afterwards. Ask for "early October" and it picks the 5th and tells you it did.
In the inbox the model reads and tags, and that is where it stops. When one of us opens a thread, an assistant drafts the reply in our voice from a playbook built out of 682 real conversations, with every price and policy pulled from the system. Then we read it and send it, or rewrite it. The warmth and the judgement calls stay with us, and the model can never promise a guest something the lodge doesn't do.
In July two groups had been created for the same party, with the one real $1,760 bank transfer on one and a duplicate cash entry keyed onto the other. I told the model, twice, to fix it from the database. It declined both times and used the reversal path, so there's a record of what moved where and the tax system isn't lied to. I'd asked it to break the fourth rule and it wouldn't, which is the point of having it. The payments module is built the same way: a payment it can't match to a folio lands in a queue that shouts until a person clears it, and nothing gets quietly dropped.
One more thing that's a decision rather than a rule. The chat on the website, the chat a booked guest gets, and the copilot in the staff app are one persona, Ranger, with the same rate table and the same limits. And the pricing engine behind the proposals module, the one that prices a multi-lodge trip from a sentence, now also runs the trip planner on marahilltop.com and on RafikiGo, the small trip company we run alongside the lodge: a day-by-day Kenya itinerary from one message, every line priced from a contracted rate or handed to a person.
The Kenya part
Most hotel software is designed somewhere else and adapted to Kenya afterwards, if at all. This is the table I'd want from any vendor. We sell the thing, so read it as a vendor's table.
| What a Kenyan lodge needs | What KaribuKit does today |
|---|---|
| A KRA-compliant invoice on every checkout | VAT and tourism levy on every line; the invoice files with KRA through eTIMS from the folio and comes back with the receipt number |
| M-Pesa as a normal way to pay | The pay-by-link page takes M-Pesa (STK push) or card, and the folio updates itself |
| Guests who book on WhatsApp | Every WhatsApp thread in the inbox, read and tagged, with the booking record beside it |
| Tour operators on contract rates, with vouchers | Each agent booking carries that operator's contracted rate on the reservation; 157 of them in six months |
| Booking.com and Expedia without double-selling | A channel sync certified by Su, our connectivity partner: Booking.com and Expedia live today, and an OTA booking that fits in no single room is flagged for a human, not refused |
| A price you can predict | One flat monthly fee, no cut of your bookings |
The last row decides more conversations than the AI does. The two shapes you'll meet elsewhere are a share of every booking, which is what HotelOnline's "pay as you go, no fixed fee" means (it bought HotelPlus and says it has 6,000 hotels), and a per-room price with a minimum room count, which is how the big imported systems sell. We charge one flat monthly fee, agreed per property, and no percentage of anything, because a lodge that has a good season shouldn't pay more for the same software.
What it doesn't do yet
It doesn't reply on WhatsApp by itself. The inbox reads, summarises and drafts, and a person sends every message. There is no voice channel. And Mara Hilltop is the only lodge live on it, on purpose: we wanted the first six months to be about running stable and steady on our own property before putting anyone else's guests on it. We're now at the point where we're happy with how it's functioning, a second lodge is onboarding, and we're looking to expand to a few more.
It has failed in ways we've written up rather than hidden. A reservation went invisible on the calendar. A folio showed $591.82 when the card held $573.10. An OTA booking arrived that fit in no single room. The booking page took eight seconds for six months because of one database setting. The inbox feed died for 41 hours in high season while the health check reported everything fine. The website chat once said "Noted!" about a request it had no way to note. That's six failures in public so far: three in the first post on this blog, two on the lodge's blog, one on our engineering blog. A vendor that can't publish its failures is asking you to take the successes on trust.
If you run a lodge or a camp in Kenya, we'll build a working copy of your booking page on KaribuKit with your own rooms and rates loaded, so you can see your property in it before you decide anything. The WhatsApp button is on karibukit.com.
As I write this, on the afternoon of 17 September, the inbox shows at least seven threads from the last twenty-four hours that we owe a reply on. The oldest is a tour operator waiting to hear that five rooms are held for October. That's the next thing I do after posting this.
— NJ