What slow intake actually costs an NGO

A caseworker sits with a beneficiary and writes the same details onto a paper intake sheet. Later, someone types those details into a Google Form. The caseworker spends 45 minutes on one intake.

The beneficiary waits. The caseworker falls behind. At the end of the day, six completed intakes sit in a folder, and the remaining appointments move to next week.

I have seen the same pattern in digital form. The paper disappears, but the delay stays. A form asks for a person’s name, phone number, address, household size, and program history. Another form asks for the same details. A spreadsheet holds a third copy.

The problem is not paper. The problem is repeated work.

The math is not complicated

In one anonymized project, an intake took 45 minutes. We changed the form flow, removed duplicate data entry, and auto-filled information already held in the organization’s records. The same intake then took 12 minutes.

That saved 33 minutes per beneficiary.

Now put a weekly number beside it. Suppose the team handles 40 intakes each week.

Forty intakes multiplied by 33 saved minutes equals 1,320 saved minutes. That is 22 hours every week.

If the staff cost is $12 per hour, the weekly labor value is:

22 hours × $12 = $264 per week

Across 52 weeks:

$264 × 52 = $13,728 per year

At $18 per hour, the yearly value becomes:

22 hours × $18 × 52 = $20,592

That is the visible cost. It is easy to explain to a finance manager because the arithmetic fits on one page.

The number changes with the workload. At 20 intakes per week and $12 per hour, the saved time is 11 hours per week, or $6,864 per year. At 80 intakes per week, the same design change saves 44 hours each week. That is more than one full-time work week.

The organization does not always turn those saved hours into a payroll reduction. That is not the point. Staff can call beneficiaries back. They can check eligibility carefully. They can visit field sites. They can submit reports before the deadline.

Time returned to a team still has a financial value.

The cost that never appears in the budget

Repeated typing creates errors. A phone number loses a digit. A household size changes from five to eight because someone clicked the wrong cell. A surname appears with two spellings, so the same person gets two records.

Those errors do not stay inside the intake process. They move into attendance sheets, referral lists, payment files, and donor reports.

Duplicate records create another problem. A program manager may think 300 people received support when the actual number is 276. A finance team may count the same beneficiary twice. A caseworker may miss a previous referral because the history sits under a second spelling.

The beneficiary pays a different cost when the system makes them repeat their story.

Someone explains a housing problem to one caseworker. Then they explain it again at the registration desk. Then a partner organization asks for the same details because the first record never reached them.

This is not just annoying. It affects dignity. People who ask for assistance already have limited control over the situation. Making them repeat personal details because the organization cannot find its own record adds another burden.

Grant reporting exposes the delay. A funder asks for a monthly figure on the 5th. The organization closes the reporting period on the last day of the previous month. Staff spend the first four days checking separate spreadsheets, asking field workers for missing entries, and trying to reconcile two totals that should have matched.

The report may still go out. The team may still receive the grant. But the organization spends scarce attention proving what happened instead of improving the program.

What actually fixes the intake

The fix usually starts with one intake form.

That does not mean one enormous form with every question the organization has ever asked. It means one controlled entry point for the core record. Every program can collect its own extra details after the shared information exists.

The first page should ask only what determines the next step. If the person needs food support, show the food-support questions. If the person needs a referral, show the referral questions. Do not make every beneficiary answer questions that apply to one program.

Conditional fields matter because they remove irrelevant work. A beneficiary should not see twelve questions about school enrollment when they are applying for emergency rent support.

Auto-fill handles information the organization already knows. A returning beneficiary should not type their full address again. A staff member should be able to search for the existing record, confirm the identity, and update only what changed.

That confirmation step matters. Auto-fill should not quietly copy stale information. The system should show the existing value and ask the staff member to verify it.

A shared database should hold the record. It can be a small, well-managed application. It does not need to begin as a major CRM purchase. The important point is that the intake form, case notes, referral history, and reporting view read from the same source.

Parallel spreadsheets create parallel truths. One file belongs to the program officer. Another belongs to finance. A third sits in a shared folder with a filename that ends in final-v7. No one can tell which one controls the record.

A single database does not solve every data problem. It does make ownership visible. The organization can define which fields matter, who can change them, and when a record counts as complete.

What does not fix it

Buying a large CRM does not fix an intake process by itself.

A system with 200 features still produces poor data when nobody configures the fields, defines the workflow, or trains the team. Some organizations pay for a platform, import old spreadsheets, and keep using email because the new process feels harder.

Adding a second form tool usually creates another copy of the same problem. One department uses Google Forms. Another uses Typeform. A partner sends a spreadsheet. The data team spends its week moving rows between systems.

Hiring another data-entry person can reduce the queue for a while. It does not remove the duplicate fields or the repeated record matching. The new person becomes responsible for cleaning a process that should have been designed correctly.

Start with the path a caseworker follows. Count the minutes. Mark every field typed twice. Find the point where a returning beneficiary becomes a new record. Then remove that work before buying anything.

The useful question is not, “Which platform should we adopt?” It is, “Why does this person need to enter the same fact again?”