The first ninety days with a new ATS

Can a recruiter see which client is waiting for a response? Can a colleague tell why a candidate was rejected for one role while another application remains open? These everyday questions reveal more about a new ATS setup than a successful login does.

Use the first ninety days to check daily work, resolve recurring problems and hand responsibility to the people who’ll manage the system. Schedule a few reviews around actual records and completed tasks. Ninety days is a planning period here, not a promise that every agency will have settled into the system by then.

Key takeaways

• Agree from launch who handles questions and who can correct problems.
• Review completed work and blocked tasks alongside usage figures.
• Prioritise improvements by their effect on candidates, clients and colleagues.
• Finish the initial period with named support owners and an evidenced list of further work.

What should you check immediately after launch?

Check that colleagues can perform the agreed daily tasks with their own permissions. Follow a record from arrival to follow-up, including the handover to someone else. Keep a short list of obstacles, each with an owner and an appropriate temporary working arrangement where one is needed.

During the first working days, keep one issue log for problems arising in actual use. A wrong recipient or missing access needs an owner immediately; a request for a different column label can wait for the review. Record the affected process, consequences and person deciding on the fix. That keeps the log from becoming an unfiltered wish list.

Provide one recognisable place for questions. Explain what a useful report contains: the action, the expected outcome, what happened and when. Share only the personal information that the authorised recipient needs. A screenshot of an entire candidate record is often unnecessary.

How should you divide the first ninety days?

Use review dates to decide what happens next. The outline below is a suggested working plan to adapt to your agency, workload and unresolved problems. If an important process is still failing, enabling more features doesn’t automatically deserve priority over fixing it.

Point in the period	What do you bring to the review?	What do you produce?
First working days	Reported issues blocking current work	An updated incident log with owners and agreed next steps
Around day 30	Recurring reports and the affected records	One selected improvement, its cause and the outcome you want to see
Around day 60	New records following the change, reviewed on the same basis	A reasoned decision to keep, adjust or reverse the change
Around day 90	Remaining issues and the work moving into routine management	A support handover covering authority, help contacts and the next review date

Keep a short record of each discussion. The date, work examined, decision and responsible person are more useful than a presentation nobody maintains. Record why something was deferred too. Otherwise, the same debate can begin again a month later.

Include colleagues who use the system infrequently where their role requires it. Low use might simply reflect a lack of relevant work. It could also hide an awkward workaround. A conversation will help you distinguish the two.

Which signals tell you about everyday work?

Choose signals that show whether people complete a task properly and where they get stuck. Combine counts with a few reviewed records and user conversations. Rising login numbers say little if recruiters still maintain the same separate spreadsheet to hand work over to a client.

Start with the reason for changing systems. If the aim was clearer client follow-up, check whether the relevant records identify an owner and the next agreed action. Keep the definition consistent and record which cases you examined. A small sample describes that selection, not the whole agency.

Here is a fictional calculation. You review twenty completed handovers and four lack a named next owner. Within that reviewed group, 4 divided by 20 is 20%. It doesn’t tell you why the owner is missing or how often this happens elsewhere. Open those four cases with the colleagues involved.

The GOV.UK Service Manual recommends combining performance data with research into where users struggle. Discuss those four incomplete handovers with the recruiters involved: was ownership undecided, or was there nowhere suitable to record the person responsible?

Include the work still required after a task appears complete. Saving ten minutes of typing while adding ten minutes of corrections isn’t a time saving. If comparable measurements from before the change don’t exist, describe the present situation without inventing an improvement percentage.

How do you turn a report into a useful change?

First establish what the person is trying to do and where the task fails. That tells you whether to change guidance, an agreement, data or a setting. Ask the person to repeat the task afterwards. Closing a ticket becomes useful when the original problem has been sufficiently resolved.

In this fictional example, Ellie reports that colleagues can’t find client feedback. The team’s first suggestion is another mandatory field. Looking at two records reveals that one recruiter stores feedback against the client, while another puts it against the application. They use the existing setup differently.

At the day-30 review, the team agrees one place for feedback about a particular application and records it alongside the example in its instructions. Around day 60, Ellie reviews new handovers on the same basis. Are comments now attached to the intended application, and can the next recruiter find them? Keep the agreement if it addresses the cause; otherwise, investigate access or configuration specifically.

Separate requests for improvements from failures that block current work. A nicer overview calls for a different discussion from a message reaching the wrong client. Agree which consequences require an immediate response, so colleagues don’t each have to invent their own threshold.

Where possible, try a change in a suitable test environment first. Include a recruiter with normal permissions. An administrator can overlook a problem that other colleagues encounter every day.

When can you reduce the extra support?

Reduce additional support when agreed daily processes work, questions have owners and the people responsible for ongoing support know what they’re taking on. Reaching day ninety isn’t enough. Some issues can remain open if their consequences, follow-up and temporary arrangements are clear.

Make the handover specific. Who can change a field or stage? Who answers a user question? When does a report go to the supplier, and who follows it up? Name the person who maintains working instructions after a change as well.

Review the remaining list with the people accountable for the decisions. For each item, record evidence of the problem, the desired outcome and the next decision point. A long wish list without owners gives the support team little to work with.

In Simply’s ATS and CRM configuration, workspace administrators can manage custom objects, fields and relationships. Include that responsibility in the handover. Before adding a requested field, establish whether the information already exists and which colleagues use it. Then record who makes the change and who reviews the new records. That prevents every temporary workaround from becoming a permanent part of the configuration.

Finish the period with a short operational decision: these daily processes work, these issues remain open and these people own them. Set the next review date immediately. The team can then move forward without reopening the original implementation project for every change.