Every process involved a third party: guest, owner, front desk, supplier. Team members could lose hours a day typing messages, one at a time, with the same content.
The reservation now starts the work
A short-term rental manager replaced hand-typed messages to guests, owners and suppliers, an operation run partly offline, and stock counts that were regularly wrong with a system where a booking in the PMS creates the record, and the record drives check-in, cleaning, laundry, maintenance and owner payout.
This is one of Jestor's earlier cases. It was recorded in July 2022. The company's portfolio and processes have changed since. Whether the system described here runs unchanged today is not known to us. Everything below describes the operation as it was at the time of the case.
A short-term rental manager whose promise is that the owner does not have to think about it.
Be My Guest takes the property, lists it, handles guests, cleaning, linen, maintenance and the monthly payout. Short-term rental is a hotel operation without a hotel.
Short-term rental management
STRManages apartments and houses for owners
PMSBookings stay in the PMS; one webhook feeds the operation
3 pmCalendars stay open for same-day booking
2022Year the case was recorded
15h/weekTime the founder says was saved, early in adoption, on message and platform communication automations aloneFounder, in the recorded interview; his own estimate, no method stated.
5% to 10%Share of bookings that are now last-minute, a product the company did not offer before because it could not release same-day inventory safelyFounder, in the recorded interview; self-reported, no period stated.
3 pmTime of day until which every apartment's calendar now stays open for same-day bookingFounder, in the recorded interview.
1Webhook that connects the PMS to the operationThe published case's description of the integration.
“We didn't have that control, and today we have it in real time. I'm at home, I need to know whether the office has enough linen to cover today's bookings, and I can see it. I can act before the problem reaches the guest: the laundry is late, or we forgot to send a cleaner. With Jestor we don't have that error any more.”
Iuri BarbosaFounder and CEO, in the recorded interview
BeforeAfter
- Extracting each reservation from the PMS by handA webhook creates the reservation record with check-in and check-out dates
- Typing guest, owner and supplier messagesButtons and automations send template messages through the right channel
- Assembling condominium access requests from guest detailsThe guest fills a form; it links to the reservation; one button sends the request
- Asking whether an apartment is readyThe cleaning order, opened by the cleaner on a phone, carries the inspection form; status is on the record
- Inspection notes passed by messageThe inspection form is reviewed by the internal team on the record before the owner payout is prepared
- Linen counted by hand, often wrongPicking writes stock out, collection orders are generated, the laundry order is compared with what returns
- Maintenance and complaints handled ad hocTickets from guests and owners, with an operational ticket opened by the customer team to execute
- Calendar closed early to protect the operationCalendar open until 3 pm for same-day bookings
What was not replaced. The PMS still owns bookings and payments. The booking channels still own the calendar. The form tool stayed for guest data. The laundry, the cleaners and the front desks stayed as external parties; what changed is that they receive generated orders instead of typed messages. Weekly KPIs the founder says cannot yet be pulled automatically are still entered by form once a week into the dashboard.
The bottleneck was operational, not commercial
Be My Guest manages apartments and houses for short-term rental on behalf of owners who do not have the time or the wish to manage them, and want the asset to earn. The company takes the property, lists it, handles guests, cleaning, linen, maintenance and the monthly payout to the owner. Its promise is that the owner does not have to think about it, which means the company has to run every hand-off without error.
Short-term rental is a hotel operation without a hotel. Each check-out triggers a cleaning, an inspection, a linen change and possibly a repair, in a building the company does not control, with a front desk that needs the guest's name in advance. Each check-in needs the apartment ready, the linen delivered and the access cleared. The number of apartments multiplies every one of these, and the calendar decides when they happen.
That is why the bottleneck was operational and not commercial. Bookings came through the PMS and the channels. What the company lacked was a way for a booking to set the work in motion, and a way to see whether the work was on track without asking. The founder's test was simple: from home, can I tell whether the office has enough linen for today's bookings?
The physical work was continuous and the information was on request
“We didn't have that control, and today we have it in real time. I'm at home, I need to know whether the office has enough linen to cover today's bookings, and I can see it. I can act before the problem reaches the guest: the laundry is late, or we forgot to send a cleaner. With Jestor we don't have that error any more.”
Because processes ran by hand, information had to be reported or fetched. Whether apartments were ready, whether linen was enough, whether the laundry would deliver on time: none of it was visible, so planning ahead was guesswork.
Cleaning, inspection and linen handling happened with little recorded and nothing to start the next step. A finished cleaning did not tell anyone it was finished.
Without a defined process for releasing an apartment on the day, the company could not safely sell last-minute bookings. The calendar closed early to protect the operation.
The pattern: the physical work was continuous and the information was on request. Nothing was broken; the company was growing. But every apartment added meant more messages, more asking, more chances that a cleaner was forgotten or a towel count was wrong, and the owner's promise depends on none of that happening.
Item by item, what did each job before and what does it today
| What did this before | What does it today |
|---|---|
| Extracting each reservation from the PMS by hand | A webhook creates the reservation record with check-in and check-out dates |
| Typing guest, owner and supplier messages | Buttons and automations send template messages through the right channel |
| Assembling condominium access requests from guest details | The guest fills a form; it links to the reservation; one button sends the request |
| Asking whether an apartment is ready | The cleaning order, opened by the cleaner on a phone, carries the inspection form; status is on the record |
| Inspection notes passed by message | The inspection form is reviewed by the internal team on the record before the owner payout is prepared |
| Linen counted by hand, often wrong | Picking writes stock out, collection orders are generated, the laundry order is compared with what returns |
| Maintenance and complaints handled ad hoc | Tickets from guests and owners, with an operational ticket opened by the customer team to execute |
| Calendar closed early to protect the operation | Calendar open until 3 pm for same-day bookings |
What was not replaced. The PMS still owns bookings and payments. The booking channels still own the calendar. The form tool stayed for guest data. The laundry, the cleaners and the front desks stayed as external parties; what changed is that they receive generated orders instead of typed messages. Weekly KPIs the founder says cannot yet be pulled automatically are still entered by form once a week into the dashboard.
The chain, end to end, for one stay
- 1A reservation is made on a channel and lands in the PMSExternal
Bookings and payments stay there.
- 2The webhook creates the reservation record; onboarding routines run according to how close check-in isAutomated
The record moves through new, confirmed, checking in today, staying, checking out.
- 3The guest fills the check-in form with names, documents and arrival time; it links to the reservationExternal
The form tool stayed because it makes good forms.
- 4The team presses the button that sends the access request to the condominium or ownerPerson
From data the guest already filled in.
- 5On check-out day, the cleaning order for that apartment is created and appears in the cleaner's appAutomated
The next person does not have to be told the apartment is leaving.
- 6The cleaner cleans, fills the inspection form and marks the type of cleaning; linen picking writes items out of stock and a collection order is generatedPerson
A form inside the order the cleaner already opened, and a cart-style picking screen on a tablet.
- 7The internal team reviews the inspection; anything found becomes a maintenance ticket; the record moves to owner payout, where the company's share and the owner's share are computedPerson reviews, system moves
A person reviews; the system moves the record on.
- 8The laundry collects and returns; the returned count is compared with the sent countExternal, then automatic
The comparison is the system; the count is still a person.
The hard links are 6 and 8. The system cannot know the apartment is clean or the towels came back; a cleaner has to fill the form and someone has to count. The design accepts that and makes each of those the smallest possible action: a form inside the order the cleaner already opened, a cart-style picking screen on a tablet, a returned-versus-sent comparison the system does. Everything automatic in the chain depends on those field steps staying easy enough to be done every time.
“Lack of proper software led to recurring headaches. It was not uncommon for us to have inventory counting problems, and other similar issues. With Jestor, we know we have the correct numbers and don't get short handed.”
Every change, with the basis beside it
| Indicator | Result | Where it comes from |
|---|---|---|
| Time on communication | About 15 hours a week saved on message automations, by the founder's estimate, early in adoption | Recorded interview; self-reported, no method |
| Last-minute bookings | A product that did not exist before; now 5% to 10% of bookings, with calendars open until 3 pm same day | Recorded interview; self-reported, no period |
| Visibility | From asking or being told to seeing linen, cleanings and check-ins in real time, from anywhere | Recorded interview and published case |
| Linen accuracy | From counts that did not match to sent-versus-returned comparison on every laundry order | Published case and recorded interview; no error rate before or after |
| Reservation intake | From extracting each booking from the PMS by hand to automatic record creation | Published case |
The headline "10% more revenue" is not adopted as stated. The published case says last-minute bookings lifted reservation revenue by 10%. In the recorded interview the founder says last-minute bookings are 5% to 10% of bookings. A share of bookings is not a revenue lift, and the case's figure is the top of the founder's range. This write-up reports what the founder said: last-minute bookings are a new product enabled by the operation, and they are 5% to 10% of bookings.
The 15 hours is the founder's early estimate. He gives it as what was visible "right at the start" from communication automations alone. No method, no baseline and no later measurement are given.
"Real time" means recorded at the moment by the person in the field. Linen is as current as the last picking; cleaning status is as current as the last form. The founder himself says errors still sometimes happen; what changed is that the process can be adjusted when they do.
Not every indicator is automatic. The published case says KPIs take no time to calculate. In the interview the founder says some weekly numbers cannot be pulled automatically and are entered by form. Both are true of different indicators; the interview is the more specific source.
What this case does not measure
Worth naming, because it is usually what gets inflated.
All descriptions and both quotes come from the founder, in the published case and in a recorded interview. No process was independently observed or timed.
Apartments under management, bookings per month, cleaning cost, linen loss rate before and after, revenue: none appear in either source. The two quantified claims are self-reported estimates.
The published case gives "10% revenue"; the interview gives "5% to 10% of bookings". The case says KPIs are instant; the interview says some are entered weekly by form. In both places this write-up follows the interview, as the founder's own words.
The case was published in July 2022 and the interview is from the same period. The company's portfolio and processes have changed since. Whether the system described here runs unchanged today is not known to us.
Several passages were reconstructed from context. Where the wording was uncertain, the claim was left out rather than guessed.
Neither source states the number of properties, team size or revenue. This write-up does not estimate them.
Every booking is a turnover
| Indicator | Number | Source |
|---|---|---|
| Nights and seats booked on the largest short-term rental platform, 2025 | 533 million, up 8% | Airbnb, Form 10-K for 2025 |
| Gross booking value on that platform, 2025 | USD 91.3 billion, up 12% | Same filing |
| Fastest-growing region by nights booked, 2025 | Latin America, up 18% in nights and 20% in booking value | Same filing |
| Average nights per booking, 2025 | 3.7 globally; 3.6 in Latin America | Same filing |
At 3.7 nights per stay, a fully booked apartment turns over roughly eight times a month, and each turnover is a cleaning, an inspection, a linen change and an access request. The operational load of short-term rental scales with bookings, not with properties, which is why a manager's costs rise fastest exactly when demand is best.
Latin America's bookings on the largest platform grew at more than twice the global rate in 2025. Growth of that kind arrives as more turnovers per week for the same team, and the process that ran on messages at last year's volume breaks at this year's.
One company's filing is the cleanest data available, and it is used here for that reason. It covers one platform in a market with several, and none of its figures describe a manager's operating cost. A manager's own turnover count is the number to plan on.
The system is built to fit, and responsibility for it stays with us
Be My Guest did not lack software. It had a PMS for bookings and payments, and the PMS did its job. What no off-the-shelf product covered was the part after the booking: the cleaning, the linen, the front desk, the payout, each done the company's own way. The question a bespoke system has to answer is what happens in year two: an operations system nobody can change becomes the new spreadsheet in three years, with a login.
One builder owns each request from start to finish, and one is always in execution.
A new flow, a new automation or a new report comes in through the same channel, without becoming a new project.
If what was built is not right, it is rebuilt. Unlimited revisions within the subscription.
Seats are never the billing unit, which matters when office staff, cleaners, inspectors and the customer team all touch the same records.
People learn to use their app the way they learn any app, by opening it. Building, configuring and maintaining stays on our side.
Full export at any time, by CSV and API. SOC 2 compliant, no exit fee. Pause in one click and the systems keep running.
Methodology and sources
The before-and-after descriptions and both quotes come from two sources: the case study Jestor published in July 2022, and a recorded interview with the founder from the same period, used through its machine-generated transcript. Where the two disagree, the interview is followed. Both are the founder's own account and were not audited. The founder's quote in the published case about creating what he designs without code was not used, because it describes a working model Jestor no longer offers.
The company's business model from the published case and the company's own site. No independent figure on company size was found.
Airbnb, Inc., Form 10-K for the year ended December 31, 2025, filed with the SEC.
The "10% revenue" headline is replaced by the founder's own "5% to 10% of bookings". The 15 hours is labelled as an early estimate. No property count, booking volume or cost figure is given, because none exists in the sources.