Webinar: Exploring Check-In Workflows in stratus-io
We recently held an informative webinar to explore the different check-in types that are available in stratus-io. The four check-in types give stratus-io its versatility and flexibility, ensuring that users are able to customize their experience to meet the needs of their event and expand their solution to additional workflows.
The webinar gives an overview of what each of the four check-in types can do, the different features of each, and some examples of how each can be utilized within an organization. It also covers the importance of individual logins when enabling location tracking and how Auto-Join can be used to simplify the check-in workflows even further. Watch the full webinar or read a transcript of the webinar below.
Welcome
Thank you for joining us for today’s webinar. My name is Jon Dugan, I’m Head of Business Development here at Serialio. Today we’re going to be exploring check-in workflows in stratus-io. I’m joined today by one of our lead Solutions Architects, Ashton Brillante. He’ll be walking us through the various check-in workflows within stratus-io.
Before we jump into that, I know some of you are familiar with Serialio, but I want to share additional background on who we are as an organization. Serialio has been in the business of specializing in workforce mobility and management solutions since early 2000.
We developed our Cloud-In-Hand framework over a decade ago for custom-made interfaces that bridge the gap between field work and back end systems. Our solutions are focused around identification, validation, and data storage. There are applications in workforce management, attendance, and inventory management.
In late 2018, we launched all of those specifications and specialities that we’ve worked for two decades on into the stratus-io complete time and attendance tool that combines the functionality and flexibility of that Cloud-in-Hand framework into an easy-to-use application.
Today, Ashton will be providing some information around best practices for check-in workflows in stratus-io. Thanks again for joining today’s call and Ashton will take it from here.
Thanks Jon. Before we get into check-in workflows, I want to briefly overview the ways that people can check someone in. We’re familiar with the smart card RFID/NFC badge readers that can be used, from our idChamp hardware line, to scan into the mobile devices for check in and check out. But, outside of smart cards/RFID badges we can also do barcode and QR code scanning, either with the Scanfob barcode/QR code scanners that we have or on the built-in scanner on Android or iOS devices that can be accessed within the app. Both platforms also have a manual check-in option, where you can use the search bar to look up a name, badge ID, or unique identifier to check someone in.
Now we’ll be talking about each of the different check-in workflows, about different use cases for each of them, and some examples.
Individual Logins
The first thing that we’re going to talk about is the importance of individual logins; what they are, why they add value, and what they allow you to do. Individual logins means a login that’s been assigned to either a specific mobile user or to a kiosk that’s deployed. These logins allow the app to track the user or kiosk that each of the scans are recorded at, which gives you the ability to do location tracking. You can filter the data by unique login, so you can track location by assigning different locations to specific logins.
Using individual logins also allows you to create events and assign that specific event to a particular login. This means that only the login assigned to the event has access and can scan people into that event. We’ll get into how that’s used in a bit.
Let’s look at an example of individual logins and what that would look like. Let’s say that we have multiple workstations, or work areas, and we create an individual login for each workstation, A, B, C, and D. When someone checks in at one of those workstations, it’s going to record if they scanned in at A, B, C, or D. This can also be used to restrict access to certain areas. For example, you could set it up so only certain people are allowed to scan in at workstation A. If someone who isn’t assigned to workstation A tries to scan in, the scan will be rejected. It will still record the scan, and will still capture data such as the name, badge ID, etc., but it will let you know in the reporting that this person scanned in but they were rejected from the workstation. You can also enable options to allow people in even if they weren’t assigned.
You can filter this data by location, so if I wanted to see all of the scans that came in through workstation A, that’s all segmented with those individual logins. This differs from having one login that covers all of the workstation because it’ll allow you to know exactly which workstation the scans came from.
Open Check-In
The first check-in type that we’re going to cover is the most basic one, Open Check-In. Open Check-In is both an event type and a menu option on Android devices. On iOS, it is currently only an event type but it will be added as a menu option in August. Because Open Check-In functions as its own event type, you can just select Open Check-In under event types in the app and start checking people in. This works really well for both mobile users and kiosk setups. It’s really easy to open the app on your mobile device, simply select Open Check-In, and start tracking.
There are certain limitations to this event type. With Open Check-In, you can’t restrict access within your roster. Open Check-In allows anyone in your roster to check-in. If you are connecting the same RFID or barcode reader to the same tablet every time, you can enable the auto-reconnect feature on the reader and the Auto-Join feature in the app, so that whenever you open stratus-io, it automatically connects to the reader and joins the Open Check-In session. This reduces the amount of selections you have to make to start scanning and speeds up the set up time.
With Open Check-In, you can really utilize the Auto-Join feature and make it much faster to scan people in and accurately collect your data. This check-in type is really useful when you want to know how many people are checking in and at what time, but you don’t need to collect information like check out time or location.
An example of this would be if we had a transportation system and we wanted to know how many people use it on a daily basis. In this case, you may not need to know who is using it, but you do need to know how many people are using it. One university uses this particular system by setting up kiosks in their tram station and collecting the scans of people boarding the tram. When they close down the tram for maintenance, the university already knows how many people use the tram and so they’re able to accurately predict the amount of alternative transportation they need to provide for students and faculty. Since they had already been collecting that data, they had a good gauge on how much alternative transportation they would need and they were able to get that information by setting up kiosks with Open Check-In.
This could also be useful for gyms, fitness classes, or worksites where you just want the check-in time and a count of who was there. In an office setting, this could be used for impromptu meetings. If a meeting comes up and you want to record who attended, but you didn’t have time to create an event ahead of time, it’s easy to open the app, go to Open Check-In, and start scanning people in.
Open Check-In/Checkout
The next check-in type is Open Check-In/Checkout. This is very similar to Open Check-In, but it tracks the second scan, or exit scan, as a “checkout” and it automatically calculates the amount of time that person was checked in for. Just like Open Check-In, it functions as its own event type and menu item on Android, so you can just select Open Check-In/Checkout and it will automatically join the event. That functionality will be on iOS next month as well. Since it’s an open event type, you can still utilize the Auto-Join feature that I mentioned previously. Just as with Open Check-In, you cannot restrict access with Open Check-In/Checkout.
A good example of how Open Check-In/Checkout can be used is as a time clock. For example, if you wanted to track employee hours, you could require employees to clock in and clock out when they enter and leave a work area. This is really useful for accurately capturing when employees arrive and leave, whether that’s for the day, lunch breaks, appointments, etc. You can really simplify payroll and hours tracking because it automatically produces a timesheet. You can also help reduce hours padding and buddy punching if you have someone manning the station people are checking in at, by matching the information on the screen when someone scans or by adding photo identification to your roster so the picture of whoever is scanning in shows up on the mobile device.
This can also be really useful for monitoring training sessions by requiring people to check in and check out, so that you’re sure that they’re not just coming in and scanning in and leaving early.
Checkpoint
The next check-in type that we’ll go over is Checkpoint (currently called Time Track on iOS). With Checkpoint you can access and check people into any public event that’s been created by admins. You can also use the Auto-Join feature for this check-in type, but only for events that have been assigned to an individual login. But, Checkpoint does allow you to restrict access to your events. When you assign roster members to events, anyone that tries to sign in that wasn’t assigned to that event will have their scan rejected. That information will be recorded and stored in your scan data. There are also options to allow people that aren’t assigned to scan into an event without being rejected, so that’s an option as well.
Checkpoint gives you more data analytics capabilities, because you can create and configure your events to have more control over the data that you collect. Administrators can search and apply filters to see which event people checked into. They can also add certain parameters to the event, like whether to track if people were late or if they were a walkup. You can also set the app to auto clock someone out after a certain interval of time.
For an example of where Checkpoint would be useful, let’s go back to Workstations A, B, C, and D. Let’s say that you work at a large facility or sports center. You’re not interested in when employee is showing up to the building, but you do want to know that employees are checking in to their assigned workstations. Checkpoint allows you to assign each of those workstations to an individual login and then use this workflow at Workstation A, B, C, and D to scan employes in and make sure they’re showing up to their correct stations.
By assigning your roster members to their corresponding workstations, you can monitor if employees show up at their assigned workstation and what time they showed up. If someone tries to check-in to a station they weren’t assigned to, you can reject that scan.
Self Check-In
The final check-in workflow is called Self Check-In (currently called Kiosk on iOS). The workflow here is a bit different than the other check-in types so it’s kind of unique. Unlike the other check-in types, after roster members have scanned their badge, they are prompted to select from a list of events created by administrators. Self Check-In gives you similar data analytics capabilities as Checkpoint, but it’s particularly useful for front desk kiosks where there are multiple event options for someone to scan and check-in to.
A good example of this would be a week long training seminar. Let’s say you have multiple sessions running simultaneously throughout the week. You need employees to attend every session, but they can attend them in the order or time preference that they want. With Self Check-In, you can create an event to correspond to each of the sessions, and put kiosks where the sessions are happening. When the attendee scans their badge, it’s going to pull up a list of those sessions, and they can check themselves into whichever one they are attending.
You can run a couple of different reports with Self Check-In. You can look at the event and see who checked into that event. You can also look at reporting based on an individual and check if they attended all of the sessions that they were required to go to.
Self Check-In is basically a reverse workflow of Checkpoint. With Checkpoint, a mobile user chooses an event and scans people in. With Self Check-in, a roster member scans in and then self selects which event they are attending. This is really useful in a kiosk type deployment.
Auto-Join
Earlier, I mentioned the Auto-Join functionality. This is available on both Android and iOS. Auto-Join is a method to reduce the amount of selections within the app so you don’t have to manage your mobile device and constantly choose the next event. This works really well with open Check-In and Open Check-In/Checkout event types, so that when you open the app it automatically joins that event type. This makes it a little less complicated because those event types are always open and always available.
With Checkpoint, because events are assigned, this gets a little bit more complicated. Let’s say that you have a university where multiple classes are held throughout the day in the same lecture hall. If your lectures are scheduled for 10 am, 12 pm, and 2 pm, the app will automatically join the 10 am lecture at 10, 12 pm lecture at noon, and the 2 pm lecture at 2 o’clock, without you have to go to the kiosk and select those events each time. Anyone that scans after the start time of each event will automatically be checked into that event. It really is meant for reducing taps and making kiosks workflows a lot more manageable.
