YStay

Contact support

Where to find the assistance channel built into your host workspace, what goes to the YStay team, how the reply comes back, who on your team sees a request, and how long exchanges are kept.

YStay opens an assistance channel built directly into your host workspace: no need to look up a separate email address. The entry point is a new link at the very bottom of the main menu, next to your account name, marked with a life-buoy icon.

What a request can cover

When opening a request, a category is chosen among:

  • Access — lock, entry code, an issue opening a door.
  • Payment — payouts, billing, deposits.
  • Reservation — a specific booking.
  • Check-in / check-out — arrival, departure, key handover.
  • My account — profile, company, connections.
  • Compliance — a rule or a regulatory obligation.
  • Bug — abnormal platform behaviour (web, mobile, or TV).
  • Report — content or behaviour to flag.
  • Other — everything else.

Deleting your account is not requested through this form: it is requested from the Account page (see the Your data and your account guide).

Whatever category is chosen, a request opened from your host workspace goes to the YStay team, never to another member of your account: this channel is not an internal messaging tool.

Attaching a file

A message — when opening a request or in a reply — can carry up to five attachments, images or PDF, 8 MB each at most, via the Add a file button.

Like the rest of a request, these files are never public: they can only be reached from your authenticated workspace, never through a link open to anyone. They are erased together with the request, following the retention periods described below.

How the reply comes back

A reply from the YStay team arrives through two channels at once: a notification inside your host workspace, and an email in your account's language. Both lead back to the same request, inside the app.

If YStay is waiting on a reply from you

When the YStay team needs more information from you to move a request forward and does not receive a reply, a single reminder is sent — never more than one. If the issue has resolved itself on your side in the meantime, that reminder can be ignored with no consequence: the request is not chased a second time.

As with the first reply, no stated deadline drives this reminder: YStay does not display any time-based commitment.

If support asks you to confirm an action

To settle a request, the YStay team can prepare an action that touches your money. Such an action is never carried out without you: today, this is the case for a deposit release, which lets go of the security deposit held on a guest's card.

When support prepares one, the account owner receives an email “An action is waiting for your confirmation”, and a notification appears in your host workspace. The View the request button leads to the support page, where the Waiting for your confirmation box shows at the top of the page. Each action is listed there with its type (Deposit release), its amount and its date, and two buttons:

  • Confirm releases the deposit: the amount held on the guest's card is let go.
  • Decline changes nothing: the deposit stays held, and your refusal is recorded as such.

The box only shows when an action is waiting for you. If the deposit has meanwhile been released or captured some other way, the action disappears on its own: there is nothing left to decide. If someone on your team has already decided, the message “This action has already been settled.” is shown, and nothing is carried out a second time.

Two other support actions are carried out without waiting for your confirmation: extending your trial period, and reissuing the access code of a guest who is locked out. In that second case, a new code is sent to the guest and the old one is revoked; the YStay team never sees that code.

Who on your team sees a request

  • The owner and a manager see every request opened on the account, whoever opened it.
  • A staff member sees them too, by default.
  • Someone with read-only access only sees the requests they opened themselves.

How long exchanges are kept

The content of a resolved request is kept for 24 months after resolution, then erased: the text of the messages disappears, while the request itself stays as a trace that an exchange took place. Attachments follow the same rule as the text of the messages: they disappear along with it.

The audit trail proving who did what and when has its own retention period: 36 months. It therefore does not follow the 24-month window that applies to the content — a request can have had its text erased while the trace of how it was handled is still there.

Next up

Updated on