Recruitment Tech · Subscription Model · Product Strategy

Atlas ATS

How I designed the subscription model and plan architecture for a new applicant tracking system — from market research through pricing and packaging to validated monetization.

Role
Expert/Senior Product Designer
Year
2025
Scope
Subscription Model Design ·
AI Agent Concepts
Industry
HR Tech / Recruitment · Enterprise
Confidentiality note. All company and product names are changed.
A job board losing its biggest clients

The company: A recruitment tech company running one of the largest job boards in its market — employers publish postings, candidates apply.

The problem: The free tool for managing applications was too basic. Bigger clients kept leaving for competitors with full applicant tracking systems.

The bet: Build a full ATS from scratch, with AI agents handling the repetitive work that eats recruiters' hours. Agents built into the daily workflow.

My job: Design how this product makes money — who pays, for what, when an upgrade makes sense, and how the packaging maps to real differences in how companies hire.

What I owned

I was the only designer working on how this product is packaged, priced, and sold. The business decisions were made together with product and business stakeholders — but I was the person who shaped them: surfacing the pain points, mapping the workflows, structuring the research that made the options concrete, and designing the flows that made each model testable. In a small expert team of senior product, engineering, and business people, I drove:

Subscription architecture
I researched how competitors segment plans and gate features, mapped real user workflows to understand where natural upgrade thresholds exist, and translated that into a concrete plan structure: which features go where, why, and how add-ons layer on top of the free tier.
Monetization mechanics
I designed the revenue model for both tiers: per-recruitment add-ons for free users, system-level subscription for Pro. I identified where in the user flow upsell surfaces should appear, based on friction points from the research.
Competitive analysis
Feature-by-feature breakdowns of three competitor ATS products, analyzing how they package, price, and convert free users into paying ones. This gave the team a real market map to make decisions against.
Prototype-driven validation
I built interactive prototypes of both entry flows and tested them with real users to validate the two-plan hypothesis before a single line of production code. When the team had competing opinions, I turned them into testable artifacts.
Sales-side validation
Joint presentations with the sales team to trusted clients, where I presented the plan architecture and collected direct feedback on willingness to pay and plan clarity.

I also owned the concept and interaction design for the AI agent layer — the features that make the subscription worth keeping.

Two segments, opposite mental models

The research gave me clear personas. They differ in how they think about hiring, and that goes deeper than feature lists.

The small company
Hires occasionally. One recruitment at a time, one job board, no dedicated HR team. They come to the product to publish a job posting. Everything else — the recruitment project, the application form, the candidate pipeline — should just appear around it.
The growing company
Has outgrown the defaults. They hire across locations and platforms, run multiple recruitments in parallel, and have people responsible for the process itself. They start by defining the recruitment: stages, team, permissions, forms. Job postings come later, as a consequence.

These two groups don't just need different features. They enter the product from opposite ends of the same flow. Forcing one entry point on both means one group always fights the interface.

This is why I designed two separate plans instead of one product with progressive upsells. The packaging follows the mental model, not the other way around.

Research-driven decisions

I grounded every packaging decision in three types of research:

Competitor analysis
Qualitative studies of three different ATS products, deliberately different in size, target clients, and approach. I mapped how each one structures its plans, what they gate behind paywalls, how they handle upsell, and where their packaging creates friction. A real map of the market instead of one reference point.
Internal interviews
Conversations with people who run recruitment every day — inside Atlas and at client companies. This is where I learned which tasks actually consume their time, which features they'd pay for, and where the current free tool breaks down.
Prototype testing
When the team disagreed on a direction — and specifically on whether two separate plans would work — we didn't settle by opinion. I built interactive prototypes of both entry flows and tested them with users.

The core of the project was a weekly workshop rhythm: the expert team spent several hours working through product strategy together. Between workshops, I explored specific topics — pricing models, feature placement, upsell mechanics — and brought conclusions back to the table.

Two plans, two entry points

The product launches in two versions. Both follow the same underlying flow — create the recruitment, define details, build the posting, set up the form, publish. The difference is who they're built for and where the user starts.

Plan 01 · Freemium
A mini ATS for small teams
Small companies hiring occasionally — one recruitment at a time, one job board, no dedicated HR team. They come to publish a job posting; the ATS appears around it.
Entry point: posting-first
The user goes straight into the posting creator. While they build the ad, the system quietly assembles everything else: recruitment project, default stages, application form, publication settings. When the posting goes live, a working ATS is simply there — the user never had to set it up.
What's included
  • Four fixed recruitment stages — set automatically,
  • Default application form,
  • Job board posting creator embedded in the interface,
  • Publishing to the domain job board only,
  • Candidates tied to the job posting — no standalone database.
Revenue model
Individual premium add-ons purchased per recruitment — time-limited features like form customization, extra stages, or extended candidate access. Low commitment, pay-as-you-go.
Plan 02 · Self-Service | Pro
Full control for growing companies
Companies whose recruitment has outgrown the defaults — hiring across locations and platforms, running many recruitments in parallel, with people responsible for the process itself.
Entry point: recruitment-first
The user starts by creating the recruitment: defining stages, team, permissions, customizing the application form. Only then do they build job postings and decide where each one publishes — which boards, with which content, tracked per source. The posting is a consequence of the recruitment, not the other way around.
What Self-Service adds
  • Multipublishing across many job boards, with tracked links per platform,
  • Fully customizable application form,
  • A real candidate database — candidates persist beyond a single posting,
  • Recruitment templates,
  • Advanced reporting across all projects,
  • Confidential recruitment and candidate shortlists,
  • System-level add-ons — bought once, applied to every project,
  • Full automation of all of the above.
