Your chatbot's mobile keyboard is the conversion leak nobody's talking about

By Mike Berris · April 21, 2026 · 6 min read

On iOS, the hit area of a single key is 471% larger on the numeric keyboard than on the traditional keyboard — 209 × 108 pixels vs. 52 × 76 pixels. That number is from a 2013 Smashing Magazine piece citing Baymard research, and it's the kind of stat mobile form designers have been chasing for a decade.

And yet, open almost any AI chatbot widget on your phone and ask it for a number — a dollar amount, a phone number, a ZIP code — and you'll get the same generic QWERTY keyboard you'd get if it were asking you your name. A composer designed for free-form prose, pointed at a field that should be four taps on a numeric keypad.

That's a conversion leak. It's quiet, it's measurable, and the agentic AI chatbot category has mostly ignored it.

What an adaptive mobile keyboard actually is

The mechanism isn't exotic. HTML5 defines inputmode and type attributes on an <input> element. Set inputmode="decimal" and iOS and Android show a numeric keypad. Set type="email" and you get the email layout with a visible @ key. Set type="url" and you get the URL keyboard with a .com shortcut. type="tel" gives you a tel keypad. inputmode="numeric" gives you digits.

The browser does the work. The OS picks the layout that matches the user's language, region, and accessibility settings. Your app doesn't ship a custom keyboard — it just tells the OS what kind of answer it expects.

Done right, the keyboard itself tells the visitor what the field is for. You don't need a label.

Who's already doing this — and who isn't

Static conversational form builders have had this for years. Typeform, Tally, Landbot, Typebot, HeyForm, Jotform Cards — pick any of them, and the field type for each step is hardcoded at build time. Setting the right inputmode on the input is trivial because the form knows exactly what it's asking.

The agentic AI chatbot category is a different story. Look at the defaults in Intercom Fin, Zendesk AI, Ada, Drift, Sendbird, Chatbase, HubSpot AI, Voiceflow, Botpress, Tidio. Each one ships a single free-text composer. No matter what the model is waiting for — a number, an email, a URL, a yes-or-no — the visitor types into the same generic box with the same generic keyboard.

Same for general-purpose assistants: ChatGPT, Claude, Gemini, Perplexity all default to a free-text composer too. They were never designed to collect structured data. That's reasonable for the product category — but it's the pattern the whole "AI chat" UI inherited from them.

Compare that to how we've positioned Wengrow against Intercom on structured lead capture specifically: the advantage isn't model quality, it's the engineering choice to treat a chat as a form when the chat is collecting form fields.

We can't find another agentic chatbot doing adaptive per-field keyboards. If you know of one, tell us and we'll update this post.

Why agentic chatbots skip it

The technical reason is straightforward: in most chatbot architectures, the composer sits between the user and the LLM, and the UI has no reliable signal about what kind of answer the model is waiting for on this turn. The model's output is free text — "What's your email?" is just a string — and the widget renders the same composer regardless.

To do better, the agent has to publish its current field intent back to the widget in a structured form. "I'm collecting an email on this turn. Render the input with type='email'." That takes deliberate engineering — field extraction, state tracking, a protocol between agent and UI — and most AI chatbot products have prioritized other things (model quality, knowledge base, escalation, analytics) ahead of it.

Wengrow prioritized it because the job-to-be-done is lead capture, and lead capture is a form. The agent's state machine — configured in the lead qualification field designer — knows when it's collecting a typed qualification field (currency, email, URL, phone, postal code), and the widget sets the right input mode before the visitor's thumb hits the screen. Those captured fields land on the lead management panel with their types intact. It's not novel technology — it's the discipline of wiring form-grade input UX through an LLM-driven conversation instead of pretending a chat isn't a form.

The conversion math

Three more numbers worth keeping in mind when you audit your chat:

• Auto-filling helps people fill out forms 30% faster. (Google, reported in a 2018 Smashing piece.) type="email" and autocomplete="email" are what make autofill happen on mobile.
• The average checkout contains almost 15 form fields, and most online services could reduce the number displayed by default by 20 to 60%. (Baymard, via the same Smashing piece.) A conversational flow asks one question per turn — the reduction is built in.
• Conversational forms have a 40% higher completion rate than traditional forms. (Per Sendbird; they don't name a primary study, so take it directionally.) Wengrow is already conversational. Add adaptive keyboards on top and you get the two biggest mobile-form wins in the same UI.

Those gains compound with the 471% hit area. Bigger keys → fewer mistypes → fewer retries → fewer abandonments. On mobile traffic, the math tends to favor whoever pays attention to the input, not the output.

Honest caveats

None of this is a free lunch. A few things we've learned shipping it:

• LLMs sometimes ask two things in one turn. "What's your name and email?" is a prompt-tuning problem, but it happens. When it does, the widget falls back to the dominant field's keyboard (typically the first one asked) and the second value is collected on the next turn. The cleaner the prompt, the rarer this is.
• OTP autofill is iOS-specific. The "paste from SMS" affordance on one-time codes is an Apple feature. Android handles OTP differently (SMS Retriever API for native apps, lighter on the web).
• Native SDK embeds need keyboard hints piped through. The web widget sets inputmode and type directly. If you embed Wengrow via an iOS or Android SDK into a native app, the host app owns the input element — your integration needs to forward the field-intent signal.
• It deserves an A/B test. Bigger keys should improve completion, and the research supports it, but the real lift on your traffic will depend on your audience, your fields, and your completion-rate baseline. If you're running experiments, hold QWERTY as the control and measure.

None of those are deal-breakers. They're the kind of caveats you bake into release notes, not the kind that change the decision.

The takeaway

Adaptive mobile keyboards aren't a new idea — they're a decade-old form-design best practice the agentic AI chatbot category has been slow to adopt. If your chatbot is a lead-capture tool, it's a form. Treat it like one, and give every field the right keyboard. The static form builders worked this out a long time ago; the agentic category will eventually too. The question is whether you want to wait for your platform vendor to ship it, or pick a platform that has already.

See how Wengrow's adaptive mobile keyboard works → · Pricing starts at $49/mo.