Refugee Resettlement Case Management Software: Why Reception and Placement Breaks Your Spreadsheets

Why resettlement software fails when it is built like clinical case management

A family of seven lands at 11:40pm on a Thursday. The apartment was secured that afternoon after a lease fell through on Tuesday, so two volunteers are still assembling beds while the caseworker drives to the airport. There is a culturally appropriate meal in the fridge, which is a requirement and not a courtesy. Within a day someone has to conduct the first home visit. Within the first weeks the family needs a health screening appointment, school enrolment for three children, Social Security applications, an orientation delivered in a language the caseworker does not speak, and an employment plan for the two adults. Every one of those deadlines is counted from the arrival date, not from when the caseworker got to the file.

The tooling is usually Eccovia ClientTrack or CaseWorthy or Apricot by Bonterra, plus the national resettlement agency's own database, plus a spreadsheet the resettlement director actually trusts, plus a folder of scanned receipts. Those products are competent human services case management systems. ClientTrack in particular is widely deployed across homelessness and social services and it does what it was designed for. The mismatch is structural: those systems model a client who presents with a need, gets assessed, receives services, and closes when goals are met. Resettlement does not work that way. Your client arrives on a plane on a date set by someone else, and a federal cooperative agreement starts a clock that does not care about your caseload, your staffing, or whether the apartment was ready.

Problem 1: the deadline clock is federal, and it starts before your file does

Reception and placement services run on a defined period after arrival, with the earliest obligations landing within the first day and the core service package within the opening weeks. Confirm the exact current requirements against your national agency's cooperative agreement and its guidance, because the detail is revised and you should never take a blog's word for a compliance date. The operational point is stable regardless of the version: every deadline derives from a date you did not choose, and the consequences of missing one fall on the affiliate agreement rather than on an individual case plan.

Generic case management systems compute due dates from enrolment, which is the day your staff created the record. If the assurance came late, or a name was misspelled and the record was created twice, or the arrival was rescheduled by a week, your due dates are wrong and confidently displayed. We have seen affiliates run two parallel trackers precisely because nobody trusts the system's dates.

What a custom build does: arrival date is the anchor and every milestone is derived from it, recomputed automatically when a flight changes. Milestones carry an evidence requirement, so marking orientation complete without an attached signed acknowledgement leaves the item in an incomplete state rather than green. The dashboard is ordered by days remaining across the whole caseload, not by case, because the question a resettlement director asks at 8am is which deadlines fall this week across everyone, and no case oriented system answers that well.

Problem 2: a case is a family unit, and family units split

A case arrives as seven people. Three months later two adult members move to another state to join a cousin, which is secondary migration, and the remaining five stay. Or a case is assigned to your affiliate and the anchor relative is in a different city, so services split across two affiliates from day one. Or a family arrives as one case and a household member needs to be tracked separately for a different programme enrolment.

What a custom build does: the case is a first class object with dated membership, so a person can leave a case on a specific date and the funded per capita allocation for that person can be reconciled correctly. Splits and transfers to another affiliate are recorded transactions with a receiving party and a documented handover, not a manual re-entry. Individual level services attach to people, case level services attach to the case, and reports can present either lens without a data manager stitching them together.

Problem 3: per capita money is documented item by item, and auditors read receipts

The direct assistance a family receives is funded per person and has to be documented specifically. Rent for the first period. A security deposit. Furniture. Kitchen equipment. Clothing appropriate to the season. Transport. Each of those becomes a receipt, a signature, and an allocation to specific individuals within a case. Right now it is a shoebox of receipts, a Google Sheet, and a scramble two weeks before a monitoring visit.

What a custom build does: expenditure lines are created against a case with an allocation rule, receipts are captured on a phone at the point of purchase and attached immediately, and the per capita balance for each case is visible while there is still time to act on it. Client signature capture happens on the same device at handover of goods. This is where machine assistance genuinely earns its place: receipts photographed in a furniture store car park become structured lines with vendor, date, amount and tax extracted for a caseworker to confirm with one tap. It is unglamorous and it removes hours a week from people who should be with families.

Problem 4: everyone types the same data twice, and the exports never quite match

Your national resettlement agency runs its own database and requires submissions in its formats. Your state refugee coordinator and the Office of Refugee Resettlement funded programmes want their own reporting. Your affiliate wants operational visibility. So a caseworker enters a placement into the national system, then into the local tracker, then emails a summary. Every transcription is an opportunity for divergence, and by quarter end the numbers disagree.

