Published 1 November 2026
Legal aid clinics operate under a structural constraint that private firms generally do not: far more people need help than the clinic has attorney and paralegal hours to serve, and the intake process itself — figuring out who qualifies, what kind of matter they have, and how urgent it is — consumes a disproportionate share of staff time before anyone gets to actual legal work. A clinic that spends an hour of staff time per intake, multiplied across hundreds of requests a month, has lost most of a full-time role to triage before a single case has been opened. That is exactly the kind of high-volume, rule-bound sorting problem that AI-assisted intake and case management can take on, carefully, without replacing the judgment calls that have to stay with a human.
What intake actually involves, and why it is harder than it looks
Intake at a legal aid clinic is not just data collection. It is simultaneously screening for eligibility (income thresholds, geographic service area, case type restrictions), identifying the legal issue when the client often cannot name it precisely themselves, flagging urgency (an eviction with a court date in five days is not the same priority as a general consumer debt question), and routing to the right program or attorney. Each of those steps has clear, checkable rules behind at least part of it, which is what makes automation genuinely useful here — but each also has edge cases that need a human to resolve, which is what makes a fully automated system the wrong goal.
What can actually be automated well
Structured eligibility screening
Income thresholds, household size calculations, geographic service boundaries, and case-type exclusions are rule-based and well-suited to an automated first pass. A client can answer a structured set of questions through a web form or guided chat, and the system can determine likely eligibility before any staff time is spent, flagging only the genuinely ambiguous cases (self-employment income, recent changes in household composition) for human review.
Legal issue identification through guided questions
Clients frequently describe their situation in their own words rather than legal terminology — “my landlord is trying to kick me out” rather than “eviction,” or “my ex won’t let me see my kids” rather than “custody modification.” A well-built intake flow uses guided follow-up questions to map a plain-language description to the actual legal category and the specific intake questions that category needs answered, rather than relying on a client to self-select from a dropdown of legal terms they may not know.
Urgency flagging against real deadlines
Some matters have hard, short deadlines — eviction court dates, protective order hearings, benefits appeal windows — and an intake system should be able to recognize date-sensitive language and flag those cases for immediate staff attention rather than letting them sit in a general queue in submission order. This is one of the highest-value pieces of the whole system, because a missed deadline on an urgent matter is often an unrecoverable harm in a way a delayed response on a non-urgent matter is not.
What should stay with a human, deliberately
Final eligibility determinations in ambiguous cases, any assessment of case merit or likely outcome, and anything involving immediate safety concerns (domestic violence, child safety) need a human making the call, not a system inferring one. The automated layer’s job is to gather clean, complete, well-organized information and get it in front of the right person quickly — not to make the determinations that carry real consequences for someone’s legal rights or safety. Designing the handoff points explicitly, rather than letting the system creep into judgment calls because it technically can generate an answer, is the most important design decision in a project like this.
Document and case management after intake
Once a matter is accepted, the same purpose-built system should carry the case through its lifecycle — tracking documents received against what is required, deadlines with escalating reminders, and status so that a client calling for an update does not require someone to reconstruct the file from memory or a shared drive. This is where document intelligence adds real value, extracting key fields from submitted documents to cross-check against the case record instead of a paralegal re-keying it by hand, which also reduces the transcription errors that are easy to make under high caseload pressure.
Where this plugs into the clinic’s broader systems
This is rarely a greenfield build in isolation — most clinics already have some case management tool, and the intake automation needs to feed into it rather than create a second system staff have to check separately. Our AI intake and case management work is built around exactly this integration problem, and pairs with the broader pattern we use across legal and immigration AI software work for firms and clinics with high-volume, deadline-sensitive caseloads.
Where this breaks
Over-automating urgency detection is the most consequential failure mode — if the system is tuned to catch only the deadline language it was trained to expect, and a client describes an urgent situation in unfamiliar phrasing, that case can silently sit in a general queue past a real deadline. The safer design errs toward over-flagging: when genuinely uncertain, route to a human reviewer rather than defaulting to non-urgent. The second common failure is eligibility screening that is too rigid about edge cases — self-employment income, recent job loss, non-traditional household structures — and ends up incorrectly screening out people who are actually eligible, which undermines the whole point of a legal aid intake system.
Multilingual intake is not optional for most clinics
Legal aid clinics serve populations where a meaningful share of clients are not comfortable completing intake in English, and an intake system that only works in one language quietly excludes exactly the people who often need the most help navigating an unfamiliar legal system. Building multilingual support into the intake flow from the start — not as a bolt-on translation layer applied after the fact — avoids the common problem where translated questions lose the specific phrasing needed to correctly map a client’s situation to the right legal category. This is worth scoping explicitly against the clinic’s actual client language data rather than assuming English and Spanish cover the need, since the right language set varies significantly by region and clinic population.
Staff adoption matters as much as the system design
An intake system that staff do not trust will get worked around, quietly, the same way any other tool that does not fit how people actually work gets worked around. The clinic staff doing intake every day know exactly where the current process breaks and exactly what makes them skeptical of a proposed change, and involving them early — not just the clinic director — in defining the eligibility rules and urgency criteria tends to produce a system people actually use correctly, rather than one that gets bypassed the first time it makes a call that does not match a staffer’s own judgment. Plan for a transition period where staff can review and override the system’s categorization easily, both to build trust and to catch cases where the rules genuinely need adjusting.
Getting started
The most useful starting point for most clinics is simply mapping the current intake process end to end — every question asked, every eligibility rule applied, every point where a staff member currently makes a judgment call — before deciding what to automate. That mapping work is most of the real scoping effort and is worth doing even before talking to anyone about a build. If it would help to walk through what a scoped system would look like for your clinic’s specific intake volume and rules, the ASTACKRA Project Planner is a fast way to start that conversation, or reach the team directly through our contact page.
Related