Customize your backup code messages🚪

This is a great addition. 

The guide does not show how to turn the backup code on entirely. How would one do that? 

Can we turn off the backup codes!

There are a few unanswered questions about this (from me LOL) on this thread:

https://community.hospitable.com/hospitable-changelog-3/looking-for-a-more-affordable-way-to-screen-guests-december-19-2025-958

But this thread here is a clearer / more appropriate place for the concerns.

I’ve confirmed with my last couple bookings that the “backup code” message is being used in BOTH these situations: 

• A.) The keypad code was successfully set to the “desired” value (e.g. last 4 digits of guest phone), but the code has not yet been communicated to the guest by check-in time.
• B.) There was a technical problem attempting to set the keypad code to the “desired” value, and one of the “backup” codes needs to be used instead (i.e. one of the random backup codes that was created on the lock some time ago, to be used in situations like this).

The problem with using the SAME message template for both of these situations, is that it causes guests to receive messages that look like this, even when NOTHING has technically gone wrong:

In other words, for situation A, the default wording that’s been enabled for all Hospitable customers, is misleading and confusing for guests. And since situation A is probably much more common/prevalent than situation B, we ALL now need to edit the default/suggested text to something that makes sense in both situations (A as well as B).

I’m going with this for now:

Hi %guest_first_name%, this is a system message to re-confirm your keypad access code for check-in: %smartlock_backup_code%. This should be the last 4 digits of the phone number that was used to book your stay. If you'd like us to use a different code, let us know.

​@Kristijan Laco Can we get an update on this 

Kristijan is taking some time off over the holidays, so he’ll reply once he’s back. 💜

​@foreal dough ​@Homelike.ca You can turn those off like any other guest experience ruleset. Locate the backup ruleset in your messaging rules page and turn it off.

https://my.hospitable.com/gx/rules

 

There are a few unanswered questions about this (from me LOL) on this thread:

https://community.hospitable.com/hospitable-changelog-3/looking-for-a-more-affordable-way-to-screen-guests-december-19-2025-958

But this thread here is a clearer / more appropriate place for the concerns.

I’ve confirmed with my last couple bookings that the “backup code” message is being used in BOTH these situations: 

• A.) The keypad code was successfully set to the “desired” value (e.g. last 4 digits of guest phone), but the code has not yet been communicated to the guest by check-in time.
• B.) There was a technical problem attempting to set the keypad code to the “desired” value, and one of the “backup” codes needs to be used instead (i.e. one of the random backup codes that was created on the lock some time ago, to be used in situations like this).

The problem with using the SAME message template for both of these situations, is that it causes guests to receive messages that look like this, even when NOTHING has technically gone wrong:

In other words, for situation A, the default wording that’s been enabled for all Hospitable customers, is misleading and confusing for guests. And since situation A is probably much more common/prevalent than situation B, we ALL now need to edit the default/suggested text to something that makes sense in both situations (A as well as B).

I’m going with this for now:

Hi %guest_first_name%, this is a system message to re-confirm your keypad access code for check-in: %smartlock_backup_code%. This should be the last 4 digits of the phone number that was used to book your stay. If you'd like us to use a different code, let us know.

​@Tom Beerley good callout.

Because this is now a user-defined ruleset, the same message is currently used in both scenarios. From a guest’s perspective, we’ve generally seen that what matters most is that the code they receive works, not necessarily why it was sent.

That said, you’re right that these are two distinct situations. Scenario A (the code was set correctly but just hadn’t been shared yet) which is not more common, while scenario B (the desired code couldn’t be set and a backup code is needed) is what originally drove the default wording, since that’s the more critical failure case.

For now, we opted to keep things simple with a single message that works in both cases, even if it’s not perfect for every scenario. We’re definitely not saying this can’t be improved, having a separate ruleset or clearer distinction here is a reasonable ask. A Featurebase request would be the best next step so we can track demand and prioritize it properly.

​@Kristijan Laco thanks for confirming that the “side effects” of this feature were anticipated and intentional. So the takeaway and action item for all hosts, is that if you’re not set up to explicitly communicate the door code via Hospitable messaging (e.g. if you’ve been communicating it only via OTA arrival instructions), then you’ll want to update the wording of the “Smart lock backup code” messaging rule so that it doesn’t come across as a hardware failure.

Happy New Year!

I noticed that we cannot delete this ruleset from the message rules, ​@Kristijan Laco 

​@Kristijan Laco  and  Hospitable team, enlighten me. Why does turning off the backup code message delete all the smart lock backup codes in the system?

What is wrong with having the codes in the system? Otherwise, I have to dig into the lock every time to get a backup.

Love it!! It sounded very automated vs my normal tone!! 

​@Homelike.ca This is intentional. Until we introduce the ability to create those rulesets manually, as with other rulesets, there will be no option to delete them. Disabling them should be enough.

​@Mahmodul Backup codes are automated codes created and managed by our system. Users who choose not to use backup codes and disable the ruleset no longer need those codes to exist in Hospitable.

If backup codes are used outside of Hospitable automations, we cannot track or rotate them, which introduces a security risk. Additionally, users who requested the backup code message to be disabled generally did not want backup codes on the lock at all.

Without an active ruleset, backup codes serve no functional purpose and they only take up space on the lock. If the ruleset is re-enabled, new backup codes will be generated automatically.

​@Kristijan Laco
I understand what you said. Here’s my two cents: keeping at least one backup code provides a vital safety net for hosts. Even if the ruleset is disabled, Hospitable could still detect when that code is used and rotate it upon checkout, or other different ideas can be applied.

For those of us managing multiple properties and owners, having immediate access to a backup code is essential when a primary lock code fails. It is much more efficient to provide a pre-existing backup code (even showing the backup code on the sidebar when Hospitable detects an issue with generating codes) during an emergency than to find which lock it is and give the backup code after logging in with a two-factor code. While this may not apply to most users, it offers significant value for larger teams.