We ran a client tracker by voice for a week
The setup was simple. We had a freelance contractor who needed to log client interactions (meeting notes, follow-up dates, contact details) while driving between sites. Typing into a spreadsheet at a red light is how data gets lost. So we ran an experiment: one week, one real client tracker, voice only.
The tool was Voice Tables, something we built at Inithouse. It's a workspace you control by talking to it. Describe what you need and it builds tables, documents and data structures for you. Think of a database that listens instead of waiting for you to type. Over five working days we logged 47 voice entries in roughly 90 minutes of total voice interaction.
Day 1 and 2: setup and first entries
We started by saying: "Create a client tracker with columns for name, company, last contact date, next follow-up, status, and notes." The workspace appeared in about 50 seconds. No templates to browse, no column-type dropdowns. Just a sentence.
The first real entries went in from a parked car after a morning meeting. "Add a row: Jan Novak, Redpoint s.r.o., met today, follow up next Thursday, status active, notes: interested in the monthly package, wants a proposal by Friday." It parsed correctly. The name, company, date inference ("next Thursday" mapped to the actual date), status: all landed in the right columns.
By end of day two we had 12 entries. Average entry time: about 40 seconds per record, including corrections.
Day 3: the first real failure
On day three we hit the first problem that mattered. The contractor tried to log a note while walking through a noisy construction site. Ambient noise (angle grinders, a radio, someone shouting across the floor) wrecked transcription accuracy. Out of 6 entries attempted on-site that day, 2 came through garbled. One had the client name wrong ("Bartos" instead of "Bartos with a hacek"). Another mixed up the notes field entirely, putting a fragment of the follow-up instruction into the status column.
Root cause: the voice pipeline (Whisper-based) handles background noise reasonably well in cars and offices, but sustained loud environments with overlapping voices push it past a useful threshold. We didn't have a noise gate or confidence-score filter at the time.
What we stopped doing by voice after day 3
This is the decision that changed the rest of the week.
We stopped using voice for:
- Complex multi-field updates. Editing an existing row where you need to reference it by name, change two fields, and leave the rest. Voice kept misidentifying which row to update when there were 20+ rows.
- Bulk corrections. If three entries needed fixing, doing it by voice was slower than just opening the table and clicking. Voice is fast for creation, slow for surgery.
- Anything requiring exact formatting. Phone numbers with country codes, email addresses, URLs. Voice gets them wrong often enough that checking and fixing takes more time than typing.
We kept using voice for:
- New row creation (the core use case, still faster than typing, especially from a car).
- Quick status updates ("Mark Novak as done" or "Move Redpoint to follow-up").
- Adding notes to existing rows ("Add a note to Bartos: sent the revised quote, waiting for sign-off").
The numbers after 7 days
| Metric | Result |
|---|---|
| Total voice entries | 47 |
| Correctly parsed on first try | 38 (81%) |
| Required manual correction | 9 (19%) |
| Average entry time (voice) | ~40s |
| Average entry time (keyboard, same fields) | ~65s |
| Entries from car or transit | 19 (40%) |
| Entries from office or desk | 22 (47%) |
| Entries from noisy site | 6 (13%) |
| Noisy-site accuracy | 67% (4/6) |
The 81% first-try accuracy is where we landed. For a desk worker, that's probably not compelling enough. You could just type. For someone who's driving, carrying materials, or standing in a kitchen, the 40% of entries that happened from a car wouldn't have happened at all without voice. That data would have been a sticky note, a mental note, or nothing.
What this says about hands-busy professions
The contractor we ran this with fits a pattern we keep seeing: people whose actual work happens away from a screen. Electricians between jobs. Real estate agents between viewings. Sales reps between meetings. They all generate data (contacts, notes, measurements, follow-ups) in moments when a laptop is impractical and a phone keyboard is slow.
Voice works for them not because it's perfect, but because it captures something that would otherwise be lost. A quick "add row" from a parked car is infinitely better than "I'll log it when I get back to the office," which realistically means it doesn't get logged.
The failure modes we found (noisy environments, complex edits, exact formatting) are real constraints, not edge cases. They define where voice stops being the right input method. And that's fine. The point isn't to replace keyboards. It's to cover the gaps where keyboards aren't available.
What we're changing based on this
Three things went onto our backlog after the experiment:
- Confidence-score filtering. If transcription confidence drops below a threshold, flag the entry for review instead of inserting it silently.
- A "repeat back" confirmation mode for noisy environments. The agent reads back what it understood before committing.
- Better row-identification for updates. Letting the user reference rows by number or a unique field rather than name matching.
None of these are hard to build. They're the kind of thing you only discover by using the product for a real job over multiple days, not by staring at a feature list.
Voice Tables is live at voicetables.com. Describe what you need and it builds it. We built it at Inithouse, where we ship products like this by actually running them on real work before deciding what to fix next.
