Sopact is a technology based social enterprise committed to helping organizations measure impact by directly involving their stakeholders.
Copyright 2015-2026 © sopact. All rights reserved.
Clean-at-source intake — one client ID assigned at referral.
Client intake software is the platform that captures the first interaction with a new client — referral, intake form, eligibility screen, consent, and the assignment of a persistent client ID — and opens the case record that everything downstream writes back to. It is also called client intake form software, human services intake software, or case intake and disposition tracking. The newest generation does more than collect: it drafts the data dictionary from your existing form, reads every open-text answer on arrival, decides eligibility at submission, and routes referrals automatically — so the record is analyzable from the first touch instead of decoded by a caseworker weeks later.
Used by: nonprofit human services intake teams · social-services and family-services referral intake · housing coordinated entry · workforce and reentry enrollment · community action agencies running eligibility screening · multi-program agencies where one client moves across several intakes.
Intake is the front door of the case pipeline. If you are comparing the whole lifecycle rather than the front door alone, start with case management software — this page covers what happens the moment a client first makes contact.
Not because forms stopped working — because getting a response out of paper and into a database became table stakes. Standalone form tools earned their place honestly: Google Forms, JotForm, Microsoft Forms, and the legal-intake tools that dominate the generic intake SERP got responses out of the filing cabinet and into something structured. If your only problem was collection — capture the answers, export them nightly — that generation solved it.
But the strength hardened into a weakness. The form became a funnel into a system, and everything that made the intake usable happened after collection, by hand. The open-text answer to "what brings you here today?" sits in a CSV column nobody reads until the cohort report. Eligibility is a worker-review task that lands behind a backlog. The same client, re-referred two years later, is matched by name and birthdate at year-end — if at all. And the case systems whose intake modules do exist — Bonterra Apricot, Penelope, ClientTrack — treat intake as free-text you pay an integrator to decode later, with a client ID scoped to one program rather than the person.
The cost of not reading at intake is concrete. A safeguarding phrase in a referral narrative, an eligibility decision delayed, a re-applicant unrecognized — each one shows up at the year-end audit instead of the day the form arrived. As one practitioner put the broader pattern: case data ends up "just sitting around in the systems… by the time they find out, you already failed a child." Intake is where that clock starts.
There is a real constraint that shapes the fix. As a corporate partner running community programs said, "what we're trying very hard not to do is ask more of our nonprofit partners. Because it's a lot on them." The answer is not a longer form. It is a smarter one — extract from what the client already provides, map every field to your framework at design time, and read on arrival so the burden stays flat while the record gets richer.
The stake, stated honestly: the record only becomes analyzable if it is clean at the source. Every field decoded later is a field entered wrong once and corrected never. Clean-at-source intake — one ID assigned at referral, every narrative field mapped to the framework, eligibility and routing decided at submission — is what separates a form you export from a record you can query.
Intake intelligence is a client record that is analyzable from the first touch — reliable answers from your intake data in minutes, not a quarter-end reconstruction. Everything the client provides at first contact is treated as data: the referral, the intake form, the validated eligibility screen, the consent, the open-text narrative. All of it lands on one persistent client ID, aligned to your framework and data dictionary, so the same person looks like the same person across three programs and five years.
The part that changes daily work is the Assistant. Instead of hunting a dashboard or waiting for the one analyst who knows where the export lives, anyone — intake staff, a supervisor, the program director, the funder — asks a question in plain language and gets a defensible answer with citations to the underlying records. Eligibility screening, open-text reading, and re-applicant matching are unified into one chat-based function. A program is never one user, and a chat interface empowers each of them directly.
When the reading is done, it does not die in the chat: create shareable reports tailored to each audience — the intake-throughput view for the supervisor, the eligibility-distribution report for the funder, the demographic summary for the board — from the same underlying answer, each number traceable to the source form.
One proof point from the field. Open Play Foundation ran on paper logs and spreadsheets, and needed live evidence rather than a quarter-end export. When the work moved onto Sopact, the record could finally read itself: "Those statistics that we're now running on Sopact immediately showed me there's something significantly wrong … things like that, we would never have been able to do in the past." — Marco Botha, CEO, Open Play Foundation. The same logic applies to intake: when every response is read on arrival, the impossible reading — the missed flag, the delayed eligibility decision, the unrecognized re-applicant — surfaces immediately, not at the audit.
The honest way to evaluate client intake software is against the pipeline it feeds, not the form-builder feature list. Intake is not one step — it is six, from the referral that opens the record to the handoff that gives casework a clean file. Below is the full sequence, each with what the software should do, the exact prompt to use, and what to expect back. Every prompt is copy-paste; the placeholders in brackets are yours to fill.
The record starts at the referral, not at enrollment. A persistent unique ID is assigned the moment a client is referred — from a partner agency, a self-referral, a hotline, or an outreach worker — so everything that follows attaches to one person. Re-referrals from an earlier cycle arrive recognized, with their prior history already on the record.
Set up referral intake for [PROGRAM]. Assign a persistent client ID at first contact from any referral source (partner agency, self-referral, hotline, field outreach), and check each new referral against existing records to detect re-referrals by more than name and birthdate. Capture referral source, date, and reason, and flag any referral that arrives with immediate-risk language for the supervisor queue.
Expected output. A referral captured against a persistent client ID, re-referrals surfaced with prior history attached, and an immediate-risk flag routed before anyone opens the file.
Tips for reliable output. Assign the ID at referral, not at enrollment — everything downstream attaches to the ID created here. Recognizing a returning client is worth more than any single new field.
Intake is where clean-at-source pays or fails. Instead of free-text you will pay a worker to decode later, the form is designed so every narrative field maps to your framework and every closed field maps to your data dictionary — and the AI drafts that form from the program documents and existing intake you already have. Conditional logic, save-and-return, and offline capture keep the burden on the client low.
Build a client intake form from this program description and our existing form: [PROGRAM URL OR DOCUMENT]. Create structured fields for demographics and eligibility, narrative fields for presenting needs and goals mapped to our theory of change, and consent capture. Add conditional logic and save-and-return. Flag any question that collects information we already hold on returning clients so we can drop it.
Expected output. A ready-to-edit intake form: structured fields, mapped narrative prompts, consent, conditional logic — and a data dictionary drafted from the form itself in one working session instead of an integrator week.
Tips for reliable output. Give the AI your theory of change and data dictionary before form design. Cut every question whose answer you already hold — reducing partner and client burden is a design goal, not an afterthought.
Eligibility screening happens the moment the form lands, not after it joins a review queue. Closed fields are scored against your criteria and open-text answers are read for the evidence that structured fields miss, so a pass/fail surfaces at submission — and the worker reviews edge cases, not every case.
From this intake submission, decide eligibility against our criteria: [ELIGIBILITY RULES]. Score the closed fields, read the open-text answers for evidence the structured fields miss, and return a pass, fail, or needs-review decision with the exact source sentence behind each. Where documentation is missing, list what the client still needs to provide. Do not infer anything the text does not support.
Expected output. An eligibility decision per submission with per-criterion evidence, a needs-review list for edge cases, and a missing-documentation checklist — decided the day the form arrives.
Tips for reliable output. Encode eligibility rules explicitly before go-live. A rule the system can state is a decision an auditor can trust; a rule left in a worker's head is a backlog.
Consent is captured and versioned at intake, and the narrative is read for risk the moment it lands. Safeguarding language, escalation, or immediate-need signals route to the supervisor queue at submission — with the source sentence attached — instead of sitting in the form until someone reads it.
Read this intake narrative: [NARRATIVE]. Confirm the required consents are captured and note any that are missing. Flag safeguarding, escalation, or immediate-risk language and route it to the supervisor queue with the exact source sentence. Do not diagnose — report only what the text supports, and mark anything ambiguous for human review.
Expected output. A consent-complete check plus a risk-flag list with sources, routed to a named queue the moment the form arrives — not at the supervisor's month-end sample.
Tips for reliable output. Route every risk flag to a named owner with a deadline. A flag nobody owns is a finding that sat there. Exclude the most sensitive fields from AI processing entirely if your policy requires it.
With eligibility decided and risk flagged, the client is routed — to the right program, the right caseworker, or an external partner when the need is outside your scope. Matching runs on capacity, specialty, and priority, so the handoff is a decision the system can explain rather than a caseworker's guess.
From this intake record, recommend a routing decision: match the client to the right program or caseworker by eligibility, specialty, capacity, and priority, or recommend an external referral where the need is outside our scope. Show the reason for the match, note any need with no available service, and cite the intake fields behind the recommendation.
Expected output. A routing recommendation with a stated reason, a gap list where a need has no matching service, and an external-referral suggestion where the client belongs elsewhere.
Tips for reliable output. Keep the routing rules visible and versioned. When a client is referred out, capture that in the record too — the front door should track who it could not serve, not just who it enrolled.
The intake does not funnel into a separate system to be re-keyed. The same persistent ID, the same data dictionary, and the same record carry into casework — the caseworker opens a file with eligibility decided, risks pre-flagged, consent recorded, and full context attached, usually minutes after the client hits submit.
Prepare the caseworker handoff for this intake: [CLIENT ID]. Summarize the client's presenting needs and baseline against the service framework with citations, list the eligibility decision and any open documentation, attach the risk flags and their sources, and confirm the persistent client ID and consent status. Format it as the opening view of the case record, not a separate export.
Expected output. A caseworker-ready file opened on the same client ID — needs summarized with citations, eligibility and consent recorded, risks pre-attached — so casework starts from a clean record, not a re-keying job.
Tips for reliable output. Capture contact channels and follow-up expectations at intake, not at exit. The ID you assign here is the one every later case note and outcome follow-up will write back to — see how the record continues in case notes software.
Beyond table stakes — conditional logic, consent, encryption — five criteria actually separate intake tools: whether the form drafts its own data dictionary or an integrator builds one, whether open-text is read on arrival or exported for later, whether eligibility is decided at submission or added to a review backlog, whether a persistent client ID is assigned at referral and survives across programs, and whether risk routes to a supervisor the day it arrives. Ask every vendor to show these on a real submission, not a slide.
The evaluation itself is work you can delegate to AI. This prompt mirrors what buyers are already asking answer engines — use it as it is:
Build an evaluation matrix for client intake software with technical and program criteria weighted 50/50. Technical: conditional logic, offline capture and sync, field-level access control, integration to our case system or HMIS, data export and exit rights. Program: data dictionary drafted from the form, open-text read on arrival, eligibility decided at submission, one persistent client ID across programs, risk routing to a supervisor queue. Score vendors [VENDOR LIST] on each criterion with evidence required, not vendor claims.
A note on scope while you evaluate: intake is the front door, and the same spine adapts by vertical with a different eligibility screen and consent language — human services case management software for coordinated entry and benefits, nonprofit case management software for funder-reporting agencies, and social work case management software for clinical referral intake each cover their fit directly. For caseworker capacity once clients are enrolled, see caseload management software; for the relationship record that spans every program, stakeholder intelligence.
The stages above are the argument; the Academy articles are the practice — each a hands-on companion for one workflow, written to run on your own data.
Honest boundaries, because the fastest way to a failed implementation is buying the wrong category.
Not a survey tool. A survey tool (SurveyMonkey, Qualtrics, JotForm) collects responses for later analysis. Client intake software collects responses that immediately become the foundation of a persistent client record — with eligibility, risk routing, and service planning happening on arrival, not in a spreadsheet afterward.
Not a legal-intake product. The generic "client intake" SERP is dominated by law-firm tools built around matters, conflicts checks, and billing. This is intake for human services, social services, and community programs — where the artifact is a client record feeding casework and outcomes, not a legal matter feeding a billing engine.
Not your whole case management system. Intake is stage one. Case notes, service plans, and outcome follow-up live in the full lifecycle — intake's job is to open a clean record and hand it over, not to replace the case system. See case management software for the full arc.
Not for every compliance regime. Sopact provides AES-256 encryption, TLS 1.3, field-level role-based access, SSO/MFA, and full audit logging, with AI under enterprise SLAs and no training-data retention — but Sopact is not currently HIPAA-certified or covered by a Business Associate Agreement. If your intake is subject to HIPAA, FERPA, 42 CFR Part 2, or state confidentiality rules, evaluate these controls against your compliance program and confirm scope in writing before storing protected information.
Client intake software is the platform that captures the first interaction with a new client — referral, intake form, eligibility screen, consent, and the assignment of a persistent client ID — and opens the case record everything downstream writes back to. Also called client intake form software or human services intake software. The newest generation drafts the data dictionary from your existing form, reads open-text answers on arrival, decides eligibility at submission, and routes referrals automatically.
For nonprofit and human-services intake, the best client intake software drafts the data dictionary from your existing form, assigns a persistent client ID at referral, reads open-text answers on arrival, decides eligibility at submission, and routes safeguarding risk to a supervisor the day it appears — rather than exporting responses for someone to decode later. Standalone form tools like JotForm and Google Forms collect well but stop at collection; case systems like Bonterra Apricot and Penelope include intake but take months and scope the client ID to one program. AI-native platforms like Sopact treat intake as the start of one persistent client record.
Human services intake software captures referral and enrollment for benefits, coordinated entry, and multi-program agencies — where one client often moves across several intakes. Intake and disposition tracking adds the decision layer: what happened to each referral (screened in, referred out, enrolled, closed) tracked against the same client record. The value is that disposition is decided and recorded at intake, not reconstructed at year-end, so the agency can report throughput and outcomes on one persistent ID.
Intake is stage one of the case lifecycle. The persistent client ID assigned at referral, the data dictionary drafted from the form, and the record itself carry directly into casework — the caseworker opens a file with eligibility decided, risks flagged, and consent recorded, not a re-keying job. For the full arc from intake through case notes and outcome follow-up on that same ID, see case management software.
Yes — the point of intake intelligence is that eligibility is decided at submission rather than added to a review backlog. Closed fields are scored against your criteria and open-text answers are read for the evidence structured fields miss, so a pass, fail, or needs-review decision surfaces the moment the form lands, each with the source sentence behind it. Workers review edge cases instead of every case, and the missing-documentation list is generated automatically.
Look for AES-256 encryption at rest, TLS 1.3 in transit, role-based access to the field level, SSO with MFA, and full audit logging — all of which Sopact provides, with no training-data retention on AI calls. Intake is the most sensitive moment in a client's record, so sensitive fields can be excluded from AI processing entirely. Sopact is not currently HIPAA-certified or covered by a Business Associate Agreement; if your intake touches protected information under HIPAA, FERPA, or 42 CFR Part 2, treat that as gating and confirm scope in writing.
Yes. Modern client intake software supports offline form capture that syncs back to the persistent client record when the field worker is back online — the pattern for outreach, encampment intake, and home visits. The client ID, eligibility decision, and risk routing all resolve once the submission syncs, so field intake produces the same clean record as an online one.
Sixty minutes, your existing intake form — PDF, JotForm, Word, Google Form, any source. We walk through how Sopact would draft the data dictionary from it, what the AI would extract from the open-text answers, how eligibility gets decided at submission, and what the caseworker's queue looks like five minutes after a client hits submit. If the record isn't cleaner at the source than what you run today, don't continue. Scope a 2-month pilot →