Reporting is a cost the provider pays first
A community provider with six staff and a waiting list does not experience reporting as data. It experiences it as the hour on Friday afternoon when the program coordinator stops returning calls and starts retyping attendance sheets into a funder's spreadsheet. Every field a funder adds is paid for in that hour, and the provider pays before anyone else sees a number. Reporting that a provider can sustain is designed from that hour backward.
The funder's instinct runs the other way. A new board member asks a question, a legislator wants a breakdown, an evaluator needs a covariate, and each request becomes a column. None of them is unreasonable alone. Together they produce a form that takes forty minutes per participant, gets filled in late and partially, and yields data nobody trusts enough to act on.
The fix is a design discipline, applied at the start and again every year: collect the least data that answers the questions someone will act on, make it fast to enter, define it once, check it at the door, and hand it back to the people who entered it. The rest of this piece walks through each of those, in the order you would build them.
Start from the decision, not the form
Every field on a reporting form should be traceable to a decision. Not a topic, a decision: something a named person will do differently depending on the value. Before a field goes on the form, write three things next to it. Who reads it. What they do when it goes up or down. How often they need to know.
Most forms fail this test on a third of their fields. "Household size" is collected because it might matter for eligibility, but eligibility was settled at enrollment and nobody reads the monthly value. "Number of referrals made" is collected but no one has decided what a good number is, so it is reported, filed and never discussed. A field that cannot name its reader is a cost with no return, and it lowers the quality of every other field because it adds to the time the provider spends on the form.
Run this exercise with the people who will use the data, in one working session, with the current form on the screen. Strike the fields nobody claims. Move the fields only an evaluator needs into a separate, time-limited collection with its own budget. What remains is your minimum data set.
A minimum data set that fits on one screen
The table below is a starting point for a direct-service program: case management, workforce, housing navigation, youth services, anything where a person enrolls, receives services and leaves. Adapt the definitions to your program, but keep the shape. Each field has one definition and one reason to exist.
| Field | Definition | Why it is needed |
|---|---|---|
| Participant ID | A program-assigned number, generated by the system at enrollment. Never a Social Security number | Counts unique people across months and sites without moving identity data around |
| Enrollment date | The date the participant signed the intake form and became eligible to receive services | Defines the active caseload and the start of every length-of-service measure |
| Service type | One value from a shared list of no more than eight categories, each with a written definition | Shows what the money bought and lets the funder compare sites on the same terms |
| Service date and units | The date of contact and the number of units, where the unit is defined in the dictionary, for example one session of at least 15 minutes | Supports billing reconciliation and shows dosage, which drives most outcome questions |
| Referral source | Where the participant came from, chosen from a short list that includes "self" and "other" | Tells the network which partnerships produce enrollments and which do not |
| Primary outcome | One outcome per program, defined with its measurement point, for example "employed 30 or more hours a week at 90 days after exit" | The single number that answers whether the program works for the people it serves |
| Exit date and reason | Date of last service and one reason from a fixed list: completed, moved, lost contact, referred elsewhere, other | Closes the record, so the caseload is accurate and outcomes are measured at the right time |
| Geography | ZIP code or county of residence at enrollment, not a street address | Answers where services reach, which councils and boards always ask, without holding addresses |
Demographics deserve their own rule. Collect only the categories the funder is required to report, use the categories the funder reports in, and always offer "prefer not to answer" without penalty. If your funder reports to a federal agency, ask which version of the federal race and ethnicity standard they use. OMB revised that standard in 2024 to a single combined question with a Middle Eastern or North African category, and a mismatch between your form and the funder's report creates a year of manual recoding.
Monthly beats weekly for almost everything
Weekly reporting feels responsive. In practice it produces four partial submissions a month, each with its own late entries and corrections, and a funder who spends Mondays chasing stragglers. The data is no more current, because providers batch their entry anyway. They just batch it four times.
Monthly reporting matches how small organizations already work. Billing is monthly. Staff meetings and board packets are monthly. A due date of the tenth business day after month end gives the provider time to finish entry and fix errors, and gives the funder one clean file per site per month.
Two exceptions belong outside the monthly cycle. Critical incidents, such as a participant safety event, a death, or a data breach, are reported within a set number of hours through a separate path, not a field on the monthly form. And if someone actually acts on a number in real time, a bed count that drives placements for example, that one number gets a live feed. Nothing else does. Quarterly, add a short narrative: what changed, what is stuck, what the provider needs. Two or three paragraphs are worth more than another twenty fields.
Forms built for the phone at the front desk
The person entering data is often standing up. A case manager between appointments, an outreach worker in a parking lot, a receptionist with a participant at the counter. Design for a phone first and the desktop version takes care of itself.
That means short sections rather than one long scroll, pick lists instead of free text, large tap targets, a date picker that defaults to today, and a draft that saves on every change so a dropped signal loses nothing. Outreach workers need offline capture that syncs later. Required free-text fields should be rare, because on a phone they get filled with a period.
Set a time budget and test against it. A reasonable target, as an illustration, is under two minutes to record a routine service contact and under ten minutes for a full enrollment. Time three staff members at three different providers entering real records. If they miss the budget, the form is wrong, not the staff.
Pre-fill everything the system already knows
Every value a provider types twice is an error waiting to happen. Enrollment captures the participant once; every service record after that carries forward the participant, the site, the staff member and the program automatically. The service date defaults to today. The service type defaults to the one this staff member records most often, and changes with one tap.
Group services need their own path. A job readiness class with fourteen participants should be one entry with a roster of check boxes, not fourteen separate forms. This single change often removes more data entry time than any other.
Providers who already run their own case management system should never be asked to retype into yours. Publish a simple file layout, accept a monthly upload of the same fields, and run the same quality checks on it as on direct entry. The provider's own system stays the record of care; yours stays the record of reporting.
Shared definitions, written down once
Two providers can report the same program honestly and produce numbers that cannot be compared. One counts everyone who called. Another counts only people who completed intake. A third counts households instead of individuals. Without a written definition, "served" means whatever the person filling in the form thinks it means that week.
Keep a data dictionary: one page per field with the definition, the allowed values, two or three worked examples and the hard cases. Put a short version of each definition behind an information icon on the form, where people actually look. Version the dictionary, date every change, and never change a definition mid-year without telling providers which months use which version.
Definitions fail at the edges, so put the edges in the dictionary
A participant attends half a session and leaves. A family of four enrolls together. Someone exits, then returns three weeks later. A phone call lasts eight minutes. Each of these happens every month at every site, and each will be recorded differently by different people unless the dictionary says what to do. Collect the questions providers ask during the first two reporting cycles and add every answer to the dictionary as a worked example. After two cycles, most of the ambiguity is gone.
Catch errors at the door, not in the reconciliation
Errors found three months later are expensive because nobody remembers the right answer. Errors found at entry cost seconds because the person who knows is holding the phone. Put the checks in the form.
Hard stops are for things that cannot be true: an exit date before the enrollment date, a service date in the future, a participant ID that does not exist. Soft warnings are for things that are unusual but possible, and they ask a question instead of refusing: twelve units for one person on one day, an outcome recorded before the measurement point, a new enrollment that looks like an existing participant with a similar name and the same birth date. The staff member confirms or corrects, and the confirmation is stored so the analyst does not chase it later.
Keep hard stops to a handful. Every unnecessary hard stop teaches staff to enter a placeholder value to get past it, and placeholder values are the worst data you can collect, because they look real.
Give providers their own data back
Reporting is sustainable when it is useful to the people doing it. Most providers send data out and never see it again, except as a compliance email when something is late. That pattern teaches them exactly how much effort the data deserves. A provider who never sees their own numbers again learns that reporting is a tax, and people pay taxes as late and as minimally as the rules allow.
Send every provider a one-page summary within a week of each monthly deadline. Their caseload, enrollments, exits and outcome rate, a twelve-month trend line, and their data quality score with the specific records that need attention. If the network agrees, show where they sit against the network median, without naming other sites. Make the page easy to paste into a board report or a grant application, because that is where a small organization will use it.
Then use the data in the monthly partner conversation. When a provider sees that their exit reasons are mostly "lost contact" and the network's are not, the conversation is about follow-up practice, not about compliance. That conversation is the return on the reporting.
Pay for the reporting time
Reporting takes staff hours, and staff hours cost money. A funder that adds reporting requirements without adding funding is moving cost onto the provider, and the provider will pay for it by cutting service time or cutting corners on the data. Usually both.
Estimate the time honestly. Multiply the expected number of records by the tested entry time from your form trials, add time for the monthly review and the quarterly narrative, and put that number in the budget as its own line. Fund training time for new staff, because turnover at community providers is high and every new hire needs to learn the form. If a provider needs a part-time data role to keep up, fund the fraction.
Pay on time, and tie payment to a timely submission rather than a perfect one. Holding an invoice until every data question is resolved punishes the provider for asking good questions and starves the organizations with the least cash on hand.
Privacy that matches the people you serve
The people served by community providers are often the people most harmed by a data leak: survivors of violence, people with records, immigrants, people in treatment, young people in foster care. Design the reporting system for them, not for the average case.
Collect less, starting with identity. A program-assigned ID and a birth year are enough for most reporting; names, full birth dates and Social Security numbers stay in the provider's own records unless a requirement says otherwise. Give each role access only to the fields it needs. Put the data use in plain language on the intake form, and explain it out loud. Sign a data sharing agreement between funder and provider that states the purpose, the fields, who can see them, how long they are kept and what happens at the end.
Public reports need small-number protection. When a count is small enough that a neighbor could identify the person, suppress it or combine categories; many public health agencies suppress any cell below a fixed threshold such as 11. Programs that serve survivors of domestic violence often operate under federal and state confidentiality provisions that limit sharing identifying information at all. Give them an aggregate-only reporting path from the start rather than an exception later.
Before the reporting package goes out
Use this list before you send a new reporting design to providers, and again at every annual review.
- Every field names its reader, the decision it informs and how often it is needed
- The minimum data set fits on one phone screen per section, with pick lists instead of free text
- Three staff at three providers entered real records inside the time budget
- Participant, site, staff and date carry forward automatically; group sessions use one roster entry
- The data dictionary covers every field, with worked examples and the hard cases
- Hard stops are limited to impossible values; unusual values get a soft warning and a stored confirmation
- Providers with their own systems can upload a monthly file instead of retyping
- Each provider receives a one-page summary of its own data within a week of the deadline
- Reporting time is a funded budget line, and payment depends on timeliness, not perfection
- No Social Security numbers, small cells suppressed, a signed data sharing agreement with every provider
If you cannot check every line, fix the unchecked ones before launch. Each one left open shows up later as late reports, inconsistent numbers or a provider that quietly stops participating.
Frequently asked questions
As few as the decisions require. For most direct-service programs, eight to twelve fields cover identity, enrollment, services, referral source, one primary outcome, exit and geography. Anything an evaluator needs beyond that belongs in a separate, time-limited collection with its own budget, not on the routine monthly form.
Only for a number someone acts on in real time, such as available beds that drive same-day placements. That number should get a live feed. Everything else works better monthly, with critical incidents reported through a separate path within a set number of hours.
Publish a data dictionary with one definition per field and worked examples of the hard cases, accept a monthly file upload in a fixed layout from providers who already have a case management system, and run the same quality checks on uploads as on direct entry. Consistency comes from shared definitions, not from forcing everyone onto one tool.
Yes. Reporting is staff time, and unfunded reporting is paid for out of service time or data quality. Estimate the hours from tested entry times and expected record counts, put them in the budget as their own line, and include training time for new staff.