Jump to a section
What problem are you buying CHW software to solve?
Name the operational problem and define the evidence that would show a system improves it.
A program replacing spreadsheets may need reliable assignments and follow-up. Another may already have those workflows but struggle to assemble funder reports. A third may need to reduce repeated entry between systems. Begin with the problem your team can describe, not the longest feature list you can find.
List the people who perform or depend on the work: a frontline worker, supervisor, intake coordinator, reporting lead, and the person responsible for purchasing and access decisions. Ask each for a real example of friction. Combine those examples into a short requirements list with a named decision owner.
Separate a requirement from a preferred interface. "A covering worker can identify the next agreed action" is a requirement. "There must be a blue button in the upper-right corner" is usually a preference. Keeping that distinction clear makes it easier to evaluate different systems fairly without losing the underlying need.
How should you score a CHW software demonstration?
Use explicit acceptance checks and record what was demonstrated, configured, promised, or left unresolved.
| Area | Test to run | Evidence to record |
|---|---|---|
| Intake and records | Create a fictional participant and handle a duplicate referral | Record ownership and duplicate handling. |
| Assignments and continuity | Reassign a case and identify outstanding work | What the replacement worker can see and do. |
| Documentation | Record an encounter and correct an error | Required fields, review roles, and retained history. |
| Follow-up | Track an agreed next action and an unknown referral result | Statuses, ownership, and reminders actually shown. |
| Reporting | Reconcile one total with the example records | Definitions, exclusions, export fields, and limitations. |
| Access | Use accounts with different responsibilities | Visible records and restricted actions. |
| Implementation | Map your current forms and source data | Responsibilities, timeline, costs, and unresolved scope. |
Suggested scoring: 0 means not demonstrated, 1 means a workaround was shown, 2 means it works with agreed configuration, and 3 means the required workflow was demonstrated directly. Keep critical requirements as separate pass or unresolved decisions. A high total must not hide a missing essential workflow.
What should happen during a useful product demo?
Ask the presenter to follow one fictional participant across the same sequence your staff will use.
Start with a new referral and a participant who prefers a specific contact method. Assign the work, record a completed encounter, and create a follow-up commitment. Then introduce an exception: the assigned worker is away, a detail needs correction, or the referral result remains unknown. Ask another role to continue the work.
End by reporting the example activity. Ask what counts as a participant, an encounter, and a task. Inspect an export rather than relying only on a chart. If a requested step needs configuration or a separate service, record who would perform that work and how it affects cost and timing.
Use fictional information throughout evaluation. Real participant records are not needed to understand whether a basic workflow fits. If a later migration assessment requires sensitive information, arrange the appropriate access, agreements, and secure transfer process through your organization.
What should you test for community and field work?
Test the actual devices, connectivity conditions, and work settings your staff use instead of assuming all web or mobile experiences are equivalent.
Have a worker complete the sample encounter on a phone and a laptop. Check readability, required fields, keyboard access, and the effort needed to find the next action. If your team needs language-specific forms or accessible materials, include those requirements in the demonstration rather than treating them as an implementation detail.
Ask directly what happens when a connection drops, a session expires, or a form is interrupted. Do not infer offline support from the existence of a mobile layout. Have the vendor explain saved drafts, recovery behavior, and any restrictions. Record which behaviors were demonstrated and which remain unverified.
Also test a busy day. Can staff distinguish appointments from completed encounters? Can they identify overdue commitments without opening every record? A system can look simple in an empty demonstration account and still require too much work once a real caseload is present.
How do you compare software costs without misleading totals?
Request a written first-year and renewal estimate using the same team size, service scope, and implementation assumptions.
| Cost category | Question to ask |
|---|---|
| Subscription | Which staff, programs, locations, and modules are included? |
| Setup and migration | What data is imported, who cleans it, and how are exceptions handled? |
| Training and support | How much onboarding is included and what support is available afterward? |
| Integrations and usage | Are interfaces, messaging, storage, or usage charged separately? |
| Configuration changes | Who updates forms or reports, and what work requires an additional fee? |
| Exit and export | What can be exported, in which format, and at what cost? |
For illustration only, a fictional quote of $400 per month plus $2,000 setup totals $6,800 for the first year before other charges. Another fictional quote of $550 per month with no setup totals $6,600. The lower monthly price is not automatically the lower first-year cost. These are arithmetic examples, not Smores pricing or market estimates.
Ask how future changes affect the estimate. Adding a new program, switching a reporting format, or importing another year of data may alter the work required. Compare commitments in the proposal and agreement rather than relying on an informal expectation from a sales conversation.
Which access and data questions belong in the decision?
Verify who can access which records, what evidence supports security claims, and how your organization can retrieve its information.
Ask for the security materials appropriate to your organization's review. Have the vendor demonstrate the roles you expect to use and explain how access is granted, changed, and removed. A compliance label on a website does not tell you whether a particular configuration meets your program's requirements.
Test an export with fictional records. Check whether it includes the fields and relationships needed to understand the service history. Ask about documents, corrections, attachments, and supporting metadata. Agree on responsibilities for retention and transition before signing a contract, rather than discovering them when the program wants to change systems.
For interfaces with a health system, payer, or partner organization, name the exact system and data flow. "Integrates with healthcare" is too broad to establish that your interface exists. Confirm dependencies, fees, testing, ownership, and what happens when the connection fails.
How do you separate essential CHW software requirements from preferences?
Identify the workflows that must work at launch, the improvements that can wait, and the evidence needed for each decision.
Create three columns: essential at launch, useful after launch, and optional. An essential item should name a concrete consequence if it is missing. For example, the team cannot use its approved note review process, or the required report cannot be produced from the records. A preference might concern the order of dashboard cards. Without this distinction, an attractive feature can distract from a workflow the program genuinely needs.
For every essential item, write an acceptance scenario and name who will assess it. If the requirement is supervisor review, show a worker creating a fictional note, the supervisor reviewing it, a correction being requested, and the authorized next action. If the requirement is a monthly report, bring a small synthetic dataset with expected totals. A feature name on a checklist is weaker evidence than a demonstrated result using your scenario.
Ask whether the demonstrated behavior is included in the proposed plan, needs configuration, depends on another vendor, or is only proposed for the future. Record the answer in the evaluation and contract discussion. Do not count a roadmap promise as a current capability. Apply this standard to Smores Health as well as any other product. A clear fit decision should identify both demonstrated strengths and unresolved dependencies.
How can you compare CHW software proposals on the same basis?
Compare total first-year and ongoing costs using identical assumptions about users, services, implementation, and support.
Consider two fictional proposals. Proposal A costs $600 per month plus $2,400 for implementation, producing a first-year total of $9,600 before any additional costs. Proposal B costs $850 per month with no implementation charge, producing $10,200. The difference is $600 in year one. In a later full year with the same monthly prices and no repeated setup fee, the base totals would be $7,200 and $10,200. These are arithmetic examples, not Smores Health prices or market benchmarks.
The comparison is incomplete until you check what each proposal includes. Ask about staff seats, participant limits, additional programs, training, data migration, integrations, message charges, reporting support, and any other usage-based fees relevant to your workflow. Some categories may not apply. Record the actual terms rather than assuming either that every item costs extra or that everything is included.
Add the organization's own transition effort. Staff may need time to prepare data, validate records, attend training, and change procedures. Do not invent a productivity saving to offset those costs. During a pilot, measure a representative task and compare it with the current process, including review and corrections. A faster first entry that creates more work later is not necessarily an improvement.
What should you verify about implementation, migration, and leaving the system?
Agree on ownership, acceptance checks, support, and usable exports before relying on a new platform.
Inventory the records you intend to move and identify which system is authoritative for each. Decide who will prepare data, resolve duplicates, validate attachments, and approve the result. Do not assume matching names proves two records belong to the same person. Use the organization's approved identity process and keep uncertain matches for review. Start with a small representative sample rather than importing everything and discovering the mapping problem afterward.
Define implementation acceptance in terms staff can demonstrate. A worker can find the right participant, record an encounter, and see the next task. A supervisor can perform the agreed review. A reporting lead can reproduce the expected sample totals. Confirm role restrictions with authorized test accounts. The acceptance list should reflect the purchased scope and the service you actually intend to operate.
Ask how you can export records and attachments in a usable form, what metadata accompanies them, and what support or fees apply at the end of the relationship. Confirm applicable retention and deletion arrangements with the responsible advisers and the written agreement. An export button alone does not prove you can reconstruct the information your program needs. Request a sample and have the intended recipient review it.
Plan a named point of contact for the first weeks after launch. Record who handles product questions, configuration issues, urgent access problems, and policy decisions. Software support can explain the product, but it should not be expected to decide an unresolved payer requirement. A realistic implementation plan makes those responsibilities clear and gives staff a route to resolve problems without inventing their own workaround.
How do you record whether a software requirement is actually met?
Use an evidence status that separates demonstrated behavior from assumptions and future promises.
| Status | What it means | Next decision |
|---|---|---|
| Demonstrated | Your acceptance scenario worked in the shown configuration | Confirm it is included in the proposal |
| Configuration required | The outcome depends on defined setup work | Agree on owner, cost, and acceptance test |
| External dependency | Another service or interface is needed | Verify availability and responsibility |
| Described only | A claim was made but the scenario was not shown | Request a demonstration or suitable evidence |
| Unavailable | The required workflow cannot currently be supplied | Reject, change scope, or accept an explicit limitation |
Record the requirement, evaluator, date, and evidence reference beside the status. For a monthly report, retain the synthetic inputs and expected total used in the demonstration. For access, record which test role performed which action. A screenshot of a chart does not prove that the underlying definition matches your requirement.
Use the same register for Smores Health and every other vendor. Do not turn a roadmap statement into a launch assumption. An essential requirement remains unresolved until the evidence supports the specific workflow you intend to buy.
How should you structure a CHW software demo?
Use one fictional participant journey and spend the time on the workflows that matter most to your decision.
Send the vendor a short, non-sensitive brief before the meeting: your organization type, service model, approximate operating scale, the three most important workflow problems, and blank examples of the forms or reports you want to discuss. Do not send live participant records to make the demonstration realistic. A fictional scenario can reveal the workflow while avoiding unnecessary disclosure.
For an initial 20-minute conversation, a suggested agenda is three minutes on the program and priorities, ten minutes on one connected workflow, five minutes on questions and limits, and two minutes on next steps. That is a planning suggestion, not a promise that a complete evaluation fits into twenty minutes. Use a later technical or operational session for complex access, migration, integration, or contractual questions.
After the meeting, have attendees record their findings independently before discussing a group score. A frontline worker may notice repeated entry that a purchasing lead missed; a reporting lead may identify a missing definition. Resolve differences by returning to the scenario and evidence. Do not let a polished presentation replace the acceptance checks you agreed on beforehand.
What could a realistic CHW software implementation schedule include?
Plan around prerequisites and acceptance checks, with dates confirmed by the organization and vendor.
The following four-stage sequence is an original planning example, not a vendor delivery commitment. Stage one establishes scope: name the program owner, confirm purchased services, inventory existing records, and agree on essential workflows. Decide which open policy questions must be resolved before configuration. A signed contract does not automatically settle how your organization wants every form or report to behave.
Stage two prepares configuration and sample data. Map fields, roles, and reporting definitions. Test a small synthetic or otherwise approved sample through the intended import and workflow. Record mismatches and assign owners. Do not move to a full migration because a sample file uploaded successfully; confirm that the records, relationships, and outputs mean what the team expects.
Stage three trains the people who will do the work and rehearses exceptions. Include an unfinished note, a worker absence, a duplicate candidate requiring review, and a participant moving between services. Ask users to complete tasks themselves. Watching a demonstration is different from independently completing the process. Identify where training, configuration, or policy changes are still needed.
Stage four makes a bounded launch decision. Confirm support contacts, unresolved limits, data validation, and the team's ability to complete essential tasks. Agree on how problems will be triaged and when the initial review will occur. Set calendar dates only after the dependencies and available staff time are understood. A smaller successful launch may be more useful than a broad rollout with unclear ownership.
How do you make the final CHW software decision?
Choose based on essential workflow evidence, total cost, implementation feasibility, and the conditions recorded in the agreement.
Summarize the decision in one page: what problem is being solved, which essential scenarios passed, which limitations remain, the agreed costs, the implementation responsibilities, and who approved the selection. A high average score should not cancel out failure of an essential requirement. If an unresolved dependency could prevent launch, identify the condition that must be met before relying on it.
Include the people who will own the system after purchase. They need to understand the configuration assumptions and workarounds, not just the sales summary. Confirm that important promises are reflected in the appropriate written scope or agreement. This article is a purchasing framework, not a review of any vendor's contract or a statement of legal terms.
For a Smores Health walkthrough, bring your blank note template, one reporting question, and a fictional participant scenario. Use the same evidence-based evaluation described here to decide whether the demonstrated workflow fits your program and what needs further discussion.
What should your implementation plan include?
Use a bounded pilot, named owners, and acceptance checks before expanding the new system across the program.
Smores Health publishes this guide and offers community health workflow demonstrations. Its participant, coordination, documentation, and reporting features should be evaluated against your own requirements. This guide is a buyer worksheet, not a competitor ranking or a promise that every requested CHW feature is included.[2][3]
Frequently asked questions
Should we choose the product with the most features?
Choose the product that demonstrates your essential workflows and fits your implementation capacity. Unused features should not outweigh usability, continuity, and clear responsibilities.
Does this guide rank competing vendors?
No. Smores Health publishes this evaluation framework. Use the same scenarios and evidence standards with every vendor you consider.
Do we need a separate CHW system?
Map the gaps in your current system first. A configuration change may solve the problem; a new system is justified when it better meets your defined requirements and transition costs.
Can we assume billing and integrations are included?
No. Confirm the exact payer, interface, workflow, availability, and pricing. A product demonstration of documentation does not establish claim submission or payer acceptance.
Sources and product pages
Sources support the specific guidance cited above. Program guidance is not a universal requirement. Product pages describe capabilities to verify against your organization’s needs.
- Resources for Community Health Workers: Centers for Disease Control and Prevention. Role and resource overview, published December 3, 2024. Checked October 9, 2026. Operational worksheets in this guide are original Smores Health examples, not CDC forms.
- Smores Health: Operate: Smores Health. Product overview. Confirm your program configuration, included services, and rollout scope in a walkthrough and written agreement.
- Smores Health: Document: Smores Health. Product overview. Confirm your program configuration, included services, and rollout scope in a walkthrough and written agreement.