Hostaway

The request is written into Zenvox with the reservation, the channel and the listing. Hostaway stays in charge of the stay, and distribution channel rights do not follow from direct-booking rights.

7 days, 20 answered calls, no card

Where your guest request lands

The request is written into Zenvox: the reservation identified, the originating channel, the listing, the person, the incident or change request. Hostaway stays in charge of the stay and its calendar. Cancelling a reservation stays with you: it is not written from Zenvox, and no key handover time is announced without confirmation from the ground.

On access, the documentation describes creating and updating reservations, calendars and messages. The token is obtained from your account out of a secret you hold, and rotated on the provider lifecycle; Zenvox asks for no password. One warning from the research deserves repeating: distribution channel permissions do not follow from direct-booking permissions.

Hostaway holds listings, reservations, calendars and distribution channels; a guest calls because a message went unanswered, they already wrote on the booking channel, and cleaning is running late.

Read, create, update, cancel

The status below comes from vendor documentation and from what has not been qualified: account, channel, quotas and event behaviour.

ActionStatusWhat that means
ReadTo qualifyReservations, calendars and message threads are documented. That read is what makes an answer useful: without it, the receptionist answers against a stay that already changed.
CreateTo qualifyCreating a reservation is documented for direct booking. Rights on a distribution channel are a separate subject, to qualify account by account before any announcement.
UpdateTo qualifyUpdating is documented, but events sometimes arrive out of order and retries are limited: periodic reconciliation is required. The platform is re-read before each confirmation.
CancelZenvox native modeAn exceptional cancellation, a compensation or releasing an access code after identity verification belong to the host. The receptionist captures, passes on and alerts; she does not decide.

What is included, what needs an add-on

Answering the phone during a stay, identifying listing and reservation, capturing an incident and alerting under your rules belong to your real estate base. Cleaning and maintenance coordination, and picking a conversation back up across channels, are named add-ons.

Add-ons for working with this software

Maintenance and vendors

Cleaning, repair, status and the answer back to the guest: a stay incident is settled by a tracked assignment, not by a reassuring message.

Web and SMS conversations

The same guest often writes across several channels. History shared with the phone saves them repeating a reservation number every time.

The authorisation, and what holds the truth

Here the most important rule is not access: it is the order of operations before a confirmation.

  • The token is obtained from your account using a secret you hold; Zenvox asks for no password
  • The platform is re-read before any change is confirmed to a guest — a stay can shift during the call
  • Distribution channel rights are qualified separately from direct booking
  • Releasing an access code follows your identity verification, not caller good faith
  • A sync incident is routed to the host, and nothing is confirmed while it lasts

Half past three, arrival day. Cleaning is running late on one listing. The call is taken by Zenvox.

GuestHi, I am standing at the door and my code does not work. I already wrote on the platform.

ReceptionistLet me take your name and your reservation number, and check the exact listing address with you.

ReceptionistI am sending this to the host right now, flagged that you are on site. An access code is released after identity verification, and the host does that.

The host receives the alert with reservation, listing, originating channel and the fact the guest is at the door. Nothing was promised about a key handover time cleaning had not confirmed.

When the connection is not there

The platform stays in charge of the stay, and the receptionist works in Zenvox native mode.

  • The request is created inside Zenvox with reservation, listing and originating channel as the guest states them
  • Stay incidents raise the host alert under your rules
  • No access code is released without the identity verification you defined
  • You find the call, its transcript and its reason in the app
  • The day a write becomes qualified, it is added without redoing your setup

Questions about this connection

Can Zenvox change a reservation?

Updating is documented, and it calls for one precaution: events sometimes arrive out of order and retries are limited, so the platform is re-read before any change is confirmed to the guest. A stay can shift during the call.

Do distribution channel rights follow direct-booking rights?

No, they are two separate subjects, to qualify account by account before any announcement. Creating a reservation is documented for direct booking; the rest gets verified on its own.

Does she release the access code to the guest?

Only after the identity verification you defined, and releasing the code belongs to the host. Caller good faith is not enough.

Cleaning is running late — what gets announced?

Nothing about a key handover time cleaning has not confirmed. The host receives the alert with the reservation, the listing, the originating channel and the fact the guest is at the door.

Does Zenvox ask for my password?

No. The token is obtained from your account using a secret you hold, and it is rotated on the provider lifecycle.

Where to next

See the practice concerned, or the full list of software studied.

Hostaway

The request is written into Zenvox with the reservation, the channel and the listing. Hostaway stays in charge of the stay, and distribution channel rights do not follow from direct-booking rights.

Start your free trial7 days, 20 answered calls, no card