ATS implementation guide: Plan your first rollout.

Start your ATS implementation with one hiring workflow that the team already understands: a vacancy, an application, recruiter review, an interview, recorded feedback and a human decision. Describe where information sits today and who picks up each handoff. Use the ATS requirements checklist to settle buying requirements before turning them into configuration tasks.

Greenhouse’s implementation guidance separates basic configuration, foundational hiring practices, data migration readiness and preparation for launch. It includes permissions, privacy, career pages, calendar setup and training. These are useful workstreams to consider, but its documentation describes Greenhouse rather than a universal schedule or a promise about another supplier.^[1]

This guide offers an original planning method for lean Talent Acquisition and People Systems teams. The 30-day and 60-day paths are illustrative planning windows, not delivery guarantees. A narrow workflow with available owners may fit the shorter path. Unresolved data access, supplier dependencies or internal approvals require more time. Keep the launch decision tied to evidence, even when the target date changes.

Name a recruitment lead who owns the operating workflow and a People Systems lead who coordinates configuration and evidence. The hiring manager approves the interview stages and feedback expectations. IT owns identity, mailbox and calendar prerequisites. The appropriate privacy or security reviewer approves the data and access scope. An executive sponsor resolves blocked decisions and approves expansion. In a small team one person may hold several roles; record which decision each role controls.

Give the supplier a named contact and ask who handles migration, configuration questions and support during cutover. Confirm the contracted scope, any implementation charge and the customer effort required. A supplier can explain a product setting, while your team decides whether that setting meets its process. Keep unresolved questions with an owner, a due date and the consequence of leaving them unanswered.

Use one decision record in your existing project tool. For every launch requirement, record the expected behaviour, who checks it, the observed result and the remaining dependency. Separate demonstrated behaviour from an assumption or promise. An accepted temporary workaround needs a person who will carry out the work and a date for review. Do not mark a requirement ready merely because its configuration task is closed.

Use this path when the first vacancy is agreed, the necessary accounts are available and the data scope is small enough to inspect. The four windows below describe activities and exit decisions. They do not estimate supplier delivery time. Confirm availability with each owner before attaching calendar dates. If an exit decision fails, carry the unresolved item into a revised plan rather than compressing the next phase.

During days 1 to 7, the recruitment lead documents the present workflow and approves the pilot vacancy. People Systems lists the data to move, the accounts needed and the dependencies. IT confirms the proposed mailbox, calendar and identity scope. Finish the week with an agreed pilot, named owners and a short launch checklist that explains what would stop the team from opening applications.

During days 8 to 14, configure the stages, application questions, interview feedback and candidate messages needed for the pilot. Prepare synthetic records and test the candidate-to-recruiter path. During days 15 to 21, rehearse with the recruiters and hiring manager, check access boundaries and resolve errors. During days 22 to 30, make the cutover decision, launch the approved vacancy and review actual handoffs. Keep a daily support owner during the first hiring activity.

The longer plan creates room for dependencies that cannot be resolved inside a small pilot. Examples include several teams with different hiring stages, a historical data review or a required connection that needs separate approval. Extending the plan should make the dependency visible. Avoid filling the extra month with features that have no accountable launch owner.

Use days 1 to 15 to confirm requirements, decision owners, migration scope and contractual dependencies. During days 16 to 30, configure the first workflow and inspect sample records with the data owner. During days 31 to 45, rehearse candidate applications, recruiter communication, interviews and access boundaries, then train users with the same workflow. Reserve days 46 to 60 for approved cutover, support and a decision about the next team.

Keep separate acceptance decisions for the pilot and wider rollout. A successful vacancy does not demonstrate that every department’s process is ready. If another team needs different access or feedback, repeat the relevant checks before adding it. Review unresolved integration questions with IT and the supplier. The buying group can approve a manual pilot process when appropriate, but should record its effort, limitations and expiry rather than silently treating it as the final design.

List the active jobs and candidate records required to continue the selected workflow. Name the source, destination field, record owner and check for each piece of information. Inspect a small approved sample before moving the agreed set. Keep the current stage, next action and relevant communication distinguishable. A total record count cannot show whether a candidate is connected to the right vacancy or whether an attachment remains readable.

Workable’s migration documentation describes a scoped statement of work, stage mapping and verification of a sample import where applicable. Its process also asks customers to coordinate activity on the old ATS before handing over data. Those are supplier-specific details that illustrate why migration scope and cutover arrangements need explicit agreement. Ask your selected supplier which method applies to your records.^[2]

Give historical records a separate decision. Your organisation’s responsible reviewers should determine retention, permitted use and deletion handling before migration. Keep uncertain or unnecessary records outside the pilot until that decision is made. This guide does not set a legal retention period. A duplicate, missing attachment or withdrawn candidate should have an agreed handling path and owner. Detailed source-to-destination migration work can remain a separate project without blocking a properly scoped new-vacancy pilot.

For each stage, write the condition for entry, the person who owns it and the next action. For example, an interview stage may require a booked time, the correct panel and feedback from the agreed interviewers. Keep stages distinct from reminders. A reminder can prompt work, but the recruitment owner still needs to know who resolves an unanswered message or a missed interview.

