Set up check-in rules to request users to confirm their approaching bookings. Add a few notes that they must confirm if you'd like. If users don't check-in, you can configure Skedda to automatically delete their booking to free up the space!
Learn even more in the FAQs section!
Overview
Skedda allows you to set up check-in rules that:
Inform users of their approaching bookings through a notification badge in the app and a reminder email (optional).
Force users confirm that they're still planning on honoring their booking (optionally include further confirmation items).
Release/delete their booking if they don't check-in (optional).
These automations solve the "no-show" problem! They free up your spaces for others to use when the time would otherwise go to waste. They additionally save countless hours of manual policing work by administrators, giving you confidence about the real attendance status of bookings at any given time.
The check-in feature is included in the Skedda Premium plan. If you have an existing non-Premium Skedda account, please reach out to our team to discuss the upgrade.
Example check-in scenario
An office with reservable desks could have the following check-in rule configured:
"For all booking holders, send a reminder email to announce the opening of the booking's check-in window 1h30m beforehand, and remove the booking automatically if they don't check in until 15m beforehand."
Given this rule, imagine that Sally and David both have bookings for different desks for 09:00am. At 07:30am, they both receive a check-in reminder email. Sally is on the way to the office and checks in to her booking using the Skedda mobile app at 08:44am. Her booking is preserved. David, on the other hand took a spontaneous day off and completely forgot about his desk booking. His booking is automatically removed at 08:45am and he receives a notification. Peter (another user) is then able to self-service book the now-free desk that David doesn't need.
Create a check-in rule
Multiple rules can be created. For any user booking, the first matching rule (based on the user-tag/space filters in the rule) governs its check-in behavior. As such, check-in rules should be ordered from most specific to least specific (i.e. the last rule should generally be the "catch all" rule).
If a booking happens to be for multiple spaces, or the booking holder has multiple tags, the single first matching check-in rule is still taken from the configured list of check-in rules. That is, no more than one check-in rule is applied to any given booking.
Check-in rules can be reordered after creation (click on the heading of any given rule to move it up or down).
Customize the rules in various ways:
User tags: You may wish to exempt some users from the requirement to check-in entirely, or vary the check-in window for certain users.
Spaces: You can have different check-in rules for different spaces. For example, perhaps bookings for desks should be removed if the holder doesn't check in until 2h beforehand, whereas bookings for meeting rooms should be removed if the holder doesn't check in until just 15m beforehand.
Check-in window: Each check-in rule specifies the window of time during which the booking holder can check in. The "opening" time of the window can be as early as 24 hours before the booking's scheduled start, to as late as the instant that the booking starts. The "closing" time of the window can be any time after the "opening" time, albeit not later than 24 hours after the booking starts.
Confirmation items: Each check-in rule can have a set of statements/audits/items that must be confirmed by the user when they check-in. This is great because check-in happens shortly before the booking takes place, so it's a perfect opportunity to obtain final confirmation from the user on any important items, or even just to remind them of something. Check-in is only possible for the user once they have "ticked off" each of the confirmation items. Confirmation items that are ticked off as part of a check-in event are included for reference in the activity feed.
Action taken when the check-in window opens: You can decide whether users should be reminded by email when it's possible for them to check in to their booking.
Action taken when the check-in window closes: You can decide whether "no-shows" should just be logged to the activity feed (great for a roll-out/testing phase), or if the booking should be removed in order to free up the space.
Changes to check-in rules are put into effect immediately for all relevant bookings (not just new bookings created from that point on). For this reason, if an owner/system admin wants to make changes to a destructive check-in rule (i.e. one set to "remove booking"), then Skedda will first force the owner to set the action step back to the non-destructive "log only" option. The intention here is to help implement a "transition phase" so that imminent bookings are not unfairly removed as a result of a change to check-in rules.
If you make significant changes to a check-in rule, Skedda recommends leaving the rule in the non-destructive mode ("log only") for 48 hours before switching it back to the destructive mode ("remove booking") so that all users have time to adjust.
During testing, and as a roll-out strategy for your check-in policy, we generally recommend that you keep all check-in rules in the non-destructive "log-only" mode, then monitor the audit logs and fine-tune if required. Once you're confident that your users are comfortable with the process, you can then switch on the destructive "remove booking" mode.
Check-in flow walkthrough
When making a booking, users will be presented with check-in information directly in the new booking window (also repeated in the booking-confirmation email).
If the booking wasn't auto checked-in on creation, the user will later receive a call-to-action message when check-in for their booking has opened. At this point, the user can check-in one of three ways:
By clicking the link in the check-in email.
By using the notification badge, which will appear whenever the user has bookings that are pending check-in.
By using the check-in option in the booking's menu in the app directly.
Once a booking is checked in, the red ! icon turns into a green map marker check.
Regardless of how the user checks in, the check-in action is processed immediately if there are no confirmation items configured on the matching check-in rule. If there are confirmation items, the user will see a check-in form that requires them to complete the check-in items before being able to check in:
If the user does not check in before the end of the check-in window, the booking will be removed automatically (if the check-in rule is configured to do so). The user will then receive an email, notifying them of the booking cancellation.
Audit logs are generated throughout this process.
Auto check-in
If a booking is made after its check-in window has started (short notice booking), then it will be automatically checked in. The user will be notified of the auto check-in as they create their booking and confirmation items must be completed before the booking is made.
If a booking is open for check-in (but not yet checked in) and is edited, then it will be auto-checked in as part of the changes (assuming the start time isn't pushed out of the check-in window). If the matching check-in rule includes confirmation items, those must be completed as part of the auto check-in.
Check-in activity/audit logs
System users can view and export check-in relevant logs via the activity feed. Two example log events are shown below. The first is a Check-In event and the second is a Cancel event indicating that the Skedda Background Worker (Skedda's 24/7 monitor that automatically releases bookings when appropriate) removed a booking because Tom Tested did not check in.
If the check-in rule is configured to log an event to the activity feed and a booking is not checked in, the activity feed will show a Cancel event with the Reason stating "Simulate not checked in action" (for repeating and individual bookings).
If the check-in rule is configured to remove the booking occurrence and a booking is not checked in, the activity feed will show a Cancel event with the Reason stating "Not checked in".
If a repeating booking has an occurrence removed from the scheduler, this will show in the activity feed as an Update. Exceptions will be added to the booking to exclude the missed day and the Reason will state "Not checked in".
Managing bookings with check-in enabled
System users and bookings with check-in rules
The check-in feature is designed to be self-service (i.e. the booking holder should check in to their booking themselves). If necessary, a System user can check in to a booking on behalf of the booking holder with the same check-in window rules. We intentionally decided not to give System users any "super powers" for checking in a booking early. If certain users need different check-in rules or need to be exempted, the check-in rules can be modified in the settings.
If a System user checks in to a booking on behalf of the holder as described in the previous point above, they are also required to complete any "confirmation items" associated with the matching check-in rule. Again, this is an intentional design decision to uphold the integrity of the check-in process. By making System users complete the confirmation items on behalf of the user, Skedda is "reminding" the System user of their organization's policies and prompting them to verify those items with the booking holder, thereby reducing the chances that the booking takes place without the necessary checks.
Editing bookings with check-in rules
Assuming no other policies forbid it (e.g. a lock-in policy), a checked-in booking can still be self-service edited or cancelled by its holder or System users. In the case of edits, the booking will remain checked-in after edits are made, unless the start time is delayed enough so that the check-in window is yet to open. In this case, the user would be required to check in to their updated booking again (including the resubmission of any confirmation items) at the check-in window opening time.
FAQs
What does the check-in email look like?
Check-in notifications are being sent at the wrong time
Double-check that your venue's time zone is set correctly (in Settings => Basics), otherwise your check-in windows and their associated events (check-in notifications and automated booking removals) may not correspond to your local wall-clock times!
Do System users need to check-in?
Yes! If the booking holder is also a System user, they still need to complete the check-in process. For example, if Jane is a System user (ex. Booking Admin) on Skedda but also needs to use Skedda to book her own desk, then she too will need to complete check-in unless the configured check-in rules exempt her (such an exemption could be based on a custom "Check-in exempt" tag or similar, for example).
Does check-in work for repeating bookings?
Yes! Check-in for repeat bookings is fully supported and works analogously to the single booking case.
Does check-in work for paid bookings?
If a booking happens to be priced and is marked paid, then it will not be auto-removed even if the matching check-in rule would otherwise do so. The reasoning for this is the same as the reason for not allowing System users to delete bookings in the paid state.
Do anonymous / Casual user bookings need to be checked-in?
Check-in is only applicable for bookings with a user. This means that check-in is not relevant for Internal/Unavailable-type bookings or bookings for the "Casual user".
Can I set up the check-in window to close after the booking ends?
Although we generally wouldn't recommend it, it is possible to set the check-in window to end well after the booking's start time. For example, you can choose the check-in window's "closing" time to be 24 hours after the booking's scheduled start. With such a rule, any booking with a duration of less than 24 hours will end before its check-in window does. In this situation, the "action" step for the no-show case is triggered aggressively at the booking's end time, not the check-in window end time.
How do the check-in links work?
Check-in links that are sent as part of the check-in reminder emails are unique, secure, unpredictable, and will of course only succeed during the booking's check-in window (otherwise an informative error is shown). Users do not need to be logged into Skedda in order to follow a link and check in.