Applicant tracking system RFP template: requirements, a weighted scoring sheet and a demo script

An applicant tracking system RFP is the document you send a shortlist of ATS vendors so their answers can be compared on the same terms. It has four parts: how you hire today, your requirements by area (workflow, compliance records, integrations, data export, security, reporting, candidate experience, support and pricing), a weighted scoring sheet agreed before responses arrive, and a scripted demo built on your own hiring scenario. As of October 2026, the compliance section matters most for US federal contractors, who must keep records of internet applicant searches (41 CFR 60-1.12), and for employers using automated screening on New York City candidates, which needs a yearly bias audit under Local Law 144.

This page is about buying the ATS itself. For which software categories an agency needs at all, see the recruiting agency tech stack; for buying an interview note taker that sits beside the ATS, see the AI note taker evaluation checklist. When the RFP is done, the ATS migration checklist covers the move.

How should an ATS selection process run?

1. Requirements workshop with recruiters, coordinators, two hiring managers, HR, IT or security, and finance. List what breaks today, not what a vendor brochure suggests.
2. Shortlist three to five vendors from public documentation and a short call.
3. Send the RFP with a deadline and one contact for questions; share every answer to a vendor question with all vendors.
4. Score written responses independently, then meet to compare.
5. Scripted demos for the top two or three, using the script below.
6. Sandbox trial and references: real users load a real (anonymized) requisition, and you call customers of your size and type.
7. Security and contract review, including the data processing terms and the exit clause.

An example timeline is eight to twelve weeks from workshop to signature. Write your own dates into the RFP so vendors know when decisions happen.

The applicant tracking system RFP template

REQUEST FOR PROPOSAL: APPLICANT TRACKING SYSTEM
Issued by: [Company]   Contact: [name, email]   Issued: [date]
Questions by: [date]   Responses due: [date]   Demos: [dates]
Decision: [date]   Target go-live: [date]

1. ABOUT US
- [In-house team / agency], [X] recruiters, [X] coordinators,
  [X] hiring managers who will log in.
- Hires per year: [X]. Open requisitions at a time: [X].
  Applications per year: [X]. Countries/states we hire in: [list].
- Current system: [name]. Records to migrate: [X] candidates,
  [X] years of history.
- What is not working today: [3–5 bullets].

2. RESPONSE FORMAT
For each requirement answer: Yes (standard) / Yes (configuration) /
Yes (custom work or add-on, with cost) / Roadmap (with date) / No.
Link to your public documentation where it exists.

3. WORKFLOW
3.1 Requisition creation and approval, with approval chains by
    [department / level / cost].
3.2 Configurable stages per job or job template.
3.3 Interview scheduling: calendar sync, panels, candidate
    self-scheduling, time zones.
3.4 Scorecards: per-stage, per-interviewer, required before debrief.
3.5 Offers: templates, approvals, e-signature.
3.6 [Agency] Client and contact records, job orders, submittals,
    placements, fees.
3.7 Bulk actions: move, reject, email with templates.
3.8 Duplicate detection and merge rules.

4. COMPLIANCE AND RECORDS
4.1 Retention periods configurable by country/state and record type,
    with automatic deletion or anonymization and a deletion log.
4.2 Legal hold that stops deletion for named candidates or jobs.
4.3 Candidate access and deletion requests: how to find and export
    all data for one person.
4.4 Voluntary EEO self-identification collected separately from
    the application and hidden from reviewers.
4.5 [Federal contractors] Records of searches of internal and
    external resume databases: criteria, date and position.
4.6 Consent and privacy notice records with dates.
4.7 Audit log of who viewed, changed, exported or deleted a record.
4.8 Any feature that scores, ranks or screens candidates: what it
    does, whether it can be switched off, and bias audit results.

5. INTEGRATIONS
5.1 List of current integrations, built by you or by partners.
5.2 API documentation link, rate limits, and which objects can be
    read and written (candidates, applications, notes, scorecards,
    attachments).
5.3 HRIS handoff at hire: [system].
5.4 Job board posting and application import: [boards].
5.5 Single sign-on: [identity provider].
5.6 Email and calendar: [provider].

6. DATA EXPORT AND EXIT
6.1 What a full export contains, in which formats.
6.2 Whether notes, scorecards, attachments and stage history are
    included, with dates.
6.3 Time to deliver, cost, and availability after termination.
6.4 Data deletion and certificate at the end of the contract.

7. SECURITY AND PRIVACY
7.1 Hosting location(s) and options for data residency.
7.2 Independent security reports or certifications you can share.
7.3 Encryption in transit and at rest; access controls by role.
7.4 Subprocessors list and data processing agreement.
7.5 Incident notification commitment.