Review the application questions against the actual vacancy. Ask a candidate representative to follow the application on the intended devices, check the required fields and locate the confirmation. Rehearse a correction and an interrupted application where the offered product supports it. Keep objective job requirements separate from interview feedback. The hiring manager remains responsible for interpreting evidence and deciding how the candidate proceeds.

Test communication with approved synthetic accounts in an authorised test setup. Confirm the sender, recipient, message content and connection to the candidate record. Include an inbound reply and a changed interview time in the rehearsal if those operations are in scope. Do not contact real candidates merely to test configuration. Before enabling a reminder or rule, confirm when it starts, who receives it and how the owner stops or corrects it.

For every proposed connection, name the exact operation needed by the pilot. Calendar access, interview links, mailbox replies and a later employee handoff are different operations. Ask for evidence using the intended account roles and package. Record any provider approval, customer administrator action or supplier work still required. A connection shown on a website does not establish that your tenant and account have completed those steps.

Check what a recruiter, hiring manager and an account outside the vacancy scope can see and change. Use fabricated candidate details when rehearsing access. Have the appropriate internal owner inspect the permitted view and the excluded view. Confirm the support route if an account loses access during a live interview. Restrict launch readiness to the operations actually observed rather than declaring the whole integration complete from one successful sign-in.

Include practical accessibility checks in the candidate and user rehearsal. W3C’s preliminary guidance covers issues such as headings, keyboard access, contrast and form labels. It explicitly warns that these checks are limited and that passing them does not establish comprehensive accessibility. Use them to identify obvious barriers, then involve the reviewer needed for your organisation’s wider evaluation. Record platform and employer-authored content issues separately.^[3]

Consider a hypothetical 180-person company introducing an ATS for one support vacancy. Its recruitment lead wants every application attached to the vacancy, a named recruiter for follow-up and interview feedback available before the debrief. People Systems prepares five synthetic records covering a new application, an incomplete record, an interview change, a withdrawn application and a duplicate. These are planning examples, not customer results or a recommended test sample size.

For the new application, the recruiter checks the vacancy, original attachment and next-action owner. For the interview change, the coordinator checks the revised time and relevant messages. The hiring manager records post-interview feedback using the agreed criteria. The access reviewer checks a manager assigned to the vacancy and an account outside its scope. Each owner records what they observed, the account role and the evidence location.

Suppose the rehearsal reveals that the interview is updated but the coordinator cannot establish whether the candidate received the corrected details. Keep that check unresolved. Assign the connection or communication question to its owner and repeat the scenario after it is addressed. If the team chooses an approved manual confirmation for the pilot, name who sends it, where it is recorded and when the workaround expires. The recruitment lead decides whether the remaining risks permit launch.

Before launch, identify the system in which each active vacancy will be managed. Tell recruiters where new applications arrive, where existing candidates are followed up and when the old process stops accepting changes. If some historical vacancies remain in the old tool temporarily, name their owner and end condition. Avoid two teams updating the same candidate without a reconciliation plan.

Agree the go/no-go meeting with the recruitment, data and access owners. Review failed checks, accepted workarounds and supplier dependencies. Set a recovery decision for a blocked application or unavailable connection: who receives the issue, how candidate communication continues and who can pause expansion. Confirm the practical recovery route with the supplier. Do not assume a full system rollback or automatic restoration is available.

After opening the approved vacancy, inspect the first handoffs rather than waiting for a monthly report. Check that applications reach the expected queue, interview work has an owner and feedback is available for human review. Record any discrepancy beside the original acceptance check. The pilot can remain small while a defect is resolved. Expansion requires a deliberate decision about the next vacancy or team, with evidence for any additional workflow.

Ask each user to practise their own task with the synthetic workflow. A recruiter should find the next candidate action and communication context. A hiring manager should locate the relevant vacancy and record interview feedback. An administrator should explain how a user reports a problem and which owner can change a setting. Training is ready when people can perform those tasks without relying on the implementation lead to narrate every step.

Choose a few operating checks for the first review: applications with a missing owner, interview feedback still outstanding and work completed outside the agreed record. Define the period and denominator before reporting a rate. For example, three missing-owner applications out of twelve received applications equals 25%. Those invented numbers explain the calculation only. Investigate the cause and decide a follow-up; the percentage alone does not prove that the ATS has improved hiring.

Keep a visible support owner and a date for the pilot review. Ask users what made their next action unclear and inspect the corresponding record before adding configuration. A recurring workaround may indicate a missing setting, unresolved dependency or unclear responsibility. Update the launch checklist when the team accepts a change, then repeat the affected rehearsal. Close the pilot with an expansion decision and a named owner for ongoing administration.

CapoFine Hire supports configurable hiring stages, candidate ownership and communication, interview scheduling and structured feedback after interviews. Hire assists recruiters and preserves human hiring decisions. Its scorecards organise post-interview evidence; they are not candidate tests.

Bring the pilot vacancy, stage owners, application questions and unresolved checks. Use the Hire overview to identify the relevant workflow and review Hire plans for package boundaries. Confirm connection, migration and implementation scope with the responsible people before agreeing a date. This guide does not promise that every proposed requirement is included in every plan.

Before the next implementation meeting, choose the shorter or longer planning path and name the decision that ends its first phase. Assign the open data, access and communication questions to their owners. Ask each owner to return the evidence needed for the pilot, together with any dependency that changes the proposed launch date.