Build an ATS business case your team can check.

An ATS business case starts with a decision about recruitment work. Name the process that is failing, the people who spend time repairing it, and the change you want them to make. A growing team may need a shared candidate record because recruiters reconstruct conversations before every handoff. Another team may need clear stage ownership because interviews happen but feedback arrives too late for the decision meeting.

Write the problem using one recent vacancy. Record who coordinated the interviews, how they found the latest candidate reply, where feedback was stored and who chased the missing contribution. Keep personal candidate information out of the business case. The operational sequence and the time spent are enough to describe the problem without copying private records into a procurement document.

Decide what the purchase covers before estimating a return. An ATS proposal might include recruitment workflow, candidate communication and interview coordination. Onboarding orchestration or ongoing employee learning needs its own scope and owners. A business case that quietly adds every people process makes implementation harder to estimate and makes the proposal difficult to challenge.

Choose a representative period and include more than your busiest week. Record the number of active vacancies, completed hires, interview bookings and feedback follow-ups. Use counts that the recruitment team can reproduce from its current records. If the team cannot reconstruct a number reliably, mark it unknown and explain how you will measure it during a pilot.

Keep elapsed time and working time separate. Three days waiting for an interviewer is elapsed time. Twenty minutes writing reminders is working time. The same twenty minutes must not also appear as interview coordination and reporting effort. Give each measured activity one owner and one category so the Finance reviewer can see where the total comes from.

Use a small activity log rather than asking people to remember a quarter of administration. For each observation, capture the activity, date, minutes, role and evidence location. Capture recurring work that a proposed workflow can plausibly change. Leave productive interviews and deliberate hiring decisions out of the recoverable administration total. Software still needs people to interview, review evidence and decide.

Describe at least three choices: keep the current process, improve it without a new system, or introduce an ATS. The second choice deserves a real plan. It might mean one shared tracker, agreed stage names, a feedback deadline and a named recruiter for each vacancy. Estimate the effort needed to maintain that arrangement as carefully as the effort needed to run new software.

Record what each option can resolve and what it leaves open. A shared tracker may make ownership clearer while candidate communication stays in individual inboxes. An ATS may bring records together while the team still needs to agree its interview criteria and escalation rules. Keep the comparison tied to observed work, rather than scoring a long feature inventory that nobody has asked to use.

Do not turn the current process into a deliberately weak opponent. If it works at the present hiring volume and has a named owner, say so. A purchase may be premature. The business case can recommend a measured pilot or a process repair before a contract. That decision still gives the executive team an accountable plan and a date to review the evidence.

Ask for a written commercial scope and price before presenting a purchasing recommendation. Include the subscription, the users or other billing units it depends on, and any agreed setup, support, integration or service costs. Record currency, tax treatment, contract term and the date of the quote. Use the quote as the source; a public starting price is not a complete implementation budget.

Add internal transition effort. Someone must define stages, review records, clean duplicates, agree access, test communication, train users and support the first vacancies. Assign hours to the people doing that work and make the workload visible beside other commitments. An external migration fee does not eliminate internal preparation or acceptance testing.

List displaced costs only when the team can actually stop paying them. A contract that continues through the first year remains a cost in that year. A reporting tool used by another department cannot be treated as removed because recruitment no longer uses it. Keep one-time and recurring amounts separate so reviewers can compare the first year with a later steady-state year.

Calculate recovered annual administration capacity as measured weekly hours multiplied by working weeks and the proportion of that work the proposed process could remove. Then multiply those hours by a Finance-approved loaded hourly cost if you need a value for comparison. Record the source of the hours and cost, and label the removal proportion as an assumption until a pilot measures it.

Recovered capacity does not automatically become money available to spend. The same people may use those hours for candidate communication, stronger interviews or other recruitment work. Describe what the team will do with the time. Recognise a cash saving only when an expense or planned payment actually disappears and Finance accepts that treatment.

Keep vacancy delay, agency spending and error correction outside the basic capacity model unless you have separate evidence. Hiring speed depends on role requirements, candidate availability, interview decisions and many other factors. Do not attribute every faster hire to an ATS or count the same delay benefit in several rows. An unmeasured benefit can remain a reason to test, without becoming a number in the approval total.

The following arithmetic is an illustration, not a customer result or a CapoFine savings claim. Suppose a team records six hours of eligible recruitment administration per week, uses forty-six working weeks, and assumes that a tested workflow could remove one quarter of those hours. The calculation is 6 × 46 × 0.25 = 69 hours of annual capacity.