8. REPORTING
8.1 Standard reports: time to fill, pipeline by stage, source,
    offer acceptance, [agency: submittals, placements, fees].
8.2 Custom reports and export to spreadsheet or BI tool.

9. CANDIDATE EXPERIENCE AND ACCESSIBILITY
9.1 Application on mobile; time to complete a standard application.
9.2 Accessibility standard the career site and forms meet.
9.3 Languages supported.

10. IMPLEMENTATION, SUPPORT AND PRICE
10.1 Implementation plan, roles, duration, and migration support.
10.2 Support hours, channels and response times.
10.3 Pricing model (per seat, per employee, per hire, flat) with a
     quote for our numbers and at twice our numbers.
10.4 Contract length, renewal terms and price increase caps.
10.5 Three references of similar size and type.

Which requirements should be must-haves?

A must-have is something you would reject a vendor for. Most teams list too many and then ignore half. Keep must-haves to the items that are hard to fix later: retention and deletion controls for the places you hire, a complete data export, single sign-on if your security policy requires it, and the integrations you cannot work without, such as your HRIS. Everything else is weighted, not pass or fail.

The weighted scoring sheet

Agree weights before the first response arrives, score each section from 0 to 4, and multiply. The weights below are an example for a mid-sized in-house team; an agency would weight client and placement workflow much higher.

SCORING SHEET   Vendor: [ ]   Scorer: [ ]   Date: [ ]
Must-haves met (all required):  [yes / no: which failed ______]

Section                Weight   Written (0-4)   Demo (0-4)   Notes
Workflow               [25%]    [ ]             [ ]          [ ]
Compliance/records     [15%]    [ ]             [ ]          [ ]
Integrations           [15%]    [ ]             [ ]          [ ]
Export and exit        [10%]    [ ]             [ ]          [ ]
Security/privacy       [10%]    [ ]             [ ]          [ ]
Reporting              [10%]    [ ]             [ ]          [ ]
Candidate experience   [5%]     [ ]             [ ]          [ ]
Price and terms        [10%]    [ ]             [ ]          [ ]
Weighted total = sum of (weight x average of written and demo)

The demo script

Send the script with the RFP and ask every vendor to follow it in order, on screen, in their product. A free-form demo shows the vendor's best features; a script shows yours.

DEMO SCRIPT (75 minutes)
1. Create a requisition for [real role], route it for approval to
   [two approvers], and post it. (10 min)
2. Apply as a candidate on a phone. Time the application. (5 min)
3. Find a duplicate: the same person applies with a second email.
   Show detection and merge. (5 min)
4. Move five candidates through screen to panel; schedule a
   three-person panel across two time zones. (15 min)
5. Interviewers submit scorecards; show what the hiring manager sees
   before and after all are in. Paste a structured note from an
   outside tool into the candidate record. (10 min)
6. Make and approve an offer; hand the hire to [HRIS]. (10 min)
7. A candidate asks for all their data, then for deletion; show the
   export, the deletion, and what the log keeps. (10 min)
8. Build a report: time to fill by department, last two quarters.
   (5 min)
9. Export everything for one job, including attachments. (5 min)

Step 5 matters if your interview notes come from a separate tool. Some note takers have no ATS integration and rely on copy and paste; Interview Signal, which we make, is one of them. Test that a pasted scorecard keeps its structure in the field it lands in. Our guide to getting interview notes into an ATS without an integration covers the routes.

What compliance questions should an ATS RFP ask?

• Retention by region. Title VII employers must keep hiring records for one year from the record or the personnel action, whichever is later, and until final disposition of any charge (29 CFR 1602.14); several states require longer, and the GDPR requires that data not be kept longer than necessary. The system needs different rules for different places; our retention policy template lists them.
• Federal contractor search records. Contractors must keep, among other things, the "substantive search criteria used and the date of the search" for resume database searches, for two years if they have 150 or more employees and a contract of at least $150,000, otherwise one year (41 CFR 60-1.12). Ask whether the ATS logs searches.
• Automated tools. If any feature scores or ranks candidates, ask what it does and for bias audit results; New York City requires an audit "within one year of the use of the tool" and candidate notices (NYC DCWP). See our Local Law 144 bias audit page and AI hiring laws by state.
• Access and deletion requests. Ask the vendor to show a full export and deletion for one person; our page on candidate data access requests lists the deadlines.

All as of October 2026. This is general information, not legal advice.

Common mistakes