San Francisco Campus for Jewish Living

Michael Forsyth

Healthcare Technology Steward

An AI tool can be affordable to purchase and expensive to operate.

The difference is often found in work that never appears on the vendor’s quote, including preparing information, connecting systems, training employees, reviewing results, correcting errors, and supporting the workflow after launch.

For an aging services organization with limited staffing, those responsibilities matter as much as the subscription price. A project can fit the software budget while exceeding the organization’s ability to implement and maintain it.

That is a central concern in my guide, AI in Aging Services: Are You Ready and What Will It Really Cost? I wanted to give leaders a practical way to evaluate the full commitment behind a proposed purchase and determine whether the expected benefit justifies it.

Define the Improvement Before Calculating the Return

A useful business case starts with a specific operational need.

“Improve efficiency” is too broad to guide an investment. Reducing referral review time, completing documentation within a shift, or eliminating repeated data entry provides the organization something it can evaluate.

Leaders should understand the current process before assigning value to a proposed improvement. Where does the work slowdown? How much time involves judgment? How much involves finding information? Which delays would remain even if the software performed exactly as promised?

This examination also creates a fair comparison with existing tools and process changes.

Purchasing AI should follow from the evaluation. It should not be the assumption that determines the answer.

Measure the Finished Task

The speed of producing an output can be misleading.

Consider a hypothetical task that currently takes 20 minutes. An AI tool generates an initial result in two minutes, but an employee needs another eight minutes to review and correct it.

The potential saving is 10 minutes, assuming the completed work meets the required standard. Reporting an 18-minute saving would ignore work that remains necessary.

That distinction becomes more important when a tool encounters incomplete information or unusual cases. A process that performs well on straightforward tasks may require substantial intervention somewhere else.

“Purchasing AI should follow from the evaluation. It should not be the assumption that determines the answer.”

A pilot should therefore measure the complete workflow across multiple situations. Include review, corrections, exceptions, and any work transferred to another department.

The organization needs to know what it takes to finish the job reliably.

Separate Financial Savings from Staff Capacity

Recovered time has value. Its financial meaning needs to be stated accurately.

If an employee spends less time assembling information and more time responding to families, the organization has gained service capacity. If the change reduces paid overtime, it may also produce a measurable expense reduction.

Those are different outcomes.

Multiplying hours saved by an hourly labour rate can help estimate the value of capacity. It does not establish that the operating budget will decrease.

This distinction should strengthen the business case. Better responsiveness reduces administrative burden, and more time for residents may justify an investment on its own merits.

Leadership should decide how recovered capacity will be used and measure whether that benefit occurs. Otherwise, the proposal risks promising savings that no one is responsible for realizing.

Make Internal Work Visible

Existing employees are often treated as a resource with no additional cost.

Their salaries may already be budgeted but assigning them to an implementation may change what they can accomplish elsewhere. Training, testing, configuration, and support compete with other organizational priorities.

A credible estimate should distinguish additional spending from existing staff time committed to the project.

It should also separate initial implementation from recurring responsibilities. New employees will need training. Integrations will need attention. Product changes may require review. Users will need help after the initial enthusiasm has passed.

Finance, operations, IT and the department using the tool should build this estimate together. Each sees costs and dependencies that the others may miss.

Test the Assumptions before Expanding

A business case contains assumptions about adoption, performance, integration, and support. Leadership should be able to see which assumptions could change the decision.

What happens if review takes longer than expected? What if the integration is delayed? What if employees must continue using both systems? What if the existing contract cannot end when planned?

A controlled pilot can help answer these questions before a larger commitment.

Set its scope, budget, baseline, and success criteria in advance. Assign someone to collect results and someone with authority to act on them. Include conditions for stopping as well as expanding.

Plan for exit, too. The organization should understand how it would retrieve records, remove access, and continue the work if the product becomes unsuitable.

My recommendation is to ask for a complete operating case with every significant AI proposal, covering the need, the expected improvement, the resources required and the evidence that will justify continuation.

An attractive price and a convincing demonstration can begin an evaluation. A sustainable investment requires evidence that the organization can support the tool and use it to deliver a worthwhile result.