keychain, key, wooden shelf, car key, keychain, car key, car key, car key, car key, car key. Short-term rental software: what to check and track
Photo by Pezibear on Pixabay

Guides

Short-term rental software: what to check and track

Short-term rental software should be judged first on availability sync, not features. Here are the six functions to check and the four KPIs worth tracking.

Short-term rental software is bought for one reason: keeping every channel in agreement about the same nights. Judge it on that first, then on the few numbers that change what you do.

What to take away

  • Availability sync is the only function in this category that can put two guests in one property on the same night. Test it before you read any feature list.
  • Ask every vendor three questionshow a change reaches each channel, what happens when a push fails, and how you would learn today that a connection died on Tuesday.
  • Six functions belong in the software. Two of them, sync and the fault log, are where the money sits, and both demo badly.
  • Write the turnover standard, fault classes, capacity rule and spending limits before you buy. Software enforces a process; it does not invent one.
  • Running any booking tool means holding guest identity data, owner money and door codes. That is an obligation at any size.

Availability sync is the whole risk

You list one property on several channels. Each channel has to believe the same thing about the same nights at the same moment.

Those channels are usually Airbnb, Vrbo and Booking.com, and each one keeps its own calendar.

Booking propagation gap

  1. Booking lands on one channel
  2. Gap before other channels learn
  3. If gap too long: double booking
  4. Shorten gap: risk shrinks
  5. If push fails: alert human

Between a booking landing on one channel and the others learning about it there is a gap. Shorten the gap and the risk shrinks. Leave it and two guests eventually hold the same weekend.

So the first question about any tool is not what it does. It is how fast a change propagates, what happens when a push fails, and whether a human is told.

A tool that fails loudly beats a richer tool that fails quietly. The quiet failure surfaces three weeks later as a double booking on your best weekend.

The six functions, and what goes wrong in each

FunctionWhat it doesCost of doing it badly
Availability syncKeeps one truth across every channelTwo guests, one property, peak weekend
Turn schedulingAssigns the work and shows collisions earlyThree check-outs, one cleaner
Guest messagingKeeps handling consistent and on recordDisputes with no evidence
Task and fault logGives every fault an owner and a dateGuests find faults before you do
Owner reportingThe report that keeps a property under managementLate reports, which is how accounts leave
Financial recordsThe numbers your pricing rests onA season priced on untested guesses

Buying decisions usually land on guest messaging and owner reporting, because those demo well in a sales call. Sync and the fault log are where the money actually sits.

Six functions: cost of failure

Function

Availability sync
Two guests, one property, peak weekend
Turn scheduling
Three check-outs, one cleaner
Guest messaging
Disputes with no evidence
Task and fault log
Guests find faults before you do
Owner reporting
Late reports, accounts leave
Financial records
Season priced on untested guesses

Cost of doing it badly

Availability sync
Turn scheduling
Guest messaging
Task and fault log
Owner reporting
Financial records

Owner reporting is also a growth asset, not just an administrative one, as the marketing and growth guide sets out.

Write the process before you buy the tool

Software enforces a process. Where none exists it enforces whatever people already do, faster and with better records.

Write process before buying

  1. Write the turnover standard
  2. Write the fault classes
  3. Write the capacity rule
  4. Write who may spend what
  5. Then buy software to carry them

Operators who buy first describe the same scene. A half-configured tool, two people using different parts of it, and a paper list still running the real work. The standard itself is covered in the operations and workflow guide, and teaching it is a separate job handled in the hiring and training guide.

Reading a propagation failure

Propagation failures are normal. Every channel connection breaks eventually, through an expired credential, a channel-side change, or a rate push that half-applies.

Write the recovery procedure before you need it. The version invented at 11pm on a Friday is slower and worse than the one written on a Tuesday.

Propagation failure recovery

  • Confirm which channels still agree
  • Freeze new bookings on affected listing
  • Contact guests holding conflicting nights
  • Log what happened and how long
  • Check whether failure was silent

Then check the thing most operators skip: whether the failure was silent. A connection that broke without an alert will break again the same way.

The four measurements worth keeping

Four numbers change what you do. Everything else is decoration.

Four measurements worth keeping

  • Turns completed inside windowcapacity measure
  • Faults found by inspectionshare of all faults
  • Contribution per available nightper property
  • Owner reports sent on promised dayshare due

Turns completed inside the window, as a share of turns attempted. This is your capacity measure, and when it falls nothing else matters until it recovers.

Faults found by inspection, as a share of all faults found. The rest were found by guests, and each of those costs several times more. That ratio predicts your repair bill better than any rate card, the argument in the repairs and maintenance guide.

Contribution per available night, per property. Not occupancy, which you can buy with rate, and not revenue, which says nothing about what it cost to earn. The derivation sits in the pricing and profit guide.

Owner reports sent on the promised day, as a share due. It reads as clerical. It is the strongest single predictor of whether a property is still with you next year.

Each one has a decision attached. A number with no decision behind it trains people to ignore the dashboard.

What to leave off the screen

Total bookings, total revenue, average nightly rate and review score.

All four are easy to produce, all four move for reasons unrelated to whether the work paid, and all four crowd out the four above. Keep them if you want. Do not act on them, and do not put them on the same screen, because the eye goes to the familiar number first.

Average nightly rate misleads most. It rises whenever you drop your cheapest nights and falls whenever you fill them profitably.

The data you are now holding

Once software is running you hold guest names and contact details, payment information handled by a third party on your behalf, access codes for buildings you may not own, and money belonging to owners.

That is a security obligation however small the business is. The National Institute of Standards and Technology publishes quick-start guides for small business cybersecurity, and the Cybersecurity and Infrastructure Security Agency keeps material aimed at small and medium businesses. Both are short, free, and written for companies with no technical staff.

Four habits cover most of it. Individual accounts instead of a shared login. Access removed the day someone leaves, including codes and vendor credentials. Backups that have been restored once, not backups that exist. And a written note of what data you hold and where, so a question about it has an answer.

Testing a backup takes minutes. Finding out it never worked takes a year of records with it, including the records behind your position in the licensing and compliance guide.

Records that serve two purposes

The per-stay record that produces your four measurements is broadly the record a business is expected to keep anyway. The Internal Revenue Service sets out what records a business should hold. One good file beats two half-kept ones.

Record per stay: channel, rate achieved net of fees, nights, and turnover cost including travel. Also record faults found and by whom, plus any refund or remedy given. Every number in this article comes out of those seven fields.

What software cannot fix

Two things, and both get blamed on the tooling.

Properties too far apart. No scheduler shortens a drive. Route density is decided when you acquire properties, not when you assign turns.

Claims that are not true. If a listing promises an amenity that stopped working, no system corrects it. Someone has to test it on every turn and someone has to change the description. What you publish has to be supportable, the standard in the Federal Trade Commission's advertising guidance for small businesses.

Common questions

When do I actually need software?

The first time two calendars disagree, or the first time a turn is missed because nobody knew about it. Before that, one authoritative calendar and a written standard will teach you what to buy.

Should I pick one system or several tools?

Fewer connections mean fewer silent failures. Where you do connect two things, add a daily check that they still agree.

How many numbers should I track?

Four, acted on, beats twenty watched. Add a fifth only when you can name the decision it triggers.

What if my team will not use it?

Usually the process was never written down, so the software is asking people to follow something that does not exist. Fix that first.

More in Guides

Latest from Trade Desk