The setup: 6 users, 40 applications, 8 days.
Between August 26 and September 3, 2026, we ran private testing with six people using an early build of Jobsistant. They applied to real jobs on their own machines. We logged what the scanner saw and what the resolver did — nothing about their answers left the device except value-free field shapes. Forty of those applications produced recorded fill events, 1,155 fill events in total.
This is first-party data from a small, self-selected group testing an early product. It is not a controlled study, the sample is too small to generalize, and the product was changing during the window. Treat the numbers below as observations from one build, not as claims about how job applications work in general. We are publishing them because building from real recordings beats building from assumptions — even when the recordings are unflattering.
Two different slices of the data appear here, and we want to be clear about which is which. Field counts were recorded on every form the scanner opened, grouped by ATS — you do not need a fill event to count how many fields a form has. Outcomes, resolution, value source, and confidence were measured across the 1,155 fill events in the 40 applications where the resolver actually ran. The two slices cover different things on purpose.
What we measured: fields, outcomes, repetition, time.
For each application we recorded the ATS, the number of fields on the form, how each fill event ended, how often a field repeated across applications, and the time the machine spent assisting — not the total time the user spent on the application.
| ATS | Applications | Avg fields / application | Fill time (machine-assist) |
|---|---|---|---|
| Generic forms | 58 | 29 | 1.0 min |
| Workday | 8 | 73 (57–89) | 2.2 min |
| Ashby | 5 | 10.4 | 1.0 min |
The 1.0–2.2 minute figures measure how long the resolver spent preparing fields for review — not how long a person spent on the whole application. Total application time, including the parts the resolver left for the user, was higher and we did not measure it cleanly here. Do not read these numbers as “application time.”
How each of the 1,155 fill events ended is the part we care most about, because it shows where the product helps and where it steps back.
| Outcome | Share | What it means |
|---|---|---|
| Left for user | 76.9% | Field not filled; the user completed it themselves |
| Known | 13.7% | Resolver matched the field to a known profile value |
| Unsure | 5.5% | Matched but flagged for the user to review |
| Never fill | 2.0% | On the never-fill list (passwords, CAPTCHA, payments, national IDs) |
| Generated | 1.6% | Drafted only from supplied facts, then reviewed |
| Verify failed | 0.3% | Generated text failed fact validation and was discarded |
The Workday finding: 73 fields, 86.3% left for the user.
Workday forms averaged 73 fields per application, with a range of 57 to 89. Ashby forms averaged 10.4. That is roughly a 7× difference in field count, and it showed up everywhere downstream. On Workday, 86.3% of fill events were left for the user. On Ashby, 44.2% were. The forms that ask more also defeat the resolver more.
73 fields on average, 86.3% left for the user, 2.2 minutes of machine-assist time. The long forms are where repetition is most painful and where we help least today.
10.4 fields on average, 44.2% left for the user, 1.0 minute of machine-assist time. Shorter, more standard fields let the resolver do more — but the sample is tiny.
We want to be careful here: we recorded 8 Workday applications and 5 Ashby applications. A 7× field-count gap is large enough to take seriously, but the outcome percentages sit on small denominators and will move as we test more. The direction matches what every job seeker describes — Workday forms feel long because they are long — and the field count is the part we are confident in.
The repetition finding: email in 60% of applications.
The clearest signal in the data is how often the same fields recur. Across the 40 applications with fill events, email appeared in 60% of them, phone and resume upload in 52.5% each, and open questions in 42.5%. These are the fields a reusable profile is meant to handle, and they are the fields our resolver leaves for the user most often.
| Field | Share of applications |
|---|---|
| 60.0% | |
| Phone | 52.5% |
| Resume upload | 52.5% |
| Open questions | 42.5% |
| Family name | 37.5% |
| Given name | 32.5% |
| Salary expectations | 27.5% |
| Years of experience | 25.0% |
| Current compensation | 25.0% |
| Notice period | 25.0% |
The honest reading: the repetition is real and large, and the resolver is not yet capturing most of it. Email, phone, and resume upload are the first things we should never ask a user to retype — and right now we usually do.
What the resolver did: 13.7% known, 59% unmappable.
For every field the scanner saw, the resolver had to decide what to do. It matched 13.7% of fill events to a known value, flagged 5.5% as unsure for review, generated 1.6% from supplied facts, and left the rest. The largest single bucket is the one we are least proud of.
| Resolution | Share | What it means |
|---|---|---|
| Unmappable | 59.0% | The scanner did not recognize the field at all |
| Synonym | 14.0% | Matched via the synonym lexicon |
| User | 10.8% | The user supplied the value directly |
| LLM | 5.9% | Field classified by the model |
| Regex | 4.1% | Matched by a pattern |
| Shared cache | 3.4% | Reused a value-free shared mapping |
“Unmappable” means our scanner did not recognize the field — it could not tell what the field was asking for, so it could not fill it. That is our problem to fix, not a property of the form. It is the single biggest reason fields get left for the user, and it is the top priority coming out of these notes.
The smaller buckets tell us where the existing machinery works. Synonym matching (14%) and the shared, value-free cache (3.4%) handle fields whose labels vary between ATS but mean the same thing. Regex (4.1%) catches structured fields like dates and postal codes. The 5.9% classified by the model is small and deliberately so — generation is the last tool we reach for, never the first.
The flywheel: 10.8% of fills came from saved answers.
One number in this data is the one we are building toward. 10.8% of filled values came from a saved answer — a value a user entered once and that Jobsistant reused on a later application. It is small. It is also the part that compounds: every application a user completes teaches the next one, and the share should rise as the profile fills out.
| Value source | Share | What it means |
|---|---|---|
| None (manual) | 86.7% | No stored value; the user typed it |
| Saved answer | 10.8% | Reused a value saved from a previous application |
| Generated | 2.5% | Drafted from supplied facts, then reviewed |
The 86.7% “none (manual)” is the same story told from the other side: today, most filled values are typed by hand because nothing was saved yet. The flywheel exists and is measurably working — it just started from zero eight days ago.
What surprised us: the confidence distribution.
When the resolver did fill a field, it assigned a confidence. 57.7% of fills were high confidence (0.9 or above), 27.4% were medium (0.78–0.9), and 14.9% were low (0.5–0.78). The high-confidence share is better than we expected for an early build.
| Confidence band | Share of fills |
|---|---|
| High (0.9+) | 57.7% |
| Medium (0.78–0.9) | 27.4% |
| Low (0.5–0.78) | 14.9% |
A low-confidence fill is still presented for review, never submitted silently, and the user can reject it. But it is a signal that we are guessing in places we probably should not. The honest target is not “fill more” — it is “fill fewer fields, but be right about the ones we do fill.”
This is where being a reviewed-autofill product matters. A low-confidence guess that sits in a field, clearly flagged, waiting for a human to accept or fix, costs seconds. The same guess submitted automatically could cost a job. We will take the seconds.
What this means for the product.
The notes point to one priority that dwarfs the others. If 59% of fields are unmappable and 76.9% of fill events are left for the user, the binding constraint is not generation and not speed — it is recognition. The scanner has to understand more fields before anything else can improve.
- Recognition first. Shrink the 59% unmappable by teaching the scanner more field labels, starting with the repeated fields in this data.
- Capture the obvious repetition. Email, phone, and resume upload appear in over half of applications and should essentially never be left for the user once a profile exists.
- Raise the confidence floor. Move low-confidence fills toward either a confident fill or an honest “left for you,” rather than a guess.
- Grow the flywheel. The 10.8% saved-answer share is the leading indicator of whether the product gets faster with use. Watch it, do not game it.
We are deliberately not chasing the Workday outcome percentage yet. With 8 Workday applications in the sample, optimizing for that number would be overfitting to a handful of forms. Fix recognition broadly and Workday improves as a side effect.
What this means for the field.
We will not claim this sample represents the market — six users and 40 applications cannot. But one observation is consistent enough, and matches everyday experience closely enough, that we will state it plainly: application forms vary enormously in length, and the longest ones are where repetition hurts most and where automation helps least today.
The 7× field-count gap between Workday and Ashby is the kind of thing every job seeker already knows from typing through it. Having it on a spreadsheet does not make it more true — it just makes it something we can build against. Our job is to turn “Workday is exhausting” from a feeling into a fixed number of fields we recognize, one release at a time.
Disclosure: Jobsistant publishes these field notes and has a commercial interest in autofill that works. The numbers above are raw recordings from our own private testing; they have not been normalized, peer-reviewed, or compared against any other product under a shared protocol. We have presented the unflattering shares (59% unmappable, 76.9% left for user) alongside the promising ones because hiding them would make the rest untrustworthy.
If you want the practical side of this — what a single person can do today, with or without us — read the guide to stopping retyping in job applications and the autofill versus auto-apply comparison.