Refugee Resettlement Case Management Software Problems: The 7 That Cost Real Money and How to Avoid Them

Why does the generic case management model get chosen so often?

The biggest scope failure in this category is agreeing to a build, or a configuration, that models resettlement as clinical case management. It is an easy mistake because the vocabulary matches. There is a client, an intake, an assessment, a service plan and a closure, and every human services product on the market is built around exactly that shape.

Resettlement does not work that way. Your client arrives on a plane on a date somebody else chose, and a federal cooperative agreement starts a clock that does not care about your caseload, your staffing, or whether the apartment was ready. The first obligations land within the first day, before anyone has done an assessment. A family of seven arriving at 11:40pm on a Thursday needs a home visit, a health screening appointment, school enrolment, Social Security applications and an orientation delivered in a language your caseworker may not speak, all measured from touchdown.

The fix is to make arrival date the anchor object in the data model before anything else is designed, and to derive every milestone from it, recomputing automatically when a flight changes. Milestones carry an evidence requirement, so marking orientation complete without an attached signed acknowledgement leaves the item incomplete rather than green. And the primary view is the caseload sorted by days remaining across everyone, because that is the question a resettlement director asks at 8am and no case oriented system answers it well. Confirm the current requirements against your national agency's cooperative agreement, since the detail is revised and no published summary should be treated as authoritative.

What goes wrong when existing case data is migrated?

Almost every affiliate arrives with three sources: the national agency's database, a local spreadsheet the director actually trusts, and a shared drive of scanned documents. Reconciling them is where these projects lose time, and the cause is almost always names.

Transliteration produces the same person under several spellings, and family naming conventions vary in ways that do not map onto a first name and last name field. So the spreadsheet has one record, the national database has another, and a third was created when a caseworker could not find the first two. Deduplicating on name alone will merge two different people, which is a far worse outcome than leaving duplicates in place.

The second problem is household structure. Legacy records usually carry a household as a grouping label rather than as an entity, so there is no record of who belonged to which case on which date. Once a family has split, the historical allocation of per capita funds cannot be reconstructed from that data at all.

The fix is to migrate conservatively and explicitly. Match on stable identifiers rather than names, route ambiguous matches to a human queue rather than resolving them automatically, and preserve every legacy identifier on the new record so an old reference can still be traced. Accept that historical household membership will be approximate, mark it as such, and start dated membership properly from go live rather than pretending the past is cleaner than it is. Budget real staff time for the review queue, because caseworkers are the only people who can resolve those matches.

Why do the reporting integrations break after launch?

Four connections carry a resettlement system and each fails differently once the project team has moved on.

The national agency's database is first and hardest. Where an interface exists, integrate to it. Where it does not, generate submissions matching the required layout exactly and keep a submission log recording what was sent and when, because the disagreement you eventually have will be about whether something was reported and on what date. Formats change, sometimes with limited notice, and a build with no owner for that maintenance starts failing quietly a year after go live.

State coordinator and Office of Refugee Resettlement funded programme reporting is second. Each programme has its own service definitions and eligibility, so a field that means one thing in reception and placement means something slightly different in Matching Grant, and a single export template will be wrong for one of them.

Finance is third. Per capita expenditure has to reconcile with what the accounting system recorded, and if the two are entered separately they will diverge. Decide which system is authoritative for the expenditure line before either is built against.

Document storage is fourth, and it fails on security rather than function. Immigration and identity documents need encryption, role based access, an access log and a defined retention schedule. A file upload field on a client record is not a document management approach, and it is the thing a monitoring visit will ask about.

What happens when per capita documentation and language access are not covered?

Two gaps produce most of the findings, and both are routinely postponed to phase two.

