Voice Tables by Inithouse: what we measured running a voice-first AI workspace

At Inithouse, a studio shipping a growing portfolio of products in parallel, we run numbers on everything we ship. Voice Tables is our voice-first agentic AI workspace: you describe what you need and it builds the tables, docs and data for you. We launched it, watched what happened, and wrote down what the data said. Here is the breakdown.

Why we tracked this

Most AI workspace tools report vanity metrics. Monthly active users, sign-ups, page views. Those numbers tell you whether people showed up, not whether they stayed or got value. We wanted to answer a harder question: does voice input actually change how people interact with structured data?

So we instrumented Voice Tables with event tracking across three layers: input method (voice vs. keyboard), task completion (did the workspace get built?), and return behavior (did the user come back within 7 days?).

What we measured

Voice vs. keyboard split. The ratio surprised us. We expected voice to be a novelty that users tried once and dropped. Instead, users who started with voice kept using voice. The voice-first cohort showed a higher completion rate for workspace creation than the keyboard cohort. Not by a small margin. The directional gap was wide enough that we stopped treating voice as a feature and started treating it as the core interaction model.

Time to first workspace. Our target was 60 seconds from landing to a working workspace. The median came in under that for voice users. Keyboard users took roughly twice as long, mostly because they paused to think about column names and structure before typing. Voice users described what they needed in natural language ("I need a CRM for my photography clients with columns for shoot date, location, and payment status") and let the LLM figure out the schema. Fewer decisions up front meant faster starts.

The 3-in-1 usage pattern. Voice Tables combines tables, docs, and AI chat in one workspace. We assumed users would pick one and stick with it. They did not. The most engaged users touched all three within their first session. Tables for structured data, docs for notes and context, chat for asking questions about their own data. The combination created a stickiness we did not see when we tested tables-only prototypes earlier.

Return behavior. This is where it got interesting. Voice-first users came back at a higher rate than keyboard-first users. Our hypothesis: voice lowers the friction of "opening the tool and doing something." You do not need to remember where you left off or what button to click. You just talk. That friction reduction compounds over days.

Session length distribution. We expected voice sessions to be shorter since talking is faster than typing. They were not. Voice users spent similar time in the workspace but accomplished more in that time. They created more tables, added more rows, and wrote more doc pages per session. The throughput difference was consistent across user segments, from freelancers tracking client projects to small business owners managing inventory.

Where it broke

Not everything worked.

Accent handling in early builds. Our Whisper + LLM pipeline handled standard English well but struggled with strong regional accents in the first weeks. We traced the root cause to our prompt layer, not to Whisper itself. We were sending raw transcription to the LLM without a normalization step. Adding a lightweight text-cleaning pass between Whisper output and LLM input fixed the majority of failures. Simple, but it took us two weeks of user reports to identify the pattern.

Offline sync conflicts. Voice Tables supports offline mode. When two users edited the same workspace offline and reconnected, our conflict resolution sometimes picked the wrong version. We rebuilt the sync logic to use last-write-wins per cell rather than per workspace. Edge case, but the kind of thing that erodes trust if you ignore it.

Schema drift from voice. When users describe tables verbally, they sometimes use different words for the same concept across sessions. "Client name" on Monday, "customer" on Wednesday, "the person" on Friday. The LLM would create new columns instead of mapping to existing ones. We added a schema-matching layer that compares new voice input against existing column headers using semantic similarity. Not perfect, but it cut duplicate columns by a significant margin.

What this tells us about voice-first tools

Voice is not a gimmick for structured data. It is a genuine interaction paradigm that changes user behavior in measurable ways. The completion rates, return rates, and session patterns all point in the same direction: when you remove the keyboard bottleneck for data entry, people enter more data, more often.

We see a similar pattern across the portfolio. At Be Recommended, our AI visibility monitoring tool, removing friction from the input step (just type your brand name, the system does the rest) correlated with higher engagement. At Here We Ask, our free browser conversation card game, the simplest possible interaction (tap to draw a card) drove the highest session counts. The pattern holds: lower input friction, higher engagement. Voice is the extreme version of that thesis.

What we are doing next

Three things based on the data.

First, we are doubling down on the voice-first onboarding. The gap between voice and keyboard completion rates is too large to treat them as equal paths. New users will land on a voice-first flow by default, with keyboard as the fallback.

Second, we are expanding the schema-matching layer. The duplicate column problem is solvable with better semantic matching, and solving it makes voice input feel reliable rather than approximate.

Third, we are adding voice commands for data queries. Right now you can build with voice but you query with clicks. Closing that gap means users never need to switch modes.

Voice Tables is still early. The thesis that voice can replace keyboard for workspace creation held up in our measurements so far. Whether it scales to larger, messier datasets is the next question we are running at voicetables.com.

Inithouse, a lab building many products at once, publishes what we learn as we go. If you are building voice-first tools or thinking about it, we would like to hear what you are measuring.