When a model helps, and when it should wait

Teams often ask for AI because the work feels heavy. Invoices pile up. Return reasons are typed by hand. Demand plans live in three sheets. A demo chatbot looks like relief. It rarely is, if the queue behind it is still a shared inbox.

We use a model when it saves time on a job you can count: reading a document into a table, sorting tickets into buckets, or producing a forecast someone can override. We skip a chatbot until the process has owners, aging, and a place for exceptions.

Three jobs where a model is usually worth it

Documents. Invoices, claim packets, contracts, and credit files still arrive as PDFs and scans. A person should not retype every field. Pull the fields into a table, then have someone check the rows that are low confidence or high value.

Sorting. Returns, guest comments, and support tickets often follow a short list of reasons. A model can put each item in a bucket. A person still handles the odd case and the angry case.

Forecasts. Demand, occupancy, and cash can use history if the history is honest. Promotions, stockouts, and one-off events should be flags, not stories in chat. The meeting still happens. The model does not replace the meeting.

What should stay with a person

Anything that posts to the books, changes a medical record, issues a refund above a limit, or sends a guest-facing message without review. Write that down in the design. If it is only implied, it will be skipped under pressure.

How to tell if it is still earning its keep

Measure hours saved on the old manual step, error rate on the extracted fields, and how often a person overrides the forecast or the bucket. If nobody overrides and the error rate is unknown, you do not have a production tool yet. You have a demo.

We do not claim HIPAA or SOC 2 unless the contract says so. Access stays limited to what the project needs. A person still reviews the step that matters.