What a custom build does: your system is the operational source of record and produces submissions in the exact layouts required rather than a generic export that somebody reformats. Where the national agency offers an interface, integrate to it. Where it does not, generate a file that matches the specification exactly and keep a submission log with what was sent and when, because the argument you eventually have will be about whether something was reported and on what date. Design this with your national agency's requirements in front of you and confirm current formats with them directly, since they change more often than anyone would like.

Problem 5: language access is an operational constraint, not a note in the file

Services must be delivered in a language the client understands. That means interpreters are scheduled, paid, and sometimes unavailable on the day, and it means written materials exist in multiple versions with different revision dates. It also means the caseworker who speaks the household's language has a caseload that is not evenly distributed with her colleagues, which is a staffing reality no scheduling module accounts for.

What a custom build does: language is an attribute on the person, interpreter bookings are a scheduled resource with cost tracked against the right funding source, and materials issued to a household record their language and version so an audit can show what was actually provided. Caseload balancing accounts for language capability, which stops one bilingual staff member quietly carrying a third of the programme until she burns out. Machine translation has one honest role here, drafting routine written communications for a bilingual staff member to review before sending. It has no role in interpreting a legal explanation of rights or an orientation on public benefits, and any developer who suggests otherwise does not understand the exposure.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, here is the honest shape for this category. A first release covering case and family unit records anchored to arrival date, derived milestone deadlines with evidence requirements, per capita expenditure documentation with receipt capture, and export in your national agency's required format runs $60,000 to $130,000 and ships in 12 to 16 weeks. A full platform adding employment placement and job retention tracking, interpreter and language access, secondary migration and affiliate transfers, in kind goods inventory, volunteer coordination and multi programme enrolment runs $150,000 to $380,000 phased over 6 to 12 months.

What pushes cost up specifically for affiliates: the number of distinct funded programmes you operate, since each carries its own eligibility, service definitions and reporting. Integration with your national agency's systems, which depends entirely on what they expose. Multi site operations under different state coordinators. And document heavy workflows, because scanning, indexing and retention of immigration and identity documents is a security obligation rather than a file upload.

What keeps cost down: building the arrival to 90 day core services path first and leaving employment, extended services and volunteer coordination for phase two. That path is where the compliance risk concentrates.

Build versus buy, and when buying is the right call

Buy if you resettle fewer than roughly 100 arrivals a year with one or two caseworkers. A disciplined shared drive, a calendar with derived deadlines and a receipts folder genuinely works at that size, and custom software would be an expensive way to formalise what two people already do well. If your organisation runs a broad human services portfolio where resettlement is one programme among many, ClientTrack or CaseWorthy may be the right central system and a smaller resettlement specific layer around it is a better investment than replacing everything.

Build when two or more of these are true. You resettle more than about 250 arrivals a year. Your staff enter the same case into two systems. Your per capita documentation is assembled retroactively before monitoring. You operate more than one funded programme with different eligibility and reporting. Or a monitoring visit has already produced a finding on documentation or timeliness.

Our position: the arrival anchored deadline engine and the per capita ledger are the two features that justify a build. Everything else in this category is ordinary case management that you can buy. If a vendor cannot show you a caseload view sorted by days remaining against arrival date, they have not built for resettlement, whatever the brochure says.

How to choose a developer for resettlement case management software

Ask them to model the case before you sign anything. A developer who has done this work will draw a case with dated membership, an individual, a derived milestone with an evidence requirement, an expenditure line with a per capita allocation, and a transfer to another affiliate. A developer who draws clients and services has built a generic case management system and will hand you the same mismatch you already have.

Ask what happens when an arrival date changes after the record is created. If milestone dates do not recompute automatically, your staff will keep the shadow spreadsheet forever and the build has failed.

Ask how they handle document storage and retention for immigration and identity records. Encryption, role based access, an access log and a defined retention schedule should come up unprompted. If the answer is a file field on the client record, keep looking.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the cloud accounts and the right to hire anyone else to continue the work. At Digital Heroes the client owns the code from the first commit. Affiliate funding moves with arrival numbers, and an affiliate locked into a vendor during a lean year is in a much worse position than one that owns its system outright.