User Experience vs. Organizational Requirements for Volunteers

Using timestamps and logs to post-mortem a customer interaction

So I had a case come in for Pawpaw Analytics with a user complaint that they had been “bumped” from a shift. The organization admin reached out to me to check if they had made some error on their end that resulted in this “bumped” shift.

Here are the logs of the transaction in question.

message	timestamp
created HandsupInstanceMembership	Thu Feb 19 04:09 AM
created SurveyResponse	Thu Feb 19 04:09 AM
assigned to shift	Thu Feb 19 04:14 AM
assigned to shift	Thu Feb 19 04:14 AM
assigned to shift	Thu Feb 19 04:14 AM
assigned to shift	Fri May 15 09:05 PM
assigned to shift	Fri May 15 09:05 PM
unassigned from shift	Fri May 15 09:05 PM
deleted ShiftAssignment	Fri May 15 10:44 PM
deleted ShiftAssignment	Fri May 15 10:44 PM
deleted ShiftAssignment	Fri May 15 10:44 PM
deleted ShiftAssignment	Fri May 15 10:44 PM
deleted SurveyResponse	Fri May 15 10:44 PM
deleted HandsupInstanceMembership	Fri May 15 10:44 PM

So we can see a decently clear picture of the chain of events. A user completes the registration form aka SurveyResponse which initiates the assignment to an event. 5 minutes later at 4:14am they then they make their selection and assign themselves to three shifts. Now the event coordinator at this point has a specific set of rules in place regarding not just the parameters of assignment but also specific locations are opened and/or closed. This was the very first round of registrations, almost certainly a repeat volunteer getting the initial email blast. Fast forward to May 15th. This is where things get dicey. At this point in the process there are entire locations that have been fulfilled and are now closed to additional entrants. The rules setting the number of shifts, lengths, etc. have been altered. So this volunteer goes to self-manage, and ends up not being able to walk back to their initial assignments in order to pass the threshold for the current registration process. About 90 minutes after this shift change we can see the cascade as they withdraw from registration entirely.

As somebody who designed this system I have a few thoughts on the topic. Initially, I have a sigh of relief. I get paid by the hosting organization, and their rules must be inviolable. To that effect, this was a technical success of the platform enforcing strict adherence to shifting rules for a volunteer schedule. But then the spiders start creeping in. Was there fair warning that altering shifts might bump you from the selected spots? Did this user make one change and it cascaded to bump their existing slots? In the long run, this behavior may be upsetting to end users and result in frustration that gets passed up to the organization (which in this case it did).

Lo and behold - there is not a warning to the user that they might be making an irrevocable change. So a quick change to the JS to introduce a modal and boom, baby, we have two boxes checked - the Organization has their shift logic protected and incentivizes people from late stage moves from full areas and we allow volunteers to self-manage without frustration.

I can imagine outside of software logging information can be incredibly helpful for managing similar situations. Keycard logs to understand community use and flow at a recreation center, reviewing registration timing for a summer camp program, you name it.