Most apps marketed as "voice-enabled" inventory software are dictation: you speak, the phone types, and the system has no idea what you said. This 55-minute recorded webinar sorts the category out - the three very different things people call voice, why error recovery matters more than transcription accuracy, exactly where voice processing happens and what data leaves the phone - and then demonstrates complete inventory transactions performed by voice, live, in the QR Inventory voice-enabled mobile app.
Presented by Alex Heiphetz, PhD, CEO of AHG, Inc. (Boise, Idaho). Recorded July 2026. No discount coupon at the end - including a section on when you don't need QR Inventory at all.
Watch on YouTube: https://youtu.be/RApPOtvsjFA · Full transcript is below on this page.
The webinar uses inventory management as the working example. It's what we build and can demo live, but the principles apply to any task employees perform away from a desk: field data lookup, service records, equipment checks, mobile data collection. If your people work with gloves on, hands full, or one hand holding a flashlight, the same questions apply: which of the three types of "voice" you're actually buying, what the system does after it mishears, and where your audio goes.
Voice dictation transcribes speech into a field. Useful for notes, useless for workflows. Voice commands match a handful of fixed phrases to fixed actions - steady in noisy rooms, brittle the moment someone says "open the scanner" instead of "scan." Voice AI uses a language model to interpret what you meant: say "item 2, set quantity to 10" and the system parses the intent and the parameters. That third category is where the productivity gains are, and it only recently became practical because language models can now run on the phone itself.
Every speech recognizer mishears sometimes - "8" and the letter "A" sound identical, and a forklift passing by doesn't help. The webinar's central argument: what matters isn't how often the recognizer mishears, it's what the system does next. A 98%-accurate system with no recovery layer acts on what it misheard, and nobody notices until the wrong item shows up on the truck. A 92%-accurate system that catches its own uncertainty asks "did you mean this?" and gets corrected in one spoken phrase. Across a thousand transactions the second system wins by a wide margin - not because it's more accurate, but because it knows when it's wrong.
The webinar walks through four distinct failure modes - mishears, missed slots ("two pumps from warehouse 5" where the location didn't register), ambiguous references ("the blue one"), and mid-sentence changes of mind - and the five recovery patterns that handle them: phonetic fallback, fuzzy matching, confirmation prompts, long-input override, and an auto-process pause.
Voice wins when hands aren't available for tapping: gloves on, hands dirty, up a ladder, walking an inspection, item in one hand and phone in the other. Multi-field updates are genuinely faster spoken than tapped. Voice also works as an accessibility feature - for a worker with a hand injury or running two-handed equipment, it's the difference between being able to do the inventory work or not. Voice helps less next to a compressor or a running power saw (above roughly 75 dB of background noise, accuracy drops), for long alphanumeric IDs (scan those), in a customer's living room or a hospital corridor where speaking inventory out loud is awkward, and for anything that's already a single tap.
In QR Inventory, the microphone audio, the transcript, the data sent to the on-device language model, and the model's output all stay on the phone. The only thing that leaves is the structured inventory query - item, quantity, location, intent - which is the same payload a manually tapped transaction sends. Voice changes how the worker generates the query, not what gets sent. The database itself is in the cloud, because that's what lets ten people across five locations see the same stock at the same time: voice understanding needs no connection, live lookups and transaction submission do. The advice given to security teams in the webinar applies to any vendor: ask what gets uploaded, when, and where to - and get it in writing.
An earlier release had text-to-speech audio feedback. The phone speaking to itself interfered with the microphone and triggered misfires; echo cancellation and half-duplex modes didn't fix it reliably, so it was replaced with a silent visual notification. Vendors will always tell you what they shipped. The webinar's position: vendors who tell you what they took out, and why, are the ones to trust.
The demo shows a complete transfer transaction set up and submitted by voice - transaction type, from- and to-locations, scanned items, quantities, a custom field, a note, a photo - in under a minute and a half; a return with several custom fields updated in one utterance; and a transaction done while switching freely between voice and the regular tap-the-button interface. Every screen keeps scanning, voice, and manual input available, with no input ranked above the others.
Dictation transcribes speech into a text field with no understanding of what was said. Voice commands match a small set of fixed phrases to fixed actions and break when the user phrases things differently. Voice AI uses a language model to interpret intent and extract parameters - item, quantity, location - from natural phrasing. Most products marketed as voice-enabled inventory apps are dictation; the meaningful productivity gains come from voice AI.
In QR Inventory, no. The speech recognizer and the language model both run on the phone. Audio, transcripts, and the model's intermediate work never leave the device. The only thing sent to the server is the structured inventory query - the same payload a manually tapped transaction sends. Whether other products upload audio depends on where their speech recognizer and language model run; ask the vendor and get the answer in writing.
Voice understanding - speech recognition and language processing - runs entirely on the phone with zero network dependency. The inventory database is in the cloud so that multiple people across multiple locations see the same stock in real time, so live stock lookups and transaction submissions need a connection. Many transactions can be recorded locally and sync when the connection returns.
Every recognizer mishears sometimes, especially in noisy environments. A system with no recovery layer acts on what it misheard, and the error may not surface until the wrong item shows up on a truck a week later. A system that catches its own uncertainty asks "did you mean this?" and the worker corrects it in one phrase. Across a thousand transactions, the system that knows when it is wrong wins.
Very loud environments - above roughly 75 decibels of background noise, recognition accuracy drops. Long alphanumeric IDs are better scanned than spoken. Privacy-sensitive settings like a customer's living room or a hospital corridor make speaking inventory out loud awkward. And when a task is already one tap, voice adds nothing.
No. Every screen keeps scanning, voice, and manual touch input available. You can start a transaction by voice, switch to the regular tap-the-button interface mid-way, and switch back. Voice-only products fail when the worker can't or won't speak; manual-only products fail when hands aren't free.
No. QR Inventory uses the phone's built-in speech recognizer in offline mode and a language model of about 800 MB that runs on a standard Android phone or iPhone. The model downloads from the app store together with the app and is ready the moment the install completes. Output is deterministic: the same input produces the same result every time.
Operations, warehouse, construction, field service, and lab managers deciding whether voice is real productivity for their operation, and IT or security teams that need to know exactly where voice processing happens and what data leaves the device. It's a technical walkthrough with a live demo, not a sales presentation.
Learn more: QR Inventory voice-enabled mobile app · Short video demos · Discuss your project
Lightly edited for readability. Speaker: Alex Heiphetz, PhD, AHG, Inc. The Q&A portion was not recorded.
Welcome. Today we'll talk about voice for real work, without hype. It should take about 55 minutes, plus I will try to have 10–15 minutes for Q&A. Feel free to drop questions in the chat and I will answer as many as I can. I'll also demo QR Inventory with voice capability so you can see something real.
We'll start by discussing three very different things people call voice-enabled apps. Second, we'll touch on the recovery problem - why every serious voice system lives or dies on what happens after the recognizer mishears. Third, we'll see concrete workflows where voice is really, really useful. Then I'll pop up the hood and show you a bit of what drives QR Inventory. And I would be remiss if I didn't honestly talk about limits: where your voice doesn't help, and what the system does about it.
If you came expecting AI marketing that ends with a discount coupon, you'll be disappointed. If you came to figure out whether voice is real productivity for your operation, I'll do my best to help you. So let's start.
There are three different things people call voice, and they are not interchangeable.
One is voice dictation. You press a button, say the words, and the phone's speech recognizer types them into a field. The system has no idea what you said; it just transcribes. Most products marketed as voice-enabled inventory are this type. They are useful for taking notes and absolutely useless for complex workflows.
Number two knows voice commands - in other words, knows several fixed phrases that match fixed actions. "Scan" opens the scanner; "submit" submits the form. It works reliably if the user has memorized all the commands. It breaks the moment the user says something slightly different: if you say "open the scanner" instead of "scan," it will be confused. Good part: it's steady in noisy rooms. Bad part: it's brittle on phrasing. In most apps I saw, manual widgets to tap and do the same thing are available. This is good.
The third type: specially trained AI. It involves natural language understanding - an AI language model interprets what was said and figures out what you meant by it. "Info on GX98234" or "set quantity to 10" will be parsed as two intents with their separate parameters. This is where the meaningful productivity gains are found. AI matters more now, since on-device language models became practical for phones. Before that, this was a server problem. Now it isn't.
Dictation: you say "2753," the field reads "2753." Commands: you say "scan," the scanner opens - and if you say "open scanner," it does not. Voice AI: you say "info on GEP98234" or "item 2, set quantity to 10," and the system understands what needs to be done.
Does it handle varied phrasing? Dictation and commands: no - every phrase is fixed. Voice AI: yes, the model handles paraphrasing. Does it work for freeform fields? Dictation works; commands, no; voice AI, yes. Error recovery: with dictation and commands, you need to repeat the phrase you said; voice AI uses phonetic and fuzzy matching fallback plus confirmation prompts. We'll see this in the demo later.
The privacy row is the important one. For dictation and commands, it depends on where the speech recognizer runs. For voice AI, it depends on where the speech recognizer and the language model both run. Both have to be local for the audio and transcript to stay on the device and not be sent somewhere else. We'll come back to this in a couple of minutes.
The left column is where voice consistently wins. The right column is where it doesn't - or, at least, where it needs work.
Voice helps most when hands aren't available for tapping: your gloves are on, or your hands are dirty, or you are up on a ladder. Walking inspections, where you're moving and recording at the same time. Or you've got the item in one hand and the phone in the other. Multi-field updates - saying "quantity 10, condition good, notes: received without damage" - is genuinely faster than tapping through three fields.
Voice helps less in very loud environments. When you are standing next to a compressor, honking traffic, a working power saw - above about 75 decibels of background, recognition accuracy drops. It also helps less for long alphanumeric IDs; in privacy-sensitive contexts - a customer's living room, a hospital corridor, anywhere speaking inventory out loud is awkward; and in single-tap workflows where tapping is already fast.
For your business, two things matter most: ease of use and recovery.
This is the distinction that matters for regulated industries, and matters as a category of risk for everyone else. Everything inside the phone box happens locally. The microphone captures audio. The phone's speech recognizer turns that audio into text. The on-device language model takes the text and extracts the intent and the parameters: what action you wanted, against which item, with what quantity, at what location.
Nothing on this side gets uploaded. The audio doesn't leave the phone. The transcript doesn't leave the phone. The model's intermediate work doesn't leave the phone. What goes to the server is the structured query: item ID, quantity, location, intent. It is the same payload a manually tapped transaction sends. Voice changes how the worker generates it, not what gets sent.
I want to be real clear about two things. The voice processing is fully on-device. The database is in the cloud, because that's what enables ten people across five locations to see the same stock at the same time. Transactions and lookups still need a connection. Voice understanding does not.
Ask any vendor: what gets uploaded, when, and where to? Get it in writing.
One slide on the principle that runs underneath the whole product category. Scan to identify the item - QR or barcode is the fastest, most reliable path from your item to the system record. Voice to add context: quantity, condition, location, notes - the fields where scanning does not work. Buttons and touch input at the moment of commit.
All three inputs need to be available on every screen, with no input ranked above the others. Voice-only products fail when the worker can't or won't speak. Manual-only products fail when hands are not free. After a lot of testing we came to the hybrid: you pick what you need at the moment. Our conviction is that the strongest products keep all three available on every screen. This is the principle we will keep coming back to.
ASR stands for Automatic Speech Recognition, and here is the real-life problem you might want to consider: success with voice is not the same as transcription accuracy. Even excellent speech recognizers mishear something from time to time. In a warehouse, with gates opening and a forklift passing by, that rate gets worse. There's no way around it. Speech recognition today is excellent, but it still misfires sometimes.
The strategy should solve the question: what does the system do after the recognizer mishears? That's a different problem, with different code and a different design budget. A lot of products marketed as voice-enabled have invested in the recognizer and not in what happens next. The result looks great in a demo and falls apart in a warehouse or on a job site.
There are four distinct failure modes, each with its own recovery pattern.
First is the mishear: the recognizer hears the wrong word. The classic case is "8" versus the letter "A" - they sound identical out loud, and ASR can't always tell which is which from acoustics alone. Same for "zero" versus "oh," especially when you say "oh" inside a number.
Second is what we call the missed slot. The user said the whole sentence - "two pumps from warehouse 5" - and the system caught the item and the quantity but didn't catch the location. The intent is right; the data is incomplete.
Third, the ambiguous reference. The user said "the blue one." Which blue one? The system has the words, but the words don't resolve to a unique target.
Fourth, drift. The user changes their mind mid-sentence, which is quite normal for people: "Where do we have pumps? Forget it - generators." The system locks in the first intent and processes against it.
Each of these has its own recovery. We'll see the recovery patterns in the demo.
In this slide I will try to reframe how you think about voice quality. Imagine two voice systems. The first is 98% accurate on transcription. The second is 92% accurate. Which one is better? Most people would pick the first. That's wrong.
The 98% system, in this example, has no recovery layer. When it mishears, it acts on what it didn't hear right. The worker might not notice until the wrong item shows up on the truck a week later. The error rate is 2%; the cost per error might be enormous - backtrack, recount, refile.
The 92% system catches its own uncertainty. When a lookup fails or the confidence score is low, it asks: did you mean that? The worker corrects the potential problem in one phrase. The error rate is 8%; the cost per error is a few extra spoken words.
When you extrapolate the two systems across a thousand transactions, the second wins by a wide margin - not because it's more accurate, but because it knows when it's wrong. Folks who pitch accuracy are pitching the wrong number. You need recovery.
Phonetic fallback. When an ID lookup fails and the ID contains a digit that sounds like a letter - 8 versus A, 0 versus O - the system retries with the substitution. Most mishear failures resolve here before the user sees anything.
Fuzzy slot matching. When the spoken slot value doesn't exactly match anything on file, matching math helps us catch single-character errors. High confidence autocorrects; medium confidence asks the user.
Confirmation prompt. Works for medium-confidence matches and ambiguous inputs. The system asks - did you mean this or that? - before acting.
Long-input override. If the user starts saying something complex during a yes-or-no confirmation, the system cancels the confirmation and treats the new utterance as a fresh command. You are never stuck in a confirmation loop.
Auto-process pause. Two seconds of silence before acting. It gives the worker room to add to a sentence without the system jumping ahead.
All of these recovery cases determine whether voice is usable in real environments.
Let me start with a canonical case, one many of you will recognize from your operation: receiving. The worker pulls up to the loading dock. The trailer is open. Phone is in one hand, dolly is in the other. The system needs to know it's a receiving transaction, the destination is the main warehouse, and there are about 30 items coming off this truck.
Voice opens the transaction: "Do receiving transaction." Done - the transaction type selector resolves; the system understood I wanted receiving. The location next: "main warehouse." It could be simply "main warehouse," but could also be "row two, bin six" - as detailed as you want. Now the phone goes into a pocket or a small dock and the worker frees both hands. Each item gets scanned with the rear camera at a steady angle. Quantities are voiced item by item. No menu navigation. No typing on a phone with dirty gloves.
What's worth noticing: every step has a manual button. The mic icon stays on screen. If you decide voice isn't working here and now, the tap path is right there. That's why you want a hybrid interface.
Second workflow: voice used to work with your company's specific custom fields. An item comes back damaged. Maybe it's a piece of returnable equipment, maybe a tool, maybe a part the customer didn't end up needing. It goes back into receiving with a condition update, a quantity update, and a note describing the damage.
Slow path: open the item. Hit update. Quantity field - tap, type, save. Open the condition field, scroll the drop-down, select. Open the notes field - tap, type the description, save. Three field updates, three round trips through the user interface, maybe 30 seconds of focused tapping and typing.
Fast path: tap update, tap the mic, say it. "Set quantity to 10. Set condition to good. Set notes to: received with cosmetic damage on the housing." Three custom fields, one utterance, about 8 to 10 seconds. The damage photo follows: voice triggers the camera - capture, attach, done. The damage record is complete. The next worker who looks at this item sees the full story - quantity, condition, notes, photo - not just a quantity adjustment that someone has to follow up on.
Custom fields take voice. Freeform notes take voice. And it works.
A tech is on a service call, in a crawl space, flashlight in one hand, phone in the other. He needs to know if the warehouse has a 1-inch PVC elbow before he tells the customer he needs a return trip.
Slow path: open the inventory app, navigate to search, type the keywords, filter by location, read the results. Possible, but inconvenient with one hand and a flashlight.
Fast path: "Do we have any 1-inch PVC in warehouse 1?" The system understands it as a stock query, extracts the keyword, extracts the location, runs the lookup against the shared cloud database, and returns the result on screen.
Voice can make the difference between your guy using the system or not. Workers with hand injuries. Workers operating heavy equipment that requires two hands at all times. Workers on ladders or scaffolding, where tapping the phone invites the risk of dropping it.
In these situations voice isn't faster - it makes the work possible. The tap path may be the better fit for somebody else doing the same task tomorrow. Today it isn't an option, and the voice path is the difference between being able to do the inventory work or not. That expands who can do the work, including people who would otherwise be limited to a narrower set of tasks.
One slide on the speech recognition layer. QR Inventory uses your phone's - Android's and iPhone's - built-in speech recognizers in offline mode. Recognition runs entirely on the phone. We don't use our own or a third-party voice service. There's no upload step. We do not claim that voice will improve over time as we collect more data from your phone, because there is no collection and we never see your data.
Why it matters: if the speech-to-text layer runs on someone else's servers, you have no control over what happens to your audio. That's an architectural choice. Some products make it. We made the opposite one. Repeat that plainly when your security team asks where voice processing happens.
One slide on the language model. We use an AI language model we fine-tune for inventory management. Its size on disk is about 800 megabytes. Inference runs right there on your mobile phone. We configure it for greedy decoding, which means the output is deterministic: give it the same input and you will receive the same output 100% of the time. That's important for inventory - voice command consistency matters more than creative phrasing.
The model is downloaded from the app store at the same time as the rest of the mobile app. It is on the phone the moment the install completes, not downloaded on first launch. Until very recently, this wasn't practical on phones. The combination of better mobile hardware, smaller models, and available software tools made it possible. The on-device LLM is the difference between real voice AI and voice commands.
The most important slide for your security team. What stays: the microphone audio, the transcript from the speech recognizer, the data sent to the language model, the output from the language model - your intent and the details the app figured out - and the matching-math computations. All of it.
Only one thing leaves the phone: the structured inventory query to the inventory database. It is the same payload a manually tapped transaction generates. Voice doesn't change what gets sent; it changes how you generated it.
Voice understanding runs on the phone with zero network dependency. The inventory database is in the cloud, because that's what enables multi-user, multi-location, real-time data - the same architecture as any modern team inventory system. Ask any vendor what gets uploaded, when, and where to. Get it in writing. Compare.
I want to spend a minute on a feature we removed. We shipped text-to-speech audio in an earlier release. The phone would speak inventory results, status, confirmations - something like "item ABC123, quantity 10, in main warehouse." Audio feedback is useful for hands-busy work where looking at the screen isn't always convenient.
We found two problems with that. It interfered with the microphone: the mic picked up the app's spoken response as new speech, the recognizer would start a new session in response to the phone speaking to itself, and misfires followed. We measured the error rate. We tried echo cancellation, source separation, half-duplex modes - none of it brought recognition reliability back to where it needed to be. So we made a call: replaced TTS audio with a visual notification pop-up. Same status information, conveyed silently, no microphone interference.
The second problem: listening to what the phone says isn't always the best option, as we found out. And a third, minor problem: voice generation, and listening to voice, is slower than reading.
Finally, why this is on a slide: every vendor will tell you about features they shipped. Vendors who tell you what they took out, and why, are, I think, more trustworthy.
Here is the plan. Workflow 1: voice-guided full transaction setup - start a transfer by voice, voice the from-location, voice the to-location, then hand off to scanning. Workflow 2: a multi-field update on a returned item - we'll update several custom fields with voice, then take a photo and submit the transaction. Workflow 3: I'll perform a transaction switching back and forth between voice and the traditional tap-the-screen interface. I'm switching to the phone screen now.
Workflow 1: "Do transaction transfer." "Select from location B27." "Select to location…" - voice the warehouse. "Next." "Button scan QR code." "Line item 2, quantity 1." "Line item 1, button properties." "Field job number - Job 1." "Notes: good condition." "Photo." "Submit." "Button submit." Here we are - prepared and submitted a transaction using voice, including custom fields and taking a photo, all in under a minute and a half.
Workflow 2: "Do transaction return." "Select to location B27." "Next." "Set customer to Joe's Construction." "Set reason to wrong size." "Next." "Button scan." "Button properties." "Set condition to ideal." "Button photo." "Submit." "Submit transaction." You can see the app gets the GPS location and sends the photo we took along with the rest of the data. Another transaction is in the books, and it took us under a minute. "Button home."
Workflow 3: In this screen video we'll see that voice is not required to use the app. You can switch back and forth between voice and the regular screen interface and use what is more convenient for you at the moment. We'll start with voice: "Do transaction receive." Switching to the regular interface… back to voice: "Next." Voice off again… "Done." "Submit transaction."
What you just saw in the QR Inventory workflows: first, voice-guided transaction setup; second, a multi-field custom-field update with a voice-triggered photo; third, the ability to use voice and the regular touchscreen interface interchangeably.
Three things I want to name before we move on. First, every voice step happened on the phone. Audio didn't leave; transcripts didn't leave; the on-device language model's intermediate work didn't leave. The only thing that went to the server was the structured query, same as any manual transaction. Second, every screen kept the tap equivalent visible. The mic icon was one option; the buttons, the drop-downs, the form fields, the scan trigger were always next to it. Pick what you need at the moment. Third, recovery. If you saw a confirmation prompt or a phonetic retry, that's the recovery layer doing its job. Recovery is the feature, not raw transcription accuracy.
Voice processing is offline. Inventory visibility is shared. The goal is not a cooler demo - it's fewer problems in real-life situations.
Now, the most honest slide in my deck: when you do not need QR Inventory. Don't take me wrong - we want your business. But if you have very few line items, or you don't carry much inventory and you don't have many tools and equipment that you want to track, you probably can live without it.
On the other hand: if you carry inventory of supplies and want to know what you have and where; if you want to know where that power generator or that tissue sample is; if you send something to a job site and then want to account for returns; if you want to know what and how much you used for this or that project or customer - QR Inventory would be of tremendous help. Using it, you will know exactly what is where, be prepared for compliance audits, and never be caught flat-footed by a simple question: how many widgets have we got?
I hope the time you spent on this webinar pays back. Thank you for your time.
