Scalable Workflows

01Configurable pipeline stages, per job

The default pipeline is seven stages — applied, screening, shortlist, interview, offer, hired, rejected — but this isn't fixed globally. Each job can define its own stage sequence, so a high-volume retail hiring push can add extra screening gates while a single executive search can strip down to just applied, interview, and offer. The configuration lives on the job, not on some separate settings page disconnected from the specific role it applies to.

02Role-based permissions

Four roles — owner, admin, recruiter, and hiring manager — each see and can do a deliberately different slice of the product. A hiring manager can move candidates and leave feedback on the roles they're hiring for without needing admin access to billing or team management; recruiters manage their pipelines without the ability to change organisation-wide settings. This matters more as a team grows past the point where everyone reasonably needs full access to everything.

03Batch operations at volume

Scoring every candidate in a pipeline individually doesn't scale past a handful of applicants. A single action re-scores every unscored application for a job in one pass, respecting the organisation's monthly AI-scoring credit allowance and resuming cleanly if interrupted partway through — useful for a role that received two hundred applications over a weekend and needs a ranked shortlist by Monday morning.

Bulk candidate and job creation follow the same philosophy: up to 100 jobs can be created from a single CSV upload, and candidates can be added in bulk via CSV, a pasted JSON array, or by dropping a batch of CV files directly, each parsed and added to the talent pool automatically. None of these bulk paths bypass the same validation and deduplication logic the single-record forms use — a duplicate email in a bulk CSV import is skipped exactly the way a duplicate manual entry would be.

04What doesn't change as volume grows

The underlying scoring methodology, the audit trail on every application, and the permission model don't behave differently at 10 applications versus 10,000 — there's no separate "enterprise mode" with different guarantees. What scales is the plan tier's seat count, active-job limit, and monthly AI-scoring credit allowance, not the mechanics of how scoring or permissions work underneath.

05What typically breaks first as a hiring team grows

Teams moving from a couple of recruiters to a larger talent acquisition function tend to hit the same few friction points, independent of which tools they're using. Pipeline visibility is the first: once more than two or three people are moving candidates through the same job's pipeline, someone inevitably asks "wait, who moved this candidate and when" — which is why every stage change is timestamped and attributed by default rather than as an optional audit feature bolted on later.

Inconsistent evaluation across recruiters is the second, closely related to the drift problem described on the Structured Hiring page — two recruiters screening the same role with slightly different mental criteria produce a pipeline that looks consistent on the surface (same stages, same board) while actually applying different bars. And credential sprawl is the third: as a team grows, the gap between "everyone has full access because it was easier when we were three people" and "we actually need role-scoped permissions" tends to arrive suddenly, usually right after an access-related mistake rather than proactively — which is why the role-based permission model exists from day one rather than as an upgrade path a growing team has to remember to configure later.