If Finance supplies a hypothetical loaded cost of €40 per hour, the comparison value is 69 × €40 = €2,760. Suppose the quoted subscription is €3,000 per year and the team estimates twenty internal setup hours at the same illustrative rate. The first-year cost is €3,000 + (20 × €40) = €3,800. These inputs do not support a first-year approval on recovered administration capacity alone.

At a ten-percent removal assumption, the model yields 27.6 hours and €1,104 of capacity value. At forty percent it yields 110.4 hours and €4,416. Keep all three scenarios beside the €3,800 first-year cost. Even the upper scenario describes capacity rather than a guaranteed cash return. Replace every example input with a checked team measurement or quote before using this model for a purchasing decision.

Use the downloadable Excel workbook to edit the assumptions and recalculate capacity, first-year cost and the removal-rate comparison. It contains clearly labelled hypothetical example amounts and working formulas, not customer data, CapoFine pricing or a savings promise. Add the evidence location and named owner for each input. Keep private candidate records in their existing access-controlled system and reference the aggregate evidence rather than embedding those records in the business case.

The decision section needs the proposed scope, the hiring problem, current process owner, alternative considered, approval requested and review date. The baseline section needs the measurement period, vacancy volume, eligible weekly administration hours, working weeks and confidence in those inputs. The cost section needs the quote date, recurring price, internal setup hours, internal cost basis, external setup and any overlapping contracts.

Add separate fields for the assumed removal proportion, recovered capacity, proposed use of that capacity and any independently evidenced cash saving. Give uncertainties their own row. An unknown migration effort or unresolved calendar setup deserves an owner and a next action. Do not replace an unknown with zero to make the proposal easier to approve.

Finish with a decision record. State whether the recommendation is to proceed, run a pilot, repair the present workflow or defer. Name the decision maker and the conditions for moving to the next step. A reviewer should be able to reopen the document later and understand which evidence changed, who accepted it and why the scope stayed within the team’s capacity.

Select one recruitment workflow with a named recruiter and hiring manager. Agree what the pilot will include, how long it will run and which events you will observe. A role that needs interview coordination and several feedback contributions can reveal whether the team can find the next action and its owner without rebuilding the candidate story.

Measure the same activities before and during the pilot. Record working time spent on coordination and follow-up, whether required feedback was available for the debrief, and whether the recruiter could find the candidate context they needed. Record failures and exceptions as well as successful steps. Do not compare a complex specialist vacancy with an unrelated straightforward role and call the difference a product effect.

Agree the stop conditions in advance. The pilot might stop if records cannot be reconciled, if an essential workflow remains unresolved or if implementation consumes more time than the team can commit. The result might support a smaller scope than the original proposal. Give the decision maker the measured baseline, pilot observations and remaining uncertainties before asking for a broader rollout.

Give the recruiter ownership of the daily workflow, the hiring manager ownership of role criteria and decisions, and an implementation owner responsibility for configuration and acceptance. Ask the appropriate internal specialists to review access, data handling and connected services. The business case should identify those reviewers and their open questions without claiming that buying software resolves their obligations.

Before moving records, define which information is needed, which records should remain in the old system, who can see them and how the team will verify the result. Check representative records and a complete recruitment path before relying on the new workflow. Any retention, privacy or contractual requirement needs the organisation’s own decision and qualified advice where appropriate.

Plan what happens when the workflow fails. Recruiters need a person to contact, a way to recover the relevant context and a rule for recording exceptions. Include that work in the transition plan. Training should cover the tasks people will actually perform, such as finding the next interview, adding post-interview feedback and handing the record to the next owner.

Hire supports configurable hiring stages, candidate ownership, candidate communication, interview scheduling and structured feedback after interviews. These are mechanisms to inspect against the workflow in your business case. Scorecards organise interview evidence; recruiters and hiring managers retain the hiring decision. Product configuration and package availability should be confirmed against the scope you are evaluating.^[1]

Bring one representative vacancy and the questions the baseline exposed. Ask how the team finds the current stage, the latest candidate communication, the next interview and the outstanding feedback owner. Follow the handoff rather than accepting a demonstration of isolated screens. Record which requirement was demonstrated, which needs configuration and which remains unconfirmed.

Take the editable Excel workbook to your next conversation with Talent Acquisition and Finance. Fill the measurement period and cost sources first. Then agree the pilot owner, the workflow to test and the date when the decision maker will review the evidence. Keep the purchasing recommendation open until those inputs support it.