Disability Services Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the "rebuild case management" scope failure happen so often?

Because case management is the visible surface of the office. Intake forms, documentation, notes, accommodation letters. So a scope document naturally covers all of it, plus the testing centre, plus alternate formats, plus interpreters, and the result is a platform that arrives after two more finals weeks have gone badly.

The awkward truth is that case management is the half of this category that products already serve reasonably. ClockWork is well established, Accessible Information Management is used widely and seriously, and Symplicity Accommodate integrates with a broader student services suite many institutions already own. Rebuilding that from scratch spends most of the budget on the least differentiated work.

The half where institutions with real volume are genuinely failed is scheduling. A finals week with hundreds of exams, extended time multipliers, reduced distraction rooms and a shared proctor pool is a constrained optimisation problem, and no product in this market solves it properly. Start there, plus continuous faculty notification. Those two produce most of the complaint risk and most of the daily pain, and the scheduling model they establish gets reused by interpreters, note takers and alternate format production later.

What goes wrong with enrolment data and case history migration?

Enrolment is the live dependency and it is where the design most often goes wrong. A nightly feed from the student information system is the minimum acceptable cadence, and anything slower means notifications lag reality in exactly the weeks when reality changes most. Cross listed sections carry two instructors and the instructor of record is frequently not in the obvious field. Sections change instructor after the term opens.

Case history brings a different problem. Determinations recorded as a note with a date, accommodations recorded as a list with no history of when each was added or removed, and denials with no recorded rationale at all. Migrating that faithfully means accepting that much of it arrives as unstructured history rather than as structured records.

The workable approach is to migrate current active accommodations as structured data, keep everything historic as read only attachments on the student record, and start the structured interactive process from the go live date forward. Then verify the enrolment mapping against a real term before launch: pick fifty students with accommodations, generate the notification list, and have a coordinator confirm every instructor by hand. The errors you find will be cross listings and instructor of record fields, and finding them in testing costs nothing.

Why do the student information system and email integrations break after launch?

They break at term boundaries, which is the worst possible timing and also entirely predictable. A registrar changes a term code format, a new campus is added with a different section numbering convention, or a course is created in a way the feed did not anticipate, and the notification run silently produces a shorter list than it should.

Email is the other quiet failure. Notification volume spikes in the first weeks of term, institutional mail filtering treats a burst of similar messages as suspicious, and a proportion of faculty never see the letter. Nobody discovers this until a student is denied an accommodation and the instructor says truthfully that they never received anything.

Design against both. Reconcile counts every run: students with active accommodations, sections they are enrolled in, notifications generated, notifications delivered, acknowledgements received, with any drop surfaced as an exception rather than buried. Require instructor acknowledgement with a timestamp so delivery is proven rather than assumed. Give instructors one consolidated view of all their sections instead of eight separate letters, which is a small courtesy that materially improves compliance because a wall of email is precisely how notifications get missed.

What happens when the interactive process record is not structured?

This is the gap that turns an administrative inconvenience into a legal exposure. The Americans with Disabilities Act Amendments Act shifted emphasis away from proving a disability and toward providing reasonable accommodation, which means your defence is a documented, individualised interactive process rather than a thick documentation file.

When that process lives in email, the office is doing careful work it cannot prove. The request is in one inbox, the conversation with the student is in another, the determination is a line in a case note, and the denial has a date but no recorded reason. A denial with no rationale is the single worst artefact to bring to an investigation.

Structure it. The request, the documentation considered, the conversation with the student, the determination with a written rationale, the alternatives offered where a request was not granted, and the appeal path with its outcome. Denials need both a reason from a defined set and a narrative. Faculty objections belong in the same record: when an instructor argues that an accommodation fundamentally alters the course, that objection, the review and the outcome should be documented as a case, because it is exactly the sequence an investigator asks about. None of this slows the office down once it is the default path rather than an extra step.

Should you build custom or configure what you already own?

Stay with your product if you are under roughly 2,500 students with a testing room rather than a testing centre, a modest interpreting need, and a caseload one coordinator can hold. ClockWork, Accessible Information Management and Symplicity Accommodate all serve that shape properly and building at that scale is a poor use of institutional money.

Before deciding the product has failed, use the parts you are paying for. Many offices have never configured exam booking rules properly, never turned on the reporting the product already produces, and never asked their vendor about student information system feed frequency. That is a few weeks of work and it separates a configuration gap from a structural one. Scheduling optimisation will still be missing afterwards, because it is not in these products, but you will know precisely what you are buying.

Build when two or more of these are true. Your testing centre exceeds roughly 3,000 proctored exams a year and finals week is scheduled by hand. You run multiple campuses with a shared interpreting or proctor pool. Alternate format production regularly misses course start dates. You have received an Office for Civil Rights complaint or entered a resolution agreement and your evidence was assembled by hand. Or your current tool is not itself accessible to the students using it, which is a position no institution should be comfortable defending.

How do hidden costs get into the quote?

Accessibility conformance is the line most often promised cheaply and delivered late. WCAG 2.1 level AA on every screen a student or faculty member touches is real engineering time throughout the build, plus testing with actual assistive technology users, and the Department of Justice rule on web and mobile accessibility for state and local government entities makes it explicit for public institutions with compliance dates keyed to entity size. It should be inside the number rather than added afterwards.

Testing centre complexity is the second. Multiple centres with different room types and shared proctor pools is a materially harder scheduling problem than one centre, and it is not a configuration difference.

Then the rest. The size of your interpreting operation, and whether multi campus travel constraints apply. Integration depth with the student information system, since live enrolment is the requirement. Alternate format production, where publisher file request tracking and vendor coordination are process work rather than features. And staff time in discovery, because much of what your office does currently lives in professional judgement and has to be written down before it can be encoded.

What separates a build that works from one that fails here?

Launch timing separates them first. Go live at the start of a term with the testing centre running in parallel for the first few weeks before a midterm period. Never cut over into finals week under any circumstances, however ready the system looks in October.

Then the scheduling question decides the vendor. Ask a developer how they would schedule a finals week with 300 exams, 22 seats, four reduced distraction rooms and three proctors. If they describe a booking calendar, they will build a prettier version of your current problem. The answer you want models typed resources, derives duration from the student's entitlement so a double time student consumes twice the seat hours and a reader assignment removes a proctor from the floor, and reports infeasibility rather than silently overbooking. That last output is what your dean needs, because the answer to an oversubscribed finals week is more seats, longer hours or an earlier instructor deadline, and none of those can be argued for without a number.

Ask what accessibility conformance level they will commit to and how they will test it. Ask how notification stays correct when a student adds a course in week three. Then settle ownership in writing before kickoff: the repository, the case data, the cloud accounts and the right to hire another firm. These records are disability related, highly sensitive, and simultaneously your legal defence, so they should never sit anywhere your institution cannot reach, export or control.