When the system gets a case wrong, the consequence depends on who catches it and what has already happened.
That is the whole issue. Vendors like to talk about how often the system is right. You live with the ones it gets wrong. The right question is simple. Who sees the error. When do they see it. What has already left your building by then.
If fixed rules can do the job reliably, compare ordinary automation with AI before choosing the approach. Use the full cost of implementation, review and maintenance. Test it at your own desk. If the work needs judgement about messy records or tired people at the end of a shift, software may help. If the work is fixed rules on clean forms, keep the rulebook.
Why the share of right answers misleads
Every system gets some wrong. The sales figure counts how many. It says nothing about which ones. It says nothing about where they go. It says nothing about what they trigger.
A wrong draft that stays inside your office is a nuisance. A wrong payment or a wrong letter to a tenant is a problem. The difference is not how often errors happen. The difference is how far they travel before someone spots them.
Your operation already knows this pattern. The dispatcher catches a bad address before the truck rolls. The leasing manager catches a wrong lease rider before it is signed. The front desk at nine in the evening catches a guest name spelled wrong before the key is cut. Each catch works because a person sees the work before the outside world does. Ask where that catch sits when software does the work.
Who sees it, when, and what already happened
Walk through one wrong case from start to end. Pick work you run now. Take the goods receipt in your warehouse. Take the transporter's evening spreadsheet. Take renewal letters for your tenants. Follow one error through your day.
Ask these things about that error. Who sees it first. Do they see it on a screen in your office, or does the customer call you about it. When do they see it. Is it the next morning, or at month end. What has already happened. Has money moved. Has a truck left.
The answers change the risk completely. An error caught by your own lead before anything is sent is cheap. The fix is a few keystrokes and a short note. An error found by the other side after action is dear. The fix is apology, rework, and credit.
Listen for where the system acts on its own. Does it draft for review, or does it send, file, post, or pay. Draft for review keeps a person between the error and the world. Send or file or pay removes that person. That removal is where cost hides. Make the vendor show you that line in plain words.
Also ask about volume on a bad day. Systems fail in groups. A changed form or a late file can break many cases at once. Ask who works that queue. Ask what waits while they do.
Questions to ask in the meeting
Bring this list to the vendor meeting. You need no engineer in the room. Ask for plain answers. Write down what they say.
- Show me the moment a person sees each result before it leaves us. Good sounds like this. Every letter, payment, or booking sits in a review list. A named role clears it. Nothing goes out alone. Bad is hiding this. Talk of trust, maturity, or confidence. If they cannot name the screen and the role, no check exists.
- What can the system do on its own, and what must wait for us. Good sounds like this. A short list of actions it may take alone, such as sorting mail or drafting replies. Sending, paying, filing, and promising dates all wait for a person. Bad is hiding this. A long answer about settings and roles. If everything is possible with the right setup, everything will happen.
- When it is unsure, where does the case go and who works it. Good sounds like this. Unsure cases go to one queue. Your lead owns that queue. The queue has a clear name and a daily routine. Bad is hiding this. Talk of automatic improvement over time. That means unsure work lands back on your busiest people with no plan.
- Show me what the reviewer sees to catch a mistake. Good sounds like this. The screen shows the source paper next to the draft. The reviewer can open the goods receipt or the lease rider with one click. Bad is hiding this. A clean draft with no source attached. Your reviewer is asked to approve work with no way to check it.
- After it acts, how do we undo it. Good sounds like this. A named way to pull back a letter or stop a payment. Steps are written down. Someone owns each step. Bad is hiding this. Talk of logs and history. A record that it happened is not a way to undo it.
- What happens on a bad morning when many fail at once. Good sounds like this. The system stops and holds the batch. Your team gets one alert. One person can pause all sending. Bad is hiding this. Each case fails quietly on its own. Your front desk learns about it from angry calls.
Take these answers back to the person who runs the shift. Ask if the plan fits a real week.
What this does not solve
This list does not make the system right. It only keeps the wrong ones inside your walls. You will still get errors. You will still need people to check work. This will demand time from your best staff, not your newest hires. Review needs judgement. Judgement sits with people who know the work.
It will demand clear ownership. Someone must own the review queue every day, including holidays. Someone must own the pause switch. Someone must own the fix when a wrong letter goes out. If no name sits next to each job, the jobs will not happen.
It will demand patience at the start. Early weeks bring more checks, not fewer. Your team will learn what the system mangles. The transporter's evening spreadsheet will break it. A faint scan will break it. Plan for that learning.
It does not solve messy source records. If your goods receipt names do not match your order names, the system will guess. If your lease rider versions live in several places, the system will pick one. Clean the sources you can. Name the ones you cannot.
A test you can run this week
Pick one past week you already understand. Pull the full set of cases, including the hard ones. Include the coffee-stained delivery note. Include the tenant letter with handwriting in the margin.
Ask the vendor to run that week side by side with your team. Your team works as normal. The system drafts but sends nothing. Compare results case by case.
Sit with your lead and read the misses aloud. Would the reviewer have caught them with the screen shown. How long did each check take. That evening tells you more than any sales figure.
Keep the pause switch in your hands during any live trial. Start with draft only. Allow no sending, paying, or filing alone. That slow start feels dull. It saves you from the kind of error your customer finds first.