Per capita documentation first. Direct assistance is funded per person and must be documented specifically: rent, security deposit, furniture, kitchen equipment, seasonally appropriate clothing, transport. Each becomes a receipt, a signature and an allocation to named individuals within a case. Left out of the build, it stays as a shoebox of receipts and a spreadsheet, reconstructed in a scramble two weeks before a monitoring visit. Built in, expenditure lines are created against the case with an allocation rule, receipts are photographed at the point of purchase and attached immediately, signatures for goods handover are captured on the same device, and the remaining balance is visible while there is still time to act on it.

Language access second. Services must be delivered in a language the client understands, which makes interpreters a scheduled, paid resource that is sometimes unavailable, and makes written materials a set of versions with different revision dates. It also means the caseworker who speaks the household's language carries an unevenly distributed caseload that no standard scheduling module accounts for.

The fix is to treat language as an attribute on the person, book interpreters as a resource with cost tracked against the correct funding source, and record the language and version of every material issued so an audit can see what was actually provided. Caseload balancing should account for language capability, which stops one bilingual staff member quietly carrying a third of the programme until she leaves.

Should you build custom or configure what you already own?

Some affiliates should not build, and it is worth hearing that on the first call. Below roughly 100 arrivals a year with one or two caseworkers, a well structured shared drive, a calendar with deadlines derived from arrival dates and a disciplined receipts process genuinely works. Custom software would be an expensive way to formalise what two people already do well, and the money belongs in rent assistance or another caseworker.

Configuring what you own is the right answer when resettlement is one programme inside a broad human services portfolio. Eccovia ClientTrack, CaseWorthy and Apricot by Bonterra are solid systems doing what they were designed for, and if your organisation already runs one of them across homelessness or family services, keeping it as the central record and building a smaller resettlement specific layer around it is usually a better investment than a replacement. The layer that matters is the arrival anchored deadline engine and the per capita ledger. Everything else in this category is ordinary case management you can configure.

Build when two or more of these hold. You resettle more than about 250 arrivals a year. Staff enter the same case into two systems. 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.

How do hidden costs get into the quote?

Estimates move in predictable places here, and all of them can be established before signing.

• Number of funded programmes. Each carries its own eligibility, service definitions and reporting, so operating reception and placement alongside Matching Grant and refugee support services is three sets of rules rather than one with variations.
• National agency integration. The cost depends entirely on what they expose, and finding out is a conversation to start before development rather than during it.
• Multi site operations. Different state coordinators mean different reporting and sometimes different service definitions for the same activity.
• Document handling. Scanning, indexing, access control and retention for immigration and identity records is a security workstream, not a file upload.
• Data migration review. The ambiguous name matches can only be resolved by your caseworkers, and that time has to be planned around their actual caseload.
• Interpreter and materials management. Often deferred, then added later at higher cost because it touches scheduling, cost allocation and document versioning at once.

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

The builds that work anchor everything to arrival date, recompute when a flight moves, and treat the case as a first class object with dated membership so a person can leave on a specific date and the per capita allocation reconciles correctly. Secondary migration and transfers to another affiliate are recorded transactions with a receiving party and a documented handover rather than a re entry that severs the link to the original case. Evidence is required to close a milestone, not merely encouraged.

The builds that fail keep the shadow spreadsheet alive. If a director still maintains a private tracker six months after go live, the system has not replaced anything, and the usual reason is that its dates cannot be trusted or its caseload view cannot answer what falls due this week.

On machine assistance, two uses genuinely earn their place and one does not. Receipt extraction turns a photograph taken in a car park into a structured expenditure line for one tap confirmation, and drafting routine written communications for a bilingual staff member to review before sending saves real time. Machine translation has no role in interpreting rights, benefits orientation or anything with legal consequence, and a developer who proposes it does not understand the exposure.

Two tests before signing. Ask what happens when an arrival date changes after the record is created, and expect every milestone to recompute automatically. Ask how immigration and identity documents are stored, and listen for encryption, role based access, an access log and a retention schedule raised without prompting. Then settle code, infrastructure and data ownership in writing, since affiliate funding moves with arrival numbers and a vendor dependency during a lean year is a poor position to be in.