The most important tool in the stack, the one connected to the booking channels, could not connect natively to the software around it. Everything after a reservation was done by hand.
A vacation rental manager went from five properties to more than three hundred in six states. The operation behind them runs on one system, after outgrowing two others.
“On other platforms, we were always missing something. They didn't have the integrations, or they didn't have a way to store and connect all the data.”

The property management system stayed. It still owns calendars, rates and channel distribution, and now pushes every new booking into Jestor by webhook. WhatsApp stayed too: still the channel guests actually answer, with messages triggered rather than typed.
Carpe Diem Homes manages vacation rentals on behalf of owners. It lists and prices the properties, distributes them across the booking channels, and runs everything that happens after a reservation: guest communication, access, cleaning, laundry, maintenance, inspections and the owner's monthly statement.
The company was founded in 2018 and is a regional leader in its market. The growth curve it published tells the story better than any description: five properties in July 2018, thirty-two in February 2019, one hundred and forty in February 2020, two hundred and fifty by May 2021, and more than thirty-five thousand guests served by that point. Roughly fifty times larger in under three years, including a competitor's portfolio acquired along the way.
That curve is the whole problem. A vacation rental manager does not earn more by charging more, because the nightly rate is set by the market and the manager takes a percentage of it. What the manager controls is the cost of running each unit: how many messages a guest needs, how fast a cleaning order goes out after checkout, whether a maintenance call reaches the right person, and how many hours of administration each new property adds.
So every property added is a small recurring operation. Add fifty and you have added fifty small recurring operations. The business either automates the handoffs or it hires proportionally, and hiring proportionally is how a manager ends up growing revenue without growing margin.
The company did not start without tooling. It started with Trello, then moved to Pipefy, and each move happened for the same reason at a larger scale.
“At the start of the company we began using Trello. Over time it stopped covering our needs, the processes got more complex, longer, with more things involved.”
“We went with another platform, Pipefy, which served us for a long time. But we reached a point where we needed things that were more specific to our business model, and we didn't have much freedom to develop inside it, to customize it to our situation. That's when we found Jestor.”
The most important tool in the stack, the one connected to the booking channels, could not connect natively to the software around it. Everything after a reservation was done by hand.
Each process had something unique about it, so each got its own software. They did not play well together.
The operations team had good ideas and neither the time nor the engineering capacity to implement them.
“On other platforms, we were always missing something. They didn't have the integrations, or they didn't have a way to store and connect all the data.”
The pattern behind all three is the same one that shows up in every operations business at this size. The tools were fine at holding information. What none of them did was carry a piece of work from one person to the next without somebody moving it.
| What did this before | What does it now |
|---|---|
| Trello, then Pipefy | One system where the process can be shaped to the business, not the other way around |
| Manual work after every booking | A booking in the property management system creates a record in Jestor by webhook |
| Guest messages typed one by one | Triggered messages: booking confirmation, checkout reminder the day before, satisfaction survey after |
| Receipts collected and reconciled later | Photograph the receipt on site, attach it to the card, and the cost lands in finance with an owner assigned |
| Maintenance reported by phone or message | A ticket opened from inside the property, with the photo attached, arrival time and resolution tracked |
| Several tools, one per process | The ones that stayed are integrated; the redundant ones were cut |
| Internal project databases | Consolidated, with the database cost that came with them removed |
What was not replaced: the property management system. It still owns calendars, pricing and channel distribution, which is exactly what it is good at. What it could not do was reach into everything that happens after a booking. Jestor took that layer and the two are connected by webhook.
Channel, dates, guest, property.
The webhook fires and the reservation exists in the operation, not just in the calendar.
Confirmation on booking, a checkout reminder the day before with the time and a note about forgotten items, a satisfaction survey after.
Concierge and building security are notified for the arrival.
Field staff open tickets from inside the property, photo attached, with arrival time and resolution on the record.
An expense photographed in the field is attached to its card and flows to the financial process with responsibility already assigned.
The two hard parts of this chain are the ones at the edges. The booking has to arrive without anyone retyping it, and the cost has to reach finance without anyone collecting receipts at the end of the month. Everything in between is easier than those two, and every manager that does this badly does it badly at exactly those two points.
| Measure | Result | Where it comes from |
|---|---|---|
| Office operations efficiency | ~35% | "Jestor became the backbone of our company processes and boosted our office operations efficiency by around 35%", reported by the founder. Self-reported and not independently audited |
| Work absorbed | About 2 roles | Two people's worth of work that the company did not have to hire for while the portfolio grew. Nobody was removed, see the limits below |
| Field expense capture | Photograph and attach | Receipts captured on a phone at the moment of spend, with the cost reaching finance already assigned to an owner |
| Software cut | Redundant tools removed | Superfluous software cut and internal project database costs reduced once processes centralized. The company did not publish a count |
| Guest touchpoints per stay | 3, automated | Booking confirmation, checkout reminder, satisfaction survey. None of them typed by a person |
On the two roles. This is the number most likely to be repeated back wrongly, so it is worth being precise. In the interview the founder first said the system had saved the company two employees, then immediately corrected himself: nobody was actually removed. The company gained enough scale that it could absorb the work and redeploy people instead of hiring. That is a better outcome than a headcount cut and a weaker one than "we fired two people", and the case says the weaker, truer version.
What the field capture actually changes. An expense photographed at the moment of spend is a different object from an expense reconstructed at month end. It arrives with a date, a property, a photograph and a responsible party attached. The work that disappears is not the photographing. It is the month-end reconstruction, which is the part that nobody can do quickly and everybody does late.
“Our favorite thing about Jestor is that it evolves as fast as we have ideas.”
Worth naming, because it is usually what gets inflated.
It is the founder's own estimate of office operations efficiency, published as a quotation. There is no methodology behind it, no before-and-after measurement, and it should be read as a direction rather than a measurement.
Nobody was removed. The company absorbed roughly two roles' worth of work while growing, and the founder corrected himself on this point during the interview. Any version of this story that says two people lost their jobs is wrong.
The written case on the Jestor blog describes the change qualitatively and quantifies nothing. Everything numeric here comes from the interview or from the company's own public disclosures.
The obvious metric for this business, what it costs to run one property for one month, was never measured before or after. Without it, the efficiency claim cannot be converted into money.
The growth curve and the property count are from the company's own disclosures around 2021 and have not been publicly updated since. They describe the period during which the system was built, not necessarily today.
| Indicator | Figure | Source |
|---|---|---|
| Vacasa's valuation at IPO | ~$4.5B | The largest centralized vacation rental manager ever built, December 2021 |
| What it sold for | Under $100M | Acquired by Casago in April 2025 at $5.02 per share, with roughly 32,000 units under management. PhocusWire, Skift |
| Units handed back to local operators | ~31,400 of 32,000 | Sold or franchised to local owners within about fifteen months, leaving roughly 600. Skift, July 2026 |
| Forecast nightly rate growth, 2026 | +1.5% | Against supply growth of 4.6% and occupancy easing about 1%. AirDNA 2026 Outlook, December 2025 |
| Average cleaning fee per turnover | $161.10 | The highest of any market. AirDNA, 2025, updated 2026 |
| Average nightly rate | $168 | Airbnb, Q4 2025 |
| Mean portfolio, surveyed managers in one large state | ~49 units | Across 175 companies that disclosed unit counts; the top five hold about 22%. Compiled from an industry association's public directory, March 2026 |
Rates are forecast to move about a point and a half while supply grows three times faster. A manager earning a percentage of the nightly rate cannot price its way to a better year, because it does not set the price and the market is not raising it.
Set the average cleaning fee against the average nightly rate and the comparison is almost one to one. That is the whole economics of the business in a single line: the money is made and lost between checkout and check-in, not at the moment of booking.
The industry built one operator to thirty-two thousand units and a four-and-a-half-billion-dollar valuation, then watched it sell for under a hundred million and get dismantled back into local franchises within fifteen months. Meanwhile the typical professional manager still runs somewhere around fifty units. Nobody has solved this with size. The remaining lever is what each unit costs to run.
One builder carries a request end to end, with one always in execution.
A new workflow, a new automation or a new report comes in through the same channel without becoming a new project.
If what was built isn't right, it gets rebuilt. Unlimited revisions inside the subscription.
Seats are never the meter, which matters when cleaners, maintenance staff, concierges and owners all touch the same operation.
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 the building in one click and the systems keep running.
The efficiency figure, the two roles absorbed, the description of the workflows and all quotations come from an interview given to Jestor and from the written case published on the Jestor blog. The efficiency figure is a founder estimate, not an audited measurement.
Founding year, portfolio size, geographic footprint and the growth curve come from Carpe Diem Homes' own public disclosures and from trade press coverage between 2021 and 2024. The portfolio figures have not been publicly updated since that period.
Airbnb Q4 2025 shareholder letter, February 2026. AirDNA 2026 Outlook Report, December 2025, and 2026 Midyear Outlook, July 2026. AirDNA cleaning fee analysis, 2025, updated 2026. PhocusWire and Skift coverage of the Vacasa acquisition and its aftermath, 2025 and 2026. Portfolio distribution compiled from an industry association's public member directory, March 2026.
No management commission percentage appears in this case. The figures that circulate for it have no published survey behind them. No derived calculation appears either: unlike some cases in this collection, nothing here is estimated from an assumption.