The gap between tapping Apply and pressing Submit

Hiring-app owners love the Apply tap. It is a clean event, it looks like demand, and it goes on the weekly slide. In the reviews we run from Shah Alam, the more honest question is what happens in the next four minutes.

On a campus-hire app we read last year, Apply-started was healthy. Submit was not. The screens in between were a Bahasa Malaysia consent wall that ran to three pages, a CV attach control that only accepted a file picker (no camera capture), and a “current address” field that opened a full Malaysian state list in a tiny spinner. Graduates on factory Wi-Fi abandoned the spinner. The event trail made that visible once we stopped treating Apply-started as the story.

A store-hiring app had a quieter leak. The CV parser accepted PDFs, then failed silently on scans from polytechnic labs. Candidates saw a green tick on attach. Submit then threw a generic error. The analytics product recorded attach-success and never recorded the error as a named event, so the weekly report blamed “low intent.”

When we walk an apply flow now, we ask to do it on the phone the talent team actually sees in candidate photos: often a mid-range Android, not the product owner’s iPhone. We count consent viewed, consent accepted, attach attempted, attach accepted, and submit. If any of those names do not exist, that fact goes in the findings pack as a finding, not as a footnote.

If you only have time to fix one stretch of a recruitment app, fix the stretch after Apply. That is where people still intend to finish, and where a spinner or a silent parse can waste the budget that bought the tap in the first place.