Reservation System for Non-Literate Workers

Community
, , ,
1

I'm not sure what category to put this in so I'm starting here. I have an idea for a workflow that would best be described as a Signup or Reservation System. I did a little searching on the forum but I think those words are too general and not sure what else to search. My context is rural West Africa mainly with non-literate workers so any fields would need audio and potentially images to explain the questions as well as at least two languages. I'm not sure ODK is the best solution, but nothing strikes me as a good tool to do this. I figured I'd throw it out there and see if anyone has done anything like this in the past.

Essentially I want to make a system where potential workers would be able to signup to work where they would see what days of the week are available to work. The first x number of people who signup to work that day would have their spot reserved and anyone else who signed up for that day wouldn't be on the official roster for that day/ideally that option would close once that limit has been reached.

Requirements

  1. This all needs to function well in areas with intermittent connectivity on low-bandwidth connections
  2. Everything required from enumerators needs to be EXTREMELY simple (No logins). Anything like Google Calendar would be overwhelming and wouldn't work.
  3. Unique ID's - Most people probably cannot type their name correctly and there are too many people with the same name anyway. Not sure what the best way to identify someone would be. Maybe concatenate a geopoint with a name/image files name? That seems like a really bad idea...

In addition, we need these non-literate workers to be able to access the official schedule which would be the source of truth for everyone. Ideally we could do this in entities, or a very basic webpage in such a way that would have a filter so that a custom URL could be made/saved to each workers phone and this would only show that individual which days they are signed up to work. I'd prefer entities as this seems more offline/internet friendly, but causes issues that I discuss below.

My main questions that I don't know how to solve are the Unique IDs (without giving each person a laminated QR Code, which is a possibility, but undesireable), designing a form that could filter out choices based on a submission count (closing a date after x number of people have signed up), as well as a basic webpage/or other way to display data back to the user.

It seems like this likely could all be done with entities but haven't used them enough to know what the ideal way to set this up would be. Also, even if it could be done with entities, it would be really important that if a user is offline that they understand they need to send their submissions in order to be signed up, which could get confusing if they fill out a form that reserves them for Y date, when that date has already been filled because they haven't connected recently/updated the entity info and others have signed up since the last time they connected. Not sure how this offline entity conflict is resolved.

This definitely all feels like new territory to me and wanted to see what people with more experience think or if they know of other tools that would be good. This is another idea where a webhook like the one made by @spwoodcock would be ideal for keeping the website up-to-date without having to run syncs constantly.

2

Hi @Tyler_Depke ,

In my experience, if you want a unique identifier in an environment that doesn’t have them, you need to create them yourself. A QR code is definitely the easiest option, with perhaps a fallback to text entry when it is not legible. We did a similar thing to create “tokens” that were redeemable for mosquito nets in a Global Fund insecticidal net distribution campaign. Note that, if you are using QR codes as proof of identity for reimbursement reasons, you will need to ensure that non-scannable QR codes are signed off by a supervisor to limit cases of erroneous data.

If QR codes are not an option, you might consider telephone numbers, if those are common enough. It sounds like that might not be the case, but that is another option to consider.

For your remaining points, it is unclear which data are required, at what level, and within what timeframe they need to be available. Should the entire reservation system run offline after the initial form download? Do the phones have to sync up once daily? Weekly? If you cannot have all the requirements, which are the easiest to compromise on versus which are hard requirements?

Sounds like an interesting project!

3

I should specify here that the form would be accessible on multiple devices and any device with this form should be able to allow any person to register for a time slot AND display confirmation they have been registered for that time slot as long as they have their uniqueID (QR or telephone number). I'd probably do a separate form for signup/adding their basic contact info and each unique ID would be an entity. Then have a separate form for the actual time slot registration. Ideally, these would be the same form (although not a dealbreaker) and I could just have the first question be something like: What do you want to do:

  1. I'm a new person that wants to register my name
  2. I want to signup for a time slot
  3. I want to confirm if I'm registered for a time slot

Because this is being done on many devices, they would all need to sync up to the source of truth (ODK Central) to confirm they have in fact been officially registered.

My main question in design is with regards to setting the limit of X number of people to register for a certain day. In my mind that date/time slot would be an entity with a property of something like "spots_available" and it would need to count down as submissions come in. I'm not sure how I would do a calculation to count submissions for that time slot in order to do this calculation. Is this possible? I guess an infinite number of people can sign up for the time slot, but only the nth person and lower gets a positive confirmation message after submission and looking at their status.

Secondly, if these are being filled out offline and then submitted, who/what submissions would get priority/registered first? Heres an example:

There are 10 slots available for next Monday and 9 have been filled already. Enumerator 1 fills out the form on Saturday morning to reserve his place on Monday, but doesn't connect to the internet/submit until Sunday night. Enumerator 2 fills out the form Sunday morning and sends it Sunday morning.

My assumption is Enumerator 2, because he actually sends his submission first, he would get the last spot. So then the question is, what happens to Enumerator 1? His form gets submitted, but my assumption is the best procedure would be to have the confirmation in another part of the form where it displays a note based on his submission place/order that says "Sorry, this time slot is already filled" or "You were the 11th person and there are only 10 places available.

It looks like quotas explained here is a similar concept, but not sure how this is handled with offline devices. Currently, entities can be updated offline if on a single device, but in my scenario where I wanted the source of truth to be the Central server to avoid entity conflicts, is there a way to FORCE a device to update its form/entity data before/after submitting so that displaying a confirmation to a user would ALWAYS be accurate and different devices would never display conflicting entity data?

With regards to syncing intervals for devices, we are currently setting up 3 days each week that people would register for, so they would need to sync up more than weekly but theoretically less than daily. Daily syncs wouldn't be a dealbreaker, but I do think that some enumerators wouldn't want to do that. I think the most important requirement here would be that as soon as someone sends their submissions, they would need an easy way to see a confirmation if they've been official registered for that time slot or not.

In my mind that would mean, enumerator sends their submissions when their device connects to the internet, at the same time their device gets the most up-to-date entity info on time slots left. Enumerator then opens the form, puts in their ID and see when/if they are registered for X time slot.

Sorry this is so long and disorganized, I'm trying to wrap my mind around this and it is making my head hurt a bit :thinking: