Lever vs Ashby: Choose Your 2026 Recruiting System

The short answer

Lever and Ashby are both recruiting platforms that combine applicant tracking with candidate relationship management, but they put different operational questions at the center of the buying decision. Lever is the stronger fit for teams that want a unified ATS and CRM with reporting, integrations, and onboarding in one commercial package. Ashby is the stronger fit for teams that want highly configurable recruiting workflows, analytics, scheduling, sourcing, and structured data in a connected system.

An applicant tracking system is the system of record for requisitions, candidates, interviews, decisions, and hiring outcomes.

Choose Lever when recruiter adoption, candidate relationship management, and a familiar all-in-one operating model matter more than deep workflow design. Choose Ashby when your team needs to shape the operating model around detailed fields, reports, interview plans, stage automation, and hiring-plan analysis. Neither decision should rest on a feature checklist alone: the deciding issue is who will own configuration, governance, reporting definitions, and exceptions after launch.

Independent review data can be a directional input, not a verdict. G2 lists Ashby at 4.7 out of 5 from 108 reviews and Lever at 4.3 out of 5 from 2,114 reviews, according to G2. The uneven review counts mean that score comparison is less useful than evaluating your own workflow, data, and implementation constraints.

Key Takeaways

• Lever is a practical choice for teams prioritizing a combined ATS and CRM with packaged reporting and integrations.

• Ashby is a practical choice for teams that need more control over recruiting data, workflows, analytics, interview structure, and scheduling operations.

• Ashby publishes a starting monthly price for its Foundations plan; Lever publishes quote-based pricing.

• Both systems require deliberate ownership of fields, stages, integrations, permissions, and reporting definitions.

• A switch can create more operational risk than benefit when the current ATS already covers the core process and the real gap is process discipline.

• Automation should route work and preserve evidence, while people retain approval over interviews, offers, candidate messaging, and exceptions.

How we evaluated these tools

This comparison weights the decisions that tend to affect a talent acquisition leader after the purchase: whether the platform fits the hiring process, whether the data can support management reporting, how much configuration ownership is required, and how clearly procurement can model costs. The weights are an analysis framework, not a vendor score.

The category matters because recruiting leaders are under pressure to make process time visible. SHRM’s 2025 benchmarking report drew on more than 2,300 members and found a median time-to-fill of 45 days for both executive and nonexecutive positions, according to SHRM. Median time-to-fill: 45 days according to SHRM (2025). A platform cannot fix every hiring delay, but it can make handoffs, aging, interview bottlenecks, and approvals visible.

The side-by-side feature matrix

The normalized matrix is intentionally not a winner chart. Both vendors describe broad ATS, CRM, reporting, and integration capabilities. The sharper distinction is where your team expects variation. Ashby’s public plan comparison describes configurable candidate, job, and project fields, structured interview plans, automation, analytics, API access, and a marketplace with 250+ integrations. That matters when recruiting operations regularly changes intake questions, approval paths, interview design, or reporting cuts.

Lever’s public pricing overview describes an AI-powered hiring platform with ATS and CRM capabilities, reporting, analytics, integrations, and onboarding. That matters when the buying team wants one platform that is easier to explain to hiring managers and less dependent on custom operating design. A good evaluation workshop should use your actual requisition, candidate, offer, and reporting flow rather than generic vendor demonstrations.

Price, procurement, and total-cost questions

Pricing checked October 12, 2026.

Ashby’s Foundations plan is listed at $400 per month for organizations with up to 100 employees, and the pricing page states a 10% annual-commitment discount. Its Plus plan is positioned for 101–1,000 employees and Enterprise for 1,000+ employees, according to Ashby. Published Ashby starting price: $400/month (2026).

Lever does not publish a dollar price on its pricing page; it says pricing is available upon request and tailored to organization size and hiring needs, according to Lever. Treat Lever as quote-based in a business case rather than importing a marketplace estimate, an old contract price, or a peer’s number.

The license is not the full cost of either choice. Add implementation services, data cleanup, integrations, security review, administrator time, training, reporting redesign, API management, and the cost of running parallel systems during migration. For Ashby, ask whether scheduling, analytics, sourcing, and security features required by your process are in the proposed package. For Lever, ask for the specific scope of ATS, CRM, reporting, onboarding, integrations, support, and implementation assumptions in the quote.

A procurement model should keep vendor fees separate from internal labor. It is easy to call administrator time “free” because it is already in a salary budget, then discover that recruiters and operations staff are carrying manual exceptions for months. The cleaner question is: which platform makes your intended process easier to operate with the staff you actually have?