Revenue model
Monthly subscription unlocking system-level capabilities. Features bought once, applied across every recruitment project.
Creation flows — free vs. Pro, two different starting points
Creation flows — free vs. Pro, two different starting points
Why each feature lands where it does

The split between free and paid isn't arbitrary. Every feature placement follows a logic:

Default form is free. Customization is a paid add-on.
Internal interviews showed most small companies never customize the form. Competitor analysis showed it's one of the highest-converting add-ons. I proposed per-recruitment pricing: high intent, low friction.
ADD-ON
Candidate database is Pro-only.
From workflow mapping: small companies tie candidates to one posting, growing companies need them across projects. The feature gates itself — by the time you need it, you've outgrown the free plan.
PRO ONLY
Multipublishing is Pro-only.
Every competitor I analyzed gates this behind a paid tier. Our data confirmed it — small companies post to one board. I positioned it as both a Pro feature and the primary upgrade trigger.
PRO ONLY
Recruitment templates are Pro-only.
Identified during workflow mapping: templates only matter when you repeat the same setup. Repeat hirers are the Pro segment by definition.
PRO ONLY
When and where upgrade moments appear

I designed upsell triggers around natural friction points — moments where the user's need has outgrown the free plan, and the system can show them what's on the other side.

01
During form setup
When a free user tries to add a custom question to the application form, the system shows the add-on — a single-click purchase for this recruitment. No page redirect, no checkout flow. The upgrade happens inside the task.
02
After the first posting
When a free user publishes their first job ad successfully, the system suggests multipublishing. The user has just completed the core flow and has momentum — the highest-intent moment to introduce expansion.
"Want to reach more candidates? Publish to additional boards."
03
At candidate volume thresholds
When a free user accumulates candidates across multiple recruitments, the system surfaces the candidate database. The trigger is behavioral — tied to what the user does, when they need it.
"You have X candidates from past recruitments. Want to keep them in one searchable place?"
04
In reporting gaps
Free users see basic stats. When they look for cross-recruitment comparisons or source tracking, the system shows what Pro reporting looks like — previewed with their own data.
Each upsell surface follows the same principle: show the upgrade when the user hits the limitation. Too early — it feels like an ad. At the right moment — it feels like the system understands what they need.
Free plan add-ons — time-limited premium features purchasable individually
Subscription upsell screen — feature cards prompting an upgrade
Individual premium add-ons sold on top of the free plan (left) and pro-only capabilities surfaced as upgrade prompts (right).
AI agents as the retention engine

The subscription model only works if users keep coming back. The AI agent layer is what builds that habit.

Every agent I designed started from a documented pain point — hours lost to preselection, inconsistent notes, manual republishing. The agents that didn't survive the workshop process were the ones where the automation was technically possible but the recruiter didn't actually need it.

01
AI scoring
Ranks candidates by form answers. Consistent scoring, recruiter sees priorities first.
02
Finding candidates fast
Search and filter across all projects with the agent's help.
03
Automatic actions
Triggers routine steps after key events — e.g. structured notes after an interview.
04
Intake Agent
Recruiter describes a position in plain language. Agent creates the project, posting, and form.
05
CV standardization
Extracts skills, experience, education from any CV format into one consistent structure.
06
HR assistant
Answers questions about a CV on demand — no re-reading the document.
07
Publication agents
Adapts postings per job board, tracks what's live and what expires.
Candidate profile with AI-generated match summary, notes, and skills
A fragment of a comparable system — candidate profile with AI-generated match summary, interview notes, and skills.
The pattern across all agents: they create compounding value. The more you use the system, the more the AI has to work with, and the harder it is to switch away.
Atlas ATS interface with Home screen, agent shortcuts, and latest updates
A sampling of agents displayed here
What the numbers showed

I validated the subscription model across three channels: prototype testing with end users, sales presentations to trusted clients, and task-completion benchmarks with AI agents. Because the product hadn't launched yet, I couldn't measure revenue or conversion in production. Instead, I used behavioral validation metrics to de-risk the monetization model before development

70%
of trusted clients presented with both models by the sales team said they'd pay for extended capabilities. Joint sessions where I presented the plan architecture and the sales team collected feedback on willingness to pay and plan clarity.
100%
of test participants correctly identified when their needs outgrew the free plan — the upgrade trigger worked without explanation. Tested with an interactive prototype where users performed realistic hiring tasks across both plans.
89%
of recruiters in our research said the Pro model would significantly speed up their daily workflow. From internal interviews with people running recruitment daily.
3.2×
faster task completion in prototype tests when AI agents handled preselection and note-taking versus the manual process. This validated the agent layer as a real value driver for the subscription.
What this project taught me
Two plans is a design decision
The split into freemium and self-service came from understanding that two segments think about hiring in opposite directions. The business model followed the mental model.
Validate before you build, even when the team agrees
The posting-first vs. recruitment-first split felt obvious internally — but we still prototyped and tested it. Two assumptions we were confident about turned out to need adjustment. Agreement in the room is still an assumption until tested.
AI features need a retention argument
Every agent we shipped solves a real problem. The ones that justified their place in the subscription were the ones that created compounding value — the more you use them, the more they give back. That's what makes a feature worth paying for monthly.