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.
One client record from Coordinated Entry to housed.
Housing case management software is a platform that runs the full housing-services lifecycle on one persistent client record — Coordinated Entry (CES) assessment and VI-SPDAT screening, navigator outreach, shelter or transitional intake, a housing-stability plan, supportive-services case notes, exit-to-housing, and 6- and 12-month stability follow-up — so navigators, program managers, and CoC leads get answers without stitching HMIS, spreadsheets, and exit surveys together. It is also called HMIS case management, CoC case management, or supportive housing case management software. The newest generation adds intelligence to the record itself: AI reads each navigator field note on arrival, scores it against the housing plan with citations, and turns the HMIS, CoC, and HUD reports into one query — so the software answers whether the client actually got housed and stayed housed, not just what services were logged.
Used by: HUD-funded CoC (Continuum of Care) lead agencies and member organizations · transitional housing and Rapid Re-Housing (RRH) programs · Permanent Supportive Housing (PSH) providers · emergency shelters and street-outreach teams · group homes and residential programs · ESG, HOPWA, and tenant-based rental-assistance grantees.
Not because the software stopped working — because getting the universal data elements in and the export running became table stakes. HMIS-aligned systems like WellSky ServicePoint, Eccovia ClientTrack, CaseWorthy, and Bonterra (ETO, Social Solutions, Apricot) earned their positions honestly: they got the CoC out of the filing cabinet, standardized the intake, and gave lead agencies a HUD-approvable system of record. If your problem was compliance — hundreds of clients, a dozen navigators, one APR deadline — that generation solved it.
But the strengths hardened into weaknesses. Implementations run months to a year; agencies describe legacy builds where every new funding stream or HUD element change is another integrator engagement. The logic is rigid by design, and the richest evidence those systems hold — the navigator field notes — dies after collection: narrative piles up in a system nobody reads across, and the analytics describe what was entered, not what changed. A program lead running services across sites put the pattern plainly: they could track "outputs and dollars and volunteer hours," but "the biggest pain point is that we can't tell a cohesive story across all of it. Each thing works fine in a silo."
The cost of not reading is concrete in housing. The lease violation about to evict a client, the safeguarding flag, the navigator caseload silently drifting — those sit in case notes until someone reads them at month-end. As one practitioner described it, case notes end up "just sitting around in the systems… by the time they find out, you already failed" the person you were trying to house. The work that decides whether a program is well run has moved to the two ends the record-keeping tools never owned: reading every field note on arrival, and proving the outcome — exit to permanent housing, returns to homelessness at 6 and 12 months — on the same client months and years later.
None of this requires replacing your HMIS. The sentence we hear on almost every call now: "We're not gonna leave our system, but we're open to an AND." Keep the HUD-approved system of record; add the layer that reads what it produces and runs alongside it.
The stake, stated honestly: HUD and CoC boards have already changed the question from "how many did you serve" to "did they get housed, did they stay housed, and can you show it." If you are signing a multi-year configuration build today, ask which question it will be able to answer when it finally goes live.
Housing intelligence is reliable answers from your housing case data — in minutes, not months. Everything a client touches is treated as data: the CES screen, the VI-SPDAT, the intake, the housing-stability plan, every navigator note, the shelter or lease milestone, the 6- and 12-month follow-up. All of it lands on one persistent client record — one ID assigned at Coordinated Entry — so the same person looks like the same person across outreach, shelter, RRH, and PSH, from year-0 CES to year-1 return-tracking.
The part that changes daily work is the Assistant. Caseload analysis, VI-SPDAT scoring, and open-text case-note reading are unified into one chat-based function: ask a question, get a defensible answer with citations to the underlying records. No prompt engineering, no dashboard hunting, no waiting for the one analyst who knows where the HMIS export lives. A program is never one user — navigators, program managers, finance, the CoC lead, HUD monitors, and the clients themselves all need different views of the same record — and a chat interface empowers each of them directly.
When the analysis is done, it does not die in the chat: create shareable reports tailored to each audience — the navigator's caseload view, the CoC APR/CAPER submission, the funder outcome report — from the same underlying answer, each number traceable to the source case note.
One proof point from the field. Open Play Foundation ran programs the way most funded organizations do — intake forms, follow-up reflections, stacks of narrative that never made it past the spreadsheet. When that 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. A system of record tells you the bed-night was logged. An intelligent record tells you a client is about to lose their lease in time to act.
The honest way to evaluate housing case management software is against the lifecycle, not the feature list. Nearly every CoC describes the same arc — and it is a loop, not a line: follow-up routinely sends a re-engaging client back to Coordinated Entry. Below is the full cycle — six stages, 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.
Coordinated Entry is where clean-at-source pays or fails. Instead of free-text answers a navigator will pay to decode later, the CES form is designed so every narrative field maps to your HMIS data dictionary, and every client gets a persistent unique ID that follows them from CES through year-1 follow-up. VI-SPDAT scoring, priority-queue placement, consent capture, save-and-return — and AI drafts the intake from the CES assessment and program documents you already have.
Build a Coordinated Entry intake form from this program description: [PROGRAM URL OR DOCUMENT]. Create structured fields for HMIS universal data elements, demographics, and consent; a VI-SPDAT scoring block with priority-queue thresholds; and narrative fields for housing barriers mapped to our housing-stability framework. Assign a persistent client ID at CES, and flag any question that collects information we already hold on returning clients.
Expected output. A ready-to-edit CES intake form: HMIS-aligned structured fields, VI-SPDAT scoring, mapped barrier prompts, and a persistent client ID assigned at first contact.
Tips for reliable output. Give the AI your HMIS data dictionary and housing-stability framework before form design. Assign the client ID at CES, not at enrollment — every navigator note, bed-night, and lease milestone downstream attaches to the ID created here.
The baseline is the reference every later wave is compared against. The VI-SPDAT, the barriers assessment, and the intake narrative land on the same record, and the assessment is read the moment it arrives — housing barriers, risk factors, and protective factors extracted and cited, not left in a folder until a client is already back on the street.
From this housing intake assessment, extract the client's baseline housing barriers, risk factors, and protective factors, each with the exact source sentence. Score the VI-SPDAT included, flag any safeguarding, domestic-violence, or immediate-risk language for human review, and note where the assessment is incomplete. Do not infer a diagnosis — report only what the text supports.
Expected output. A structured housing baseline with per-item evidence, a scored VI-SPDAT, and a flagged list of risk or safeguarding language routed to a human.
Tips for reliable output. Lock the baseline before services begin — a baseline captured at CES, even on a handful of clients, proves the loop works before anything scales.
Every client gets a housing-stability plan built from the assessment and mapped to your framework — goals that are observable, timelines that are real, and the outcome each supportive service is meant to move. The plan becomes the thing navigator notes are later read against.
Draft a housing-stability plan from this assessment: [ASSESSMENT]. Map each identified barrier to a measurable goal, a supportive service or referral, and the outcome indicator it should move, aligned to our housing framework and HUD-required outcomes. Write goals as observable statements a navigator can evidence, and flag any barrier with no service currently available.
Expected output. A housing-stability plan with measurable goals, mapped supportive services, outcome indicators, and a gap list where barriers have no matching service.
Tips for reliable output. Name the outcome for every goal — exit to permanent housing, lease retention, income stability. A plan that can't say what success looks like can't be evaluated at exit.
This is the stage HMIS cannot do. Every navigator field note is read as it lands — offline-safe from encampment outreach, motel inspections, and home visits, then read on arrival when the worker syncs back online — coded against the housing plan, with risk signals (lease violations, missed appointments, disengagement, safeguarding language) surfaced the week they appear instead of at month-end. The narrative stays with the navigator; the structure is generated and tied back to the source sentence.
Read this batch of navigator case notes: [NOTE BATCH]. For each client, summarize progress against the housing-stability plan with citations, code the note against our outcome indicators, and flag risk signals — lease violations, missed appointments, disengagement, safeguarding or escalation language — with the exact source sentence, broken out by navigator and building. Use the same method as last month so results are comparable.
Expected output. Per-client progress summaries with citations, coded outcome evidence, and a risk-flag list with sources — the day notes are written, not six weeks later.
Tips for reliable output. Route every risk flag to a named owner with a deadline. A lease-violation flag nobody owns is an eviction that sat there.
Move-in is not the end of the record. The 6-month and 12-month follow-ups land on the same client ID as the CES screen, so the question every CoC asks — did the client stay housed, or return to homelessness — has a reproducible answer instead of a name-match reconstruction across systems. Re-engaging clients arrive with their full history attached.
Compare the CES baseline to the [6-month / 12-month] follow-up across [COHORT / PROGRAM]: which housing outcomes moved — exit to permanent housing, returns to homelessness, income and lease stability — by how much, and with what confidence? Show change per indicator, note where the sample is too small to conclude, and pair every number with a representative case-note quote. Treat this as change over time, not attribution.
Expected output. A baseline-to-follow-up outcome analysis — exit-to-housing and returns-to-homelessness with honest confidence bounds and a narrative quote behind each number — the longitudinal view a persistent ID makes possible.
Tips for reliable output. Capture contact channels and follow-up expectations at CES, not at exit. The longitudinal horizon is what separates an exit destination from a stability outcome.
Reports are questions, not formats. From the same accumulating client record, the caseload report, the HMIS export, the CoC APR/CAPER, and the returns-to-homelessness cohort are each one query — with the supporting navigator note two clicks away — instead of a two-to-four-week reconstruction joining CES, services, and exit data across systems.
Aggregate this program's client records into a [HMIS export / CoC APR / CAPER] submission: outcomes achieved against HUD targets, coded case-note themes ranked by frequency with representative quotes, demographic distribution, and clients flagged as missing a required data element or follow-up. Cite the source client record for every number and quote. Format one version for the CoC lead and one for the funder.
Expected output. A HUD-ready HMIS or CoC submission generated as a query, every figure citing its source record — plus the "missing element" list surfaced before the submission deadline asks.
Tips for reliable output. Lock the data dictionary before the first reporting cycle and version every HMIS element — comparability across annual cohorts is the entire value. For the HUD data standards themselves, anchor to the HUD HMIS program standards so your elements stay comparable across the CoC.
Beyond table stakes — CES intake, caseload views, bed-night logging, HMIS elements, security — five criteria actually separate tools: time to first live cycle (days vs. a quarter), whether AI reads navigator notes on arrival or a program manager still samples them by hand, whether field navigators can write offline and have notes read on sync, whether the CoC export is a query or a custom build, and whether the platform can prove housing outcomes (exit-to-housing, returns-to-homelessness) rather than just count bed-nights. Ask every vendor to show the returns-to-homelessness report on real data, not a slide.
The evaluation itself is work you can delegate to AI. These prompts mirror what buyers are already asking answer engines — use them as they are:
Build an evaluation matrix for housing case management software with technical and program criteria weighted 50/50. Technical: security and field-level access control, running alongside our approved HMIS (ServicePoint, ClientTrack), offline field capture, data export and exit rights. Program: AI navigator-note reading with citations, one client ID from CES to year-1, VI-SPDAT and CES support, returns-to-homelessness tracking, HMIS and CoC report generation. Score vendors [VENDOR LIST] on each criterion with evidence required, not vendor claims.
Propose a 30-day pilot plan to evaluate housing case management software: one program, one cohort of roughly 50 current clients, tested end to end (CES → assessment → housing plan → navigator-note reading → returns report), with numeric success thresholds and rollback criteria if the pilot fails.
A note on scope while you evaluate: the same spine adapts by vertical with a different intake and funder report — human services case management software, nonprofit case management software, social work case management software, and community action agency software each cover their fit directly. For the note layer itself, see case notes software; for the full category, the case management software hub. To coordinate every relationship on one record, see 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 property management system, and not your HMIS. A property management system (Yardi, RealPage) tracks tenant payments and lease compliance; the HMIS is your CoC's HUD-approved system of record for compliance reporting. Housing case management software tracks the client through the services lifecycle — from CES to housed to year-1 follow-up — with navigator narrative and outcome evidence at the center. Sopact often runs alongside the approved HMIS as the AI reading layer rather than replacing it.
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 program is subject to HUD VAWA confidentiality, HIPAA, 42 CFR Part 2, or state behavioral-health rules, evaluate these controls against your compliance program, consult your CoC lead and counsel, and confirm scope in writing before storing protected information. And if your use case is purely a data warehouse, Sopact is not the ideal system for that.
Housing case management software is a platform that runs the full housing-services lifecycle — Coordinated Entry, VI-SPDAT, navigator outreach, shelter intake, supportive-services case notes, exit planning, and 6- and 12-month follow-up — on one persistent client record, so navigators, program managers, and CoC leads get answers without a multi-system merge. It generates HMIS exports and CoC submissions as queries. The newest generation adds AI that reads each navigator note on arrival and turns follow-up into cited returns-to-homelessness evidence.
Yes. For HUD-funded CoC, RRH, PSH, and transitional housing programs, the software should support HMIS universal data elements and program-specific elements out of the box, VI-SPDAT and CES assessment, field-worker mobile notes with offline sync, and HMIS exports and HUD-required reporting as queries. Sopact adds AI that reads navigator notes on arrival and tracks returns to homelessness on the same client ID from CES to year-1 follow-up.
Sopact reads HMIS-aligned data elements and produces the export format required for CoC submissions — HMIS export, CoC APR/CAPER, ESG report, and returns-to-homelessness cohort — each as one query against the persistent client records, with the supporting note two clicks away. HMIS-compliance is also a function of your CoC lead agency's approved-vendor list; some CoCs require a specific HMIS for the system of record, so Sopact often runs alongside an approved HMIS as the AI reading layer rather than replacing it.
Sopact supports CES assessment, VI-SPDAT scoring, and the housing-priority queue. The persistent client ID assigned at Coordinated Entry survives through navigator outreach, shelter intake, transitional or PSH placement, and supportive-services case notes — so the same person is one record from first screening to year-1 return tracking, not a fresh case each time they touch a new program.
Yes. Emergency shelters and street-outreach teams use the same persistent client record: bed-night logging and intake screening for shelters; offline-safe mobile contact logs, encampment location, and VI-SPDAT for outreach. Every field note is read on arrival when the worker syncs back online, and risk signals surface to the program manager mid-month instead of at the exit interview.
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. Sopact is not currently HIPAA-certified or covered by a Business Associate Agreement; if your program touches protected information under HUD VAWA confidentiality, HIPAA, or 42 CFR Part 2, treat that as gating, consult your CoC lead and counsel, and confirm scope in writing. Sensitive fields can be excluded from AI processing entirely, and analysis can run on anonymized IDs.
Eccovia ClientTrack, CaseWorthy, and WellSky ServicePoint are HUD-approved HMIS systems that serve well as the system of record. All were built for compliance reporting, not for reading; none reads navigator notes on arrival. Sopact often runs alongside an approved HMIS as the AI reading layer — the HMIS owns compliance reporting and CoC submission approval; Sopact owns the case-note intelligence, risk-signal surfacing, and returns-to-homelessness tracking on the same client ID. It avoids both the configuration cost and the year-end reporting cost, and coexists rather than replacing.
Six questions separate platforms that work from platforms that only demo well: How long until our first cycle is live? Will every navigator note get read, or just the ones a manager samples? Can field navigators write notes offline and have them read on sync? Does the same client ID survive from CES to 12-month follow-up? Is the CoC export a query, or a custom build? And when a HUD monitor asks why this outcome, can I show the supporting note in two clicks? Then run a contained pilot on your own data before you commit.
Two months, one contained use case — one program, one CES intake, one cohort of clients you already serve. You bring last year's navigator notes and your VI-SPDAT data; the pilot shows you the coded, cited version of your own caseload — notes read on arrival, risk signals surfaced, the next CoC submission as one query — ending with a demonstrated export. If the returns-to-homelessness answers aren't defensible in front of your CoC lead or a HUD monitor, don't continue. Scope a 2-month pilot →