What each platform is built to make easier

Lever profile: operational simplicity around ATS and CRM

Lever is best for talent teams that want candidate relationship management and applicant tracking together, while retaining packaged reporting and broad integration options. Its commercial positioning is useful when the team does not want to compose a recruiting stack from many specialized tools. Recruiters can keep candidate activity, sourcing context, and hiring movement in the same operating environment instead of treating CRM as a separate project.

The limitation is that a unified system still needs governance. “Easy to use” does not resolve duplicate candidate rules, source taxonomy, required feedback, hiring-manager access, consent handling, or the definition of an accepted offer. If your team has many conditional pipelines, business-unit-specific reporting rules, or nonstandard interview designs, validate each scenario in a scoped proof before committing.

Implementation should begin with a process inventory: requisition creation, posting approval, application review, interview scheduling, feedback completion, offer approval, close reasons, and HRIS handoff. Decide which fields are required at each step and which reports will be used in leadership meetings. That turns a platform implementation into an operating-model project rather than a record migration.

For integrations, Lever’s API credential documentation says Super Admins can generate scoped credentials and identifies API access across Lever Basic, LeverTRM, and LeverTRM for Enterprise; Lever Basic includes Postings API access only, according to Lever. Documented Lever API release: Summer 2024 (2024). Confirm the required API package, endpoint permissions, and data-retention implications before promising downstream automation.

Ashby profile: configurable recruiting operations and analysis

Ashby is best for teams that see recruiting operations as a designed system: structured intake, customized data, stage-specific automation, interview plans, scheduling rules, source analysis, and leadership reporting. Its all-in-one scope can reduce the number of disconnected recruiting workflows when the team is prepared to define how the system should behave.

The limitation is the same strength viewed from the other side. More configuration choices create more decisions about owners, change control, naming, reporting logic, exceptions, and training. An organization without a clear recruiting operations owner can reproduce inconsistent processes more quickly rather than solve them. Teams should identify an administrator with authority to protect data definitions and approve configuration changes.

Implementation should start with the reporting questions leadership actually needs answered: which roles are aging, which stages create delays, which sources produce qualified candidates, where interview feedback is missing, and where offers stall. Build the requisition and candidate data model around those questions. Then configure workflow rules, notifications, permission boundaries, and dashboards around the agreed process.

Ashby’s public developer documentation says the applicationUpdate webhook fires when an application changes, including changes to application fields and job transfers, and expects a 200 response when data is received, according to Ashby. Webhook success response: HTTP 200 (2026). That is useful for integration design, but it also means the team must specify retry handling, error ownership, and what downstream systems may receive candidate data.

Who this is for

This comparison is for a talent acquisition lead with a real selection decision, a defined recruiting process, and access to the people who own HRIS, identity, data privacy, finance, and hiring-manager enablement. It is especially useful when the current ATS creates friction around reporting, sourcing, scheduling, candidate records, or cross-system handoffs.

Red flags: no named system owner; no documented data-retention or candidate-consent policy; no agreement on which reports leadership will use.

Choose Lever if your priority is a combined ATS and CRM operating model that recruiters and hiring managers can adopt without turning every process decision into a configuration initiative. It can be the more sensible choice when the team values a broad core platform and wants to limit the number of systems involved in everyday recruiting.

Choose Ashby if your team needs recruiting data and workflows to reflect more detailed operating rules. It is especially worth evaluating when analytics, configurable processes, sourcing, structured interviews, and scheduling all need to work from the same record model.

Consider keeping your existing platform if the central problem is unclear ownership, delayed feedback, inconsistent intake, or low hiring-manager participation. Replacing the software will not create those disciplines. For adjacent reading on ATS workflow decisions, see automating Greenhouse versus Lever for recruiting firms and why recruiting teams chase reference checks before offer stage.

A worked planning example

Here is an illustrative planning scenario, not a benchmark: a team opens 12 roles, expects 8 interviews per role, and assigns 2 coordinators to validate 96 interview events in a month. If each manual validation takes 6 minutes, that is 576 minutes, or 9.6 coordinator hours. A proposed workflow could listen for Ashby’s applicationUpdate event, place only qualified scheduling records in a review queue, and avoid calling application.update automatically; the math does not claim a realized time saving, because the actual workload depends on calendar complexity, stage rules, and exceptions.

