Different teams handling different processes chose different tools on their own, so the information sat in separate silos and each team ran its process a different way. The tools named were Kanban and workflow apps that fit a single team's board but not a booking that has to move through hosting, cleaning, maintenance and finance.
From 20 to 50 properties per person on the operations team
A short-term rental manager replaced three task tools and a layer of manual re-entry with one operations system that starts working the moment a booking lands.
A short-term rental manager that grows as fast as the back office allows.
Quarto à Vista, which uses the brand Qavi, manages properties on behalf of their owners: cleaning, laundry, maintenance, check-in, pricing, distribution and seven-day guest support. The owner only sees the result.
Short-term rental property management
2020Founded, managing short-term rentals for owners
800+Properties under management, company figure, undated
60,000+Bookings, company figure, undated
96%Owner satisfaction, self-published, undated
2.5xProperties per operations personFrom 20 to 50, as reported by the client in the 2022 case. Self-reported, not audited.
3xGrowth per yearThe client's own statement in the 2022 case, describing the rate at that time.
800+Properties under management200 and more in late 2022; 800 and more is the company figure today, undated.
60,000+BookingsCompany figure today, undated. In late 2022 the client reported 6,000 and more.
75%OccupancyThe company's own published figure, undated.
96%Owner satisfactionThe company's own published figure, undated, methodology not published.
“Every time a new property came in, we felt we could not scale the way we wanted to.”
Sérgio RebouçasCo-founder and COO, Quarto à Vista
BeforeAfter
- Task boards chosen per teamWorkflows built for the booking, with a host assigned
- Someone reading a new booking in the PMS and re-entering itA webhook creates the card and assigns the responsible host
- A host noticing the booking and starting the guest conversationAn automatic first message, linked to the assigned host
- Cleaning and maintenance tracked apart from bookingsFlows linked to the bookings and properties already in Jestor
- Reports generated in one system to feed anotherPer-unit, maintenance and cleaning reports from the same base
The PMS stays as the system of bookings and channel distribution; Jestor receives from it and does not try to be it. The WhatsApp messaging service stays as the guest channel. The company's own developers stay for the pieces that need custom code.
The bottleneck is operational, not commercial
Quarto à Vista manages short-term rental properties on behalf of their owners. It was founded in 2020 and today lists cleaning, laundry, maintenance, check-in and check-out, dynamic pricing, distribution across the major booking platforms plus its own booking site, photography, an owner dashboard and seven-day guest support as the service. It reports more than 800 properties under management, 75 percent occupancy and 96 percent owner satisfaction, all self-published and undated.
In late 2022 the client reported 200 and more properties under management and 6,000 and more bookings.
The business exists because owners who handed their properties to hotel-style operators or individual managers were getting a poorer service and more headaches than they set out to remove. That is the pitch to the owner: hand it over and it works. It is also what puts pressure on the back office, because every property added brings a set of bookings, each booking brings a guest conversation, a cleaning, a possible maintenance ticket and an owner statement, and the owner only sees the result.
The bottleneck here is operational, not commercial. Demand was not the constraint; the client describes growing three times a year. The constraint was that every new property meant more people, because the work between systems was done by hand.
The booking, the one object every team works on, had no single home
The pattern behind all three problems is that each team held a partial copy of the booking, and someone was paid to keep the copies in sync.
“Every time a new property came in, we felt we could not scale the way we wanted to.”
A piece of information lived in one system, a report had to be generated from it, and that report was then fed into another system to continue what the client calls an interdisciplinary process. As properties and bookings grew, managing that manually became, in his words, very complicated.
The client wanted integrations between the several systems the operation depended on precisely so that the same number of people could run more units. Without them, headcount tracked property count.
Item by item, what did each job before and what does it now
| What did this before | What does it today |
|---|---|
| Task boards chosen per team (Trello and Pipefy in the interview; Asana in the 2022 written case) | Jestor workflows built for the booking, with a card per booking, a host assigned and the next steps attached |
| Someone reading a new booking in the PMS and re-entering it | A webhook from the PMS creates the card and assigns the responsible host |
| A host noticing the booking and starting the guest conversation | An automatic first message through the WhatsApp service, with the conversation linked to the assigned host |
| Cleaning and maintenance tracked apart from bookings | Cleaning and maintenance flows linked to the bookings and properties already in Jestor |
| Reports generated in one system to feed another | Per-unit performance, maintenance and cleaning reports pulled from the same base |
What was not replaced. The PMS stays as the system of bookings and channel distribution; Jestor receives from it and does not try to be it. The WhatsApp messaging service stays as the guest channel. The company's own developers stay for the pieces the client describes as needing real custom code, which is a smaller share of the work than before.
The chain, end to end
- 1Booking created in the PMSExternal
Through a distribution channel or the company's own site.
- 2PMS sends the booking by webhookAutomated
The event has to hold for every booking, not most of them.
- 3Card created, host assignedAutomated
Jestor maps the booking into a card with the right fields.
- 4First guest messageAutomated
Assignment triggers the WhatsApp service and links the conversation to that host.
- 5Host carries the conversationPerson
From the queue the conversation landed in.
- 6Cleaning and maintenancePerson
Opened against that booking and property in Jestor; field teams execute them.
- 7Reports from the same dataAutomated
Per-unit performance, cleaning and maintenance, available without a second copy.
- 8Internal reviewPerson
The team reviews unit and company performance in meetings from those reports.
The hard links are 2 and 4. Step 2 is the one that stopped the re-entry: it needs the PMS to emit a usable event and Jestor to map it into a card with the right fields, and it has to hold for every booking, not most of them. Step 4 is the one guests feel: assignment and message have to fire together, or the host gets a conversation with no context, or the guest gets a message with no host. Steps 6 to 8 were the second wave. Once bookings lived in Jestor, the client says the other teams brought the processes that shared booking data in from their own tools, because it was easier to work where the booking already was.
Every figure, with the basis beside it
| Indicator | Result | Where it comes from |
|---|---|---|
| Properties per operations person | 2.5x, from 20 to 50 | Client statement in the 2022 written case. Self-reported. Definition of "operations person" not specified. |
| Annual growth in properties under management | 3x per year | Client statement in the 2022 written case, describing the rate at that time. |
| Properties under management | 200 and more in late 2022; 800 and more today | 2022 figure from the client at the time; current figure from the company's own published material, undated. |
| Bookings | 6,000 and more in late 2022; 60,000 and more today | Same sources as above. Cumulative counts, not annual. |
| Owner satisfaction | 96 percent | The company's own published figure, undated, methodology not published. |
"2.5x more properties per person" is the number, not "250 percent." The 2022 written case headlines a 250 percent increase in operational efficiency. The underlying figure it cites is 20 to 50 properties per person, which is 2.5 times, or a 150 percent increase. This case uses 2.5x and the base figures. The 250 percent framing is not carried forward.
"3x per year" describes 2022. It is a growth rate the client stated then, not a rate measured since. The 200 to 800 property figures are consistent with strong growth over roughly four years, but they come from two different sources at two different times and the current one is undated, so no rate is derived from them here.
The per-person figure is an operations figure. It says nothing about cleaning or maintenance field staff, whose count scales with physical work regardless of software. What changed is the coordination layer: how many properties one person on the operations team can keep moving through bookings, guests, cleaning and maintenance without re-entering data.
What this case does not measure
Worth naming, because it is usually what gets inflated.
20 to 50 properties per person comes from the client's statement in 2022. No timesheet, headcount record or audit backs it.
The client did not report operating cost per unit before or after, so the case cannot state what a booking costs to run.
Team size is not published. Third-party directories list a range but the company has not confirmed it, so the case does not say how many people run 800 properties.
The interview and written case are from 2022. The current property and booking figures are the company's own, undated, and not tied to the 2022 measurement.
The company's owner page says 800 and more properties under management; its public booking site listed 336 available properties on the day this case was checked. These may measure different things (managed versus currently listed). The case reports both rather than choosing.
Part of what looks like efficiency is the natural scale effect of a growing operation; the case has no counterfactual.
The task tools listed did what they were built to do. They did not fit an operation whose unit of work crosses four teams.
Staffing is the constraint managers name, not technology
| Indicator | Figure | Source |
|---|---|---|
| Global short-term rental gross bookings | 219.9 billion USD in 2025, projected 270.6 billion USD by 2029 (5.3 percent CAGR) | Phocuswright, Global Short-Term Rentals 2026, reported August 2026 |
| Airbnb active listings | More than 9 million; 533 million nights and seats booked in 2025 | Airbnb Q4 2025 shareholder letter, February 2026 |
| Tools per short-term rental operator | Average of 13 integrations or tools; 88 percent of operators with 100+ listings use a dedicated cleaning or turnover tool | Hostfully Tech Stack Report, June 2026 (vendor survey of its own customers) |
| Operator workload | 73 percent run more than 50 tasks a week; 90 percent say the work needs constant coordination | Breezeway State of Work 2025, September 2025 (vendor survey, 350+ professionals, 23 countries) |
| Top barriers for property managers in 2026 | 73 percent cite staffing and revenue; 8 percent see technology as the limiting factor | Key Data 2026 Vacation Rental Industry Outlook, October 2025 (244 management companies) |
| Properties per employee | About 1 employee per 9.5 properties, excluding cleaning, plus a fixed base | Lighthouse (then Transparent), from a 2018 European vacation rental survey of 552 managers |
The 1 to 9.5 ratio is the only quantified properties-per-employee figure found, it comes from 2018, from a vendor, and it excludes cleaning. Newer vendor benchmarks name "units per employee" as the headline ratio without publishing a number. Treat it as an order of magnitude, not a target. What the client reports, 50 properties per operations person, is a narrower measure (operations coordination, not total staff) and is not comparable to it.
Thirteen tools per operator is a vendor's count of its own customers, so it is likely high for the market, but the direction is what matters: the standard response to a new problem is a new tool, and each new tool is a new place where the booking is copied. The client's starting point, a different tool per team, is the ordinary case.
Only 8 percent of managers in the Key Data outlook see technology as limiting; 73 percent name staffing. That matches what the client described: the problem was never the lack of a tool, it was that every tool needed a person to feed it.
The system is custom-built and stays our responsibility
Quarto à Vista's first years with Jestor were built around a booking flow that its own team could extend. The question that matters in year two of any custom system is who owns it when that person leaves, because a system nobody can touch becomes a spreadsheet again within three years.
One builder owns each request end to end, with one always in progress.
A new flow, a new automation or a new report enters 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 hosts, cleaning coordinators, maintenance staff, finance and management 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 in one click and the systems keep running.
Methodology and sources
The 20 to 50 properties per person figure, the 3x annual growth rate, the description of the tools used before, the booking flow and the guest messaging chain come from the video interview and the written case published in November 2022. None of it is audited. The interview transcript is machine-generated and garbles names and some terms; only what the sentence logic guarantees was reconstructed.
Property count, booking count, occupancy and owner satisfaction are the company's own published figures, checked in September 2026 and undated on the company's pages. The late-2022 property and booking counts come from press coverage at the time. Founding year from the same coverage. Titles: Sérgio Rebouças is identified as COO in the 2022 case and as co-founder in press coverage; Daniel Paiva is identified as CTO in the 2022 case and in third-party directories.
Phocuswright Global Short-Term Rentals 2026 (August 2026); Airbnb Q4 2025 shareholder letter (February 2026); Hostfully Tech Stack Report (June 2026); Breezeway State of Work 2025 (September 2025); Key Data 2026 Vacation Rental Industry Outlook (October 2025); Lighthouse scaling formula article (March 2019, based on 2018 survey data). Vendor-sourced figures are labeled as such in the table.
The 250 percent efficiency headline from the 2022 case, because the underlying figures give 2.5x (150 percent), and the case does not publish a number it cannot reconcile. Any derived annual growth rate between the 2022 and current property counts, because the current count is undated. Any statement about team size, because none is published by the company. The 2022 quotes about the client's own team building automations, because the arrangement described in this case is different.