Skip to main content

Auto-select timing: recover the jobs that had applicants and nobody selected

The initiative in one sentence: stop losing about 59 gig jobs a week at the last step of the funnel, where an applicant exists and nobody selects them, by selecting at each job's last safe moment instead of at 09:00 and 17:00, and by re-selecting at once when a selected jodder drops out.

What this page is

This is the entry page of the initiative. It holds the problem in three sentences, the headline numbers, the pages that carry the evidence, and the decisions the CTO still has to rule on. It exists so that engineering can spec the implementation from the solution page without re-reading the analysis, and so that every number can be traced back to a query on the queries page.

The problem in three sentences​

Auto-select looks at each open job once, at 09:00 or 17:00 the day before the shift. 55% of applications arrive after the evening run and before the morning run, half of all jobs are posted in the same window, and a normal job expires 8 hours before its shift, so the morning run finds it already gone. The result is 703 jobs in twelve weeks that expired with a live applicant waiting at an outlet where auto-select was switched on.

The headline numbers​

All numbers are from the nightly copy of production for shifts starting 22 June to 13 September 2026, twelve weeks, unless the row says otherwise. Each carries its strength tag.

whatnumbertag
jobs that expired with a live applicant at outlets with the flag on703, about 59 a weekfact from data
of which the job or the applicant arrived after the one run662 of 703 (94%): 515 jobs created after the run, 147 with the first applicant after itfact from data
of which the run had its chance and did nothing41 of 703 (6%), 31 of them UKG jobs where the hire rolls back silentlyfact from data
what auto-select earns today, gross, credits on the shifts it filledabout SGD 7,200 a week, 5.8% of platform credits, an upper boundfact from data
what auto-select earns today, net of picks a manager would have madeabout SGD 3,500 a week, range 2,000 to 4,500, about SGD 182,000 a yearreplay estimate
what the proposed rule catches, 6-hour floor452 of 703 (64%), about 38 jobs a weekreplay estimate
what it takes from hiring managers0.6% of their picks on normal jobs, the same as today; 9.5% on short-notice jobsreplay estimate
what it adds on top of today, with the dropout re-selection and the largest switched-off outletabout SGD 130,000 to 175,000 a yearreplay estimate

The pages​

  1. Current metrics: what the selection step loses today, and on whose clock. The loss in jobs and credits, the companies and outlets that carry it, and two heat maps: when jodders apply and when hiring managers select.
  2. Problems: auto-select loses jobs because it looks once, at the wrong moment. The three buckets every miss falls into, two timelines that show the run against the applicants and against the manager, the reposting mechanism, four code defects, and the five rules in the code that bound any fix.
  3. Solution: select at each job's last safe moment, not at a clock time. The user stories, five rules with the code change beside each, the proposed timeline, the reasoning, the replay proof, what it does not fix, and the build order.
  4. Impact: what auto-select earns today, and what the change would add. Before and after auto-select at platform level, the one outlet that switched it off, and the options table with a combined range.
  5. Queries: the SQL behind every table and chart. Metabase-ready, with the shared definitions and the data traps.

Decisions the CTO has to rule on​

#decisionoptionsrecommendationowner
1The preparation floor: how long before the shift the last automatic selection may happen6 hours; 6 hours by default with an outlet setting down to 4; 3 hours6 hours by default, outlet may lower to 4. ACK1 closes 3 hours before the shift, so 3 hours has no margin. 4 hours lifts the catch from 452 to 492 of 703.CTO
2Night selections: 55% of the rule's selections fall between 00:00 and 06:59select at night; pull those selections to 21:59 the evening beforeDecide with ops. Night selections keep 452 of 703; the 21:59 variant keeps 359 at 2.5% of manager picks, with 12 hours' median notice.CTO with ops
3The day-before run and the short-notice run that shipped on 16 September 2026keep both beside the new rule; retire the short-notice run once the new rule is live; retire bothKeep the day-before run, it gives more notice to the jobs it catches. Retire the short-notice run once the new rule is live, it becomes redundant.CTO
4The four outlets that switched the flag offleave off; switch back on with the new ruleSwitch back on with the new rule. Changi Business Park alone has 123 reachable misses in twelve weeks, about 10 a week, and its own switch-off cost SGD 650 to 2,900 a month.ops with the accounts
5Order of workschedule change first; logging and the corrected metric firstLogging and the corrected metric first, one week. Today the result of every automatic attempt is thrown away, so nothing after it can be measured.CTO
6After a dropout: clone an empty job, or re-select at once from the parent job's applicantskeep the clone with no attempt; carry the parent's applicants to the clone and select at once; re-open the same job instead of cloningCarry the applicants and select at once now, inside the existing repost command. Re-open instead of clone later, it needs a status transition the system does not have.CTO
7The Metabase report on the legacy page, question 377, with monthly figures that no definition supportskeep quoting it; retire it; re-derive it with a stated definitionRe-derive it with the definitions on the queries page, then retire the old figures.data analyst

Where the work is tracked​

The implementation is tracked as an epic in the roadmap repository, Auto-Select Round 4: select at each job's last safe moment, jod-app/roadmap#80. It holds the five deploy phases, the child issues as they are created, and the done-when list. Round 3, the short-notice run and the per-job switch that shipped on 16 September 2026, is jod-app/roadmap#78.

Where the numbers come from​

The nightly copy of production, jodgig_ai, complete through 13 September 2026, queried through the JodGig Data connector. Two analysts measured the core numbers independently, one given only the timeline page and the code inventory, and got the same 703 misses, the same three-bucket split and the same ranking of schedules. Code facts are from the API repository at merge-prod, with file and line on the problems page.