A proposed US Tech Automations workflow could begin when a candidate reaches a defined interview-ready stage. The action would validate required fields, create a reviewable coordination task, and write a dated exception record when an interviewer, availability window, or consent requirement is missing. The output would be a queue for a coordinator, not an automatic candidate message. This configuration requires authorized API or export access, documented stage names, a designated queue owner, and human review before any external communication or offer-related action.

A second proposed US Tech Automations workflow could run after a requisition changes status. It could compare the ATS record with an approved headcount export, flag mismatched department, location, or approver fields, and produce a weekly reconciliation file for recruiting operations. The design should not alter requisitions automatically unless the organization explicitly authorizes that behavior. A human owner reviews exceptions, resolves the source record, and approves any policy changes.

No-code, custom build, or an operational workflow layer

Zapier, Make, n8n, and an in-house integration can all be reasonable choices. When configured well, they can provide run histories, retries, error branches, and audit evidence. They can be the lowest-friction option for a narrow, stable integration such as copying a completed assessment status into an ATS field or sending an approved report to a shared internal channel.

The trade-off is ownership. The buyer must design and maintain observability, idempotency, escalation rules, access controls, error recovery, data retention, and change management. A workflow that triggers twice after a retry can create duplicate tasks or conflicting updates unless it has a durable event key and a reconciliation path. A workflow that silently fails can make recruiter workload look like a people problem rather than an integration problem.

A proposed US Tech Automations design can configure those controls around the recruiting process: event IDs are retained for duplicate protection, failures enter an owned exception queue, sensitive fields are minimized, and manual approvals remain visible. It still needs vendor API or export access, a documented data map, a security-approved credential model, and recurring human review of errors and policy changes. That is not a replacement for an ATS; it is a way to make agreed cross-system work more observable.

When NOT to use US Tech Automations

When NOT to use US Tech Automations: use a simpler native rule, report, or direct integration when it already solves the problem, when the workflow has no stable owner, or when your organization cannot provide authorized API/export access and a human reviewer. A custom operational layer adds value only when there is a repeatable cross-system process worth governing. It should not be used to automate candidate messaging, hiring decisions, or policy exceptions without accountable human review.

Decision checklist before signing

Run the checklist using one real requisition and a representative candidate journey. Include an active sourcing prospect, an applicant who requires scheduling, an interviewer with a conflict, a rejected candidate, an offer approval, and a hire handoff. This reveals more than a polished product tour because it forces the team to name records, owners, exceptions, and evidence.

For broader operating guidance, talent teams can also review reference-check workflow risks and automation evaluation ideas for agencies. The point is not to copy another team’s stack; it is to establish where a system must preserve judgment, privacy, and accountability.

Frequently asked questions

Is Ashby better than Lever?

Neither platform is universally better; Ashby tends to fit more configurable recruiting operations, while Lever tends to fit teams prioritizing a unified ATS and CRM model.

Your process complexity, reporting expectations, security requirements, implementation capacity, and commercial scope should decide the outcome. Ask each vendor to demonstrate your actual hiring path and reporting questions.

Does Lever publish pricing?

No, Lever’s pricing is quote-based.

Its pricing page says the commercial model is tailored to organization size and hiring needs. Request a written scope that separates subscription, implementation, integrations, support, and any optional services.

What does Ashby cost?

Ashby lists its Foundations plan at $400 per month for organizations with up to 100 employees.

The public page positions Plus and Enterprise as quote-based offerings, so a complete comparison needs the vendor’s current proposal and any required add-on assumptions.

Can either tool replace a recruiting CRM?

Both can support CRM activity, but the right answer depends on how your team sources, segments, nurtures, and re-engages candidates.

Map your talent pools, outreach governance, recruiter ownership, consent rules, and reporting needs before assuming that any single CRM feature solves the operating problem.

Should we build integrations before choosing an ATS?

No, choose the ATS operating model first and design integrations around approved records, fields, owners, and exception paths.

Early integration work often hardens assumptions about stages or data that change during implementation. Start with a data inventory and a small controlled workflow once the system of record is settled.

The decision to make

The best Lever versus Ashby decision is the one that makes your recruiting process clearer after implementation. Pick Lever if your organization wants an integrated ATS and CRM experience with a simpler operating posture. Pick Ashby if your team can benefit from deeper configuration across recruiting data, analytics, workflow, and scheduling and is willing to own that design.

Do not ask which vendor has more features in isolation. Ask which system makes your required process easier to run, audit, explain, and improve six months after rollout. For a proposed workflow that connects approved recruiting records to controlled review queues and exception reporting, see how US Tech Automations configures recruiting operations.