Continuing from the first part; this topic briefly explores some of the fundamental considerations in building an IoT button type of a solution that enhances the overall drive-thru experience for consumers
Drive-thru IoT button concept
There are a multitude of IoT solutions (devices, platforms, ecosystems) that QSR brands could explore in enhancing CX, optimizing their operations and growing their bottom lines; each presenting their own unique benefits & challenges
As introduced in Part 1; an IoT button type of drive-thru solution is one such solution that has the potential to translate the traditional ordering process down to just a simple click (simplicity) whilst also allowing customers to bypass long queues (save time) and even offer relevant personalized offers (customer engagement)
Quick Note: Despite certain similarities inherent to the broader industry; each QSR business is unique; defined by a multitude of factors (geography of operation, food/drinks menu diversity, technological capabilities, industry partnerships, et al.) and as such would have distinct goals in building related digital & IoT solutions that aptly supports their individual long term operational, ROI & CX goals
Key considerations in building an IoT button solution
Lets say that in this instance the primary role of the IoT button is to act as a companion device (extension of a more complex smartphone app) that focuses on enabling quick ordering & pickup experience within a vehicle
As with any product development, there are some some fundamental considerations in developing an IoT button solution; particularly if the goal is to maximize consumer engagement with the device, the overall solution as well as the QSR brand
IoT button powered drive-thru solution would vary depending on a myriad of factors such as implementation scenario, technological capabilities, local regulations, user behavior & HCD principles, et al. and at the very least..
…the standalone device itself should allow for a distraction-free operation, built to be robust enough to handle the everyday ‘bumps & pushes’ of an in-vehicle operation and importantly feature an intuitive UI
1. Distraction-free operation
As far as in-vehicle user interactions go; pushing a physical button (within easy reach) is usually considered to be intuitive & even safer as opposed to fumbling around with a touchscreen type of solution (particularly smartphones)
Ergo one of the key considerations in building an IoT button device should center around minimal user interaction i.e. distraction-free operation; particularly if the device is primarily intended (& marketed) for use in a moving vehicle
2. Robust & reliable
Another key design consideration of an IoT button should take into consideration its sustained use in an in-vehicle environment (bumps, drops, road vibrations, et al.)…
… and as such the device should be robust & reliable inside & out encompassing robust outer casing as well as reliable operational components such as its battery (e.g. battery life, recharge cycles, et al.), connectivity modules (eSIM, et al.) biometric (fingerprint readers) & NFC modules, display, etc.
3. Intuitive UI
To maximize user engagement with the overall solution, the minimalist IoT button would need to be complemented with an intuitive UI (particularly on-device)…
…that ensures no more than a few clicks (read: user input / device interaction) are needed throughout the end-2-end (from placing an order to drive-thru pickup) customer journey [discussed in Part 3]
This would require the UI on the actual IoT button to be intuitive enough to facilitate simple one-button transactions as well as simplified view of key notifications…
…whilst relegating more complex tasks (think: user preferences input) such as assigning the button to a favorite/frequently ordered menu items, entering preferred payment method, etc. to the associated full featured smartphone app or customer web portal
For example, the IoT button could also be designed to house a built-in biometric (fingerprint reader) & NFC modules that simplify & secure sensitive (on-device) operations such as individual user authentication & m-payment transactions
Why not voice assistants as an interface?
Since its first mass market launch in the guise of smartphone assistants; voice user interface (VUI) has rapidly been emerging as a promising human-2-device (handsfree) interaction medium…
…with each of the prominent smart voice assistant platforms – Apple Siri, Amazon Alexa, Google Assistant – seeing varying degree of adoption & success across a plethora of device types (smartphones, smart speakers, TV, in-vehicle infotainment, et al.)
So rather than developing a (completely new) physical companion IoT button why not leverage these existing VUI technologies?
Whilst there is no doubt that all three VUI platforms are seeing rapid advancements in their underlying technologies, solution delivery and even end user experience….
…there are still a few challenges in implementing a VUI only solution as opposed to a physical IoT button (or even hybrid with voice) type of a solution; at least for the purposes of enhancing fast food pre-orders & drive-thru experience… namely –
1. Response lag & lingual complexities
Current crop of consumer-grade VUI assistants continue to largely rely on remote cloud computing for advanced voice processing (acoustic & language modeling, solution retrieval, etc.) –> necessitating a reliable & always-on network connectivity –> and when used predominantly in a moving vehicle could contribute to response lags
From the end user’s perspective the VUI’s relatively longer response time (invoking VUI wake command –> placing voice order –> remote cloud processing & authentication –> device repeating order for confirmation –> IF erroneous THEN repeat) making it hardly conducive to a pleasant experience… at least in comparison to simply pushing a pre-programmed IoT button
And then there is also the complex task of teaching the underlying VUI platform to learn & near instantly respond to wide variety of languages, accents & phonics (read: lingual processing complexities) required to further minimize potential errors & response lag
So; when the user invokes “Hey burger… order my meal” only to be translated by the device as “Hey burger… order my mail” OR “Hey burger… order my meat” after say 15-30 seconds of wait time… not only is their appetite gone but so is the user engagement
2. User authentication
Whilst existing consumer grade VUI assistants are iteratively getting better at accurately identifying individual voice prints, it is still far from perfect (just refer to existing smart speaker platforms)…
…creating a challenge in authenticating only authorized users to access the IoT button as well as for other sensitive transactions such as order/upgrade offer confirmation and payment authorizations
On the other hand an IoT button with built-in biometric (fingerprint reader) & NFC modules could authenticate users as well as aforementioned sensitive transactions with a simple push of a button… often without even looking at the device
Ongoing developments in mobile processors, SoC chipsets as well as on-device ML & AI technologies are rapidly improving VUI assistant platforms (think: edge / on-device processing) to a point where it may be quicker, safer, more intuitive & even secure enough to summon than using an IoT button… but until that day… the latter platform holds a degree of advantage over the former
An IoT button type of solution (if done right) may be able to alleviate the long drive-thru customer wait & service times (read: improving overall CX) whilst presenting QSR brands with a myriad of previously unexplored peripheral opportunities
To maximize consumer engagement (higher order frequency + CLV); the minimalist IoT button would need to at the least be robustly built, offer a simple & distraction-free operation and be complemented with an equally intuitive UI
Forthcoming segments will aim to cast light on the consumer journey aspect of the IoT button powered drive-thru solution as well as outline a potential B2B partnership opportunities the solution could unlock