Wednesday, October 30, 2019

tales of two cities - green light indicates bikes are secure, part 3 (solutions)

I’ve written in this mini-series about the challenges created by the Blue Bikes method of using a green light to indicate a rental closure. I thought today I would briefly look at the current solutions and try to offer up a couple of my own.

First, I should be clear about what I’m talking about in these posts. The green light system works as designed over 99% of the time. From my experience, it’s also very reliable in a long-term sense because if you get the green light the system does… eventually… close out the rental. Trust me, it always works... eventually. The issue is that the green light itself means nothing beyond confirmation that the bike was docked correctly. There is still the added step of linking the docked bike with the open rental. The green light confirms this communication will happen... eventually. It’s kind of like putting a letter into the mailbox. The problem I’m concerned with is that when this communication remains pending for long enough, I won’t be able to unlock another bike. The current setup blames the customer until the system fixes itself, a policy that based on my experiences wastes one hour per member per year. What I’m writing about is a way to get that number down to zero.

The current ‘best solution’ is entirely electronic – when a bike docks, an email comes in that confirms the closure. This is a great solution in theory but in practice the failures become obvious. The biggest issue is that emails can be slow. I’ve had experiences where the emails for a closed trip come in hours after the fact. Given that the problem involves knowing whether the rental is closed while I’m in front of the bike, a slow email will only mean more confusion and anxiety. Another way of looking at this is if the email is one minute slow sixty times a year, the minute I spend waiting at the dock for the email will add up to that hour of wasted time I referenced above. This would defeat the whole point of my rant.

The larger problem is that the emails are system generated whereas the area of concern here is at the dock level. If a bike docked correctly but the system didn’t read it, that email is never coming in on time. This is again the essence of why I project the current system wastes an hour or so of member time per year. When the email doesn’t come in, the only solution is to call in to customer service, and once more the wasted time clock begins ticking upward.

An SMS option would fail for the same reasons outlined above for the current email method. I’ve also experienced firsthand its specific version of failure. I was in Washington DC this past June and I signed up for a one-day pass with their Blue Bikes equivalent, Capital Bike. I opted in for the SMS notification to notify me when my rental closed out. Unsurprisingly, when I closed my trip, no SMS came (I’m still waiting). If this option isn’t working correctly by late 2019, it probably never will, at least in the context of the problem I’m concerned with at the moment.

The solution I casually mentioned in my first post – a printed receipt – is probably the closest thing to the best solution. The method would be very simple – after the bike docks and the green light comes on, a printed receipt confirms the rental closure. The docks already have printers installed in the kiosk so the infrastructure is ready. This feature would be immune to problems with specific docking stations because the docks read closure independent of their connection to the system (the bike communicates to the dock and the dock communicates to the system). If a rider experienced an issue with an ‘open rental’, the receipt would be useful to have on hand until the dock linked back to the system.