An ABA applicant tracking system is an ATS whose data model knows what an RBT is. Not one that lets you type "RBT" into a text box you created — one where BT, RBT, BCBA, BCBA-D, BCaBA, QBCBA and QASPS are credential types the software ships with, each with its own verification state and its own expiry date.
That distinction sounds pedantic until you watch a generic ATS handle an ABA pipeline. Then it's the whole difference between software that works on day one and software somebody has to configure into an approximation of your job.
A live 20-minute look at the product on roles you're hiring for now. Google Meet. No pitch deck.
A general-purpose ATS isn't badly built. It's built for a world where a candidate is qualified or not, once, permanently. ABA is not that world.
The first thing every ABA agency does inside a general ATS is create a field called "Certification." Sometimes it's a dropdown, sometimes free text, usually both because two people built it on different days. It holds a string. A string cannot expire. A string cannot be mismatched against an opening's requirement, because the opening's requirement is also a string, in a different field, that nobody reconciled.
So the actual credential check migrates back out of the ATS into the place it was before: a spreadsheet, a shared drive, and one person's memory. The ATS holds applicants. A human holds the compliance.
Most ABA hiring volume is behavior technicians who are not RBTs on the day you meet them. A general ATS models this as a deficiency — a missing qualification on a req that asks for one. You end up either lying to your own requisition or running BT hiring outside the system entirely.
An opening that doesn't require certification is a normal opening, not an exception. That has to be true in the data model, not in a note on the job description, or the software will keep flagging your best hires as unqualified.
Certifications lapse on a date. That date is a scheduling fact about your workforce, and it belongs next to the person, in the system that hired them — with a status that can read expired without anyone retyping it.
Capabilities described here are the ones in the product today. What isn't built is listed further down, under "What it doesn't do."
Four things you can check on a call, not four adjectives.
BT, RBT, BCBA, BCBA-D, BCaBA, QBCBA and QASPS are first-class credential types, alongside RN, LPN and CNA — not custom fields somebody has to configure. Verification status is tracked through its full lifecycle, and the BACB registry is a recognized verification source. Expired, mismatched, or missing credentials are flagged before you spend a minute on the file.
Every applicant is scored against the job's real requirements, factor by factor: credentials match, experience match, distance and commute radius, language match. The weights are tunable per organization, so a score means what your organization means by fit — not what a vendor assumed.
Name, age, gender, and address never feed the score directly; commute distance is a weighted factor, and the weight is yours — set distance or language to zero if they don't matter for your roles. The score orders your day. It doesn't decide anything.
Import them from any spreadsheet export (CSV/Excel). The import is staged, with fuzzy duplicate detection and a review queue before anything lands, plus provenance and consent controls that hard-block what shouldn't be contacted. Then bulk-score the whole pile against your open roles and get it back ranked, with the evidence shown.
Candidates worth talking to get a self-booking link for the right calendar — availability in the app, atomic tokenized booking so two people can't take one slot, calendar files for both sides, reminders at 24 hours and 2 hours. Recruiters, clinic sites, and operators each get a role-scoped portal on the same live data, and tenant data is isolated with row-level security backed by a passing isolation test matrix.
No automated credential verification. Screening is automated. Verification is a person checking a registry, with an audit trail.
No outbound multi-board job posting. Jobs post to your SherStaff portal; Indeed applications come in through an inbound integration.
No CentralReach or Rethink integration yet. It's on the roadmap. Today your data exports cleanly (CSV) for entry into your practice-management system.
No self-serve signup or in-app billing. We set it up for you — your account, your users, your applicant import — and your team is live within 24 hours. Large historical imports run through a duplicate-review queue, which can take a little longer.
One test: open the software and try to record that a candidate holds a BCaBA whose certification expires in March, and that a second candidate is a BT with no certification who is eligible for an opening that doesn't require one. If both are ordinary states the system already understands, it's an ABA ATS. If either requires you to invent a custom field, a tag, or a spreadsheet column, it isn't — it's a general ATS you are configuring.
In SherStaff, BT, RBT, BCBA, BCBA-D, BCaBA, QBCBA and QASPS are first-class credential types alongside RN, LPN and CNA, and verification status moves through a defined lifecycle — unverified, pending, verified, failed, expired, revoked — with an immutable audit entry behind every change.
No, and nobody should tell you they do without showing you the integration. A recruiter checks the state board or the BACB registry and records what they found; that record carries an audit trail.
What is automated is the screening — expired, mismatched, and missing credentials are flagged before you open the file. Screening is automated. Verification is a person checking a registry.
No. We don't do outbound multi-board job posting — if distributing postings across job boards is the center of your recruiting, keep the tool that does it. SherStaff runs alongside it.
What SherStaff takes over is the checking work: credential-first screening, an explainable 0–100 fit score against the job's real requirements, and re-scoring the applicant database you already own.
Supported, and normal. You post openings that don't require RBT certification, hire into them, and track credential status and expiry for those people as it changes.
There is no BT-to-RBT certification pipeline tracker in the product — that's on the roadmap, not in the build. What exists today is the opening without a certification requirement, and credential status and expiry tracking on the person you hired.
Google Meet. No pitch deck. If it isn't a fit, I'll tell you on the call.