Quickly jump to a section:
Skedda allows you to set up check-in rules that:
inform users of their approaching bookings through a reminder email and a notification badge in the app,
obligate users to take an explicit confirmation step to indicate that they're still planning on honoring their booking, and
release/delete their booking if they don't.
Particularly for organizations handling large numbers of bookings, these automations effectively 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
Imagine that ABC Limited uses Skedda to manage bookings for its desks and rooms. It has 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, is swimming laps at the local pool because he 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.
Creating check-in rules in Skedda
The account owner can head to Settings => Check-in to create check-in rules.
Multiple rules can be created. For any given 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). Check-in rules can be reordered after creation (click on the heading of any given rule to move it up or down).
A typical check-in rule might look like the one below. Just read it from start to finish to understand what it does:
You can precisely control check-in behavior by customizing the rules in various ways:
User tags: You may wish to exempt some users from the requirement to check-in entirely, or you may wish to vary the check-in window for certain users. For example, perhaps users tagged with Design Team often don't know if they'll really be needing their desk until the "last minute", so they should get a more generous check-in window that allows them to check-in up to 30min after their booking's scheduled starting time. This user-varying behavior leverages Skedda's core concept of user tags.
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.
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 indeed really be removed in order to free up the space for others.
Check-in flow walkthrough
When making a booking, users will be presented with check-in information directly in the booking flow (also repeated in the booking-confirmation email). The example below shows the case where the user is making a booking before the check-in window has opened (see the auto check-in section below for the case in which it has).
Assuming that email reminders are enabled in the matching check-in rule, and that the booking wasn't auto checked-in on creation, the user will later receive a call-to-action message like the one below when check-in for their booking has opened:
At this point, the user can check in in one of three ways:
By clicking the link in the email (see above). The app will then show a confirmation message and they're done.
By using the notification badge in the app, 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:
When a booking is checked in, it appears with a green "map marker check" icon on the scheduler:
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 also generated.
If a booking is made after its check-in window has commenced (i.e. it's a relatively "short notice" booking), then it will be automatically checked in to save the user the superfluous check-in step. The user will be notified of the auto check-in when they create their booking.
Check-in activity/audit logs
Admins and owners can view check-in relevant logs via the activity feed. Two example log events are shown below. The first is a Check-In event, showing that Sally Jones checked in at 10:45am for her booking for 12:00pm. The second is a Cancel event indicating that the "Skedda Background Worker" (Skedda's 24/7 monitor that automatically releases bookings when appropriate) removed another one of Sally's bookings (for 10:00pm) at 10:15pm because she did not check in to it (in this case the check-in rule allowed check-in up until 15 minutes after the scheduled booking start time).
Detailed notes for the check-in feature
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" (all such bookings can be created by admins only).
To reduce the admin workload, the check-in feature is of course designed to be self-service (i.e. the booking holder should check in to their booking themselves). If necessary, however, a booking admin can indeed check in to a booking on behalf of the booking holder (via the booking's menu in the app), albeit subject to the same check-in window. That is, we intentionally decided not to give admins any "super powers" for checking in a booking "in advance" of the configured check-in window. The reasons for this design decision include 1) to avoid the chance that users would hassle booking admins for special treatment, 2) to respect the core problem that the check-in feature is trying to solve (i.e. requiring final confirmation of a booking "just before it begins" to avoid no-shows), and 3) to avoid admins developing bad habits (e.g. always checking in bookings by default whenever they create them). Of course, if it is desired for certain users to experience different check-in rules or be exempted from them altogether, the owner can modify the check-in rules in the settings accordingly.
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 (as well as admins of course). In the case of edits, the booking will remain checked-in after edits are made, unless the start time is "delayed/pushed back" enough to mean that the check-in window for the updated booking is yet to open. In such a case, the user would be required to check in to their updated booking again at the corresponding "check-in window opening" time. Example: Sally has a booking for 10am and is required to check in from 2hrs beforehand. Sally checks in at 8:46am. At 8:51am, Sally then edits the booking, changing the start time of the booking to 3:00pm. The booking's check-in status is reset to "not checked in" as a result, and Sally will be required to check in again from 1:00pm (she'll receive another reminder).
If a booking is open for check-in (but not yet checked in) and is edited (either by the booking holder or an admin), then it will be auto-checked in as part of the changes (again assuming that the start time isn't "delayed/pushed back" enough to mean that the check-in window for the updated booking is yet to open). The intuition in this scenario is that the process of actively editing the booking is an equally-valid indication from the user that they intend to honor their booking, so a separate/extra check-in would be superfluous.
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 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.
Changes to check-in rules (done by the owner) are put into effect immediately for all relevant bookings (not just new bookings created from that point on). For this reason, if an owner wants to make changes to a destructive check-in rule (i.e. one that has its action 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 the owner 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 for repeating/recurring bookings is fully supported and works analogously to the single booking case.
If the booking holder is also a booking admin, they still need to complete the check-in process. For example, if Jane is a 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).
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.
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 admins to delete bookings in the paid state.
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!