Before you automate, check the process

Show the task, not the technology

“We need AI” does not tell a supplier what to fix. “We copy these figures into this report every Friday, then spend an hour checking them” does. Start with the work and the person doing it.

Walk through one recent example. Show where the information comes from, what gets changed and who uses the result. Include the awkward cases: a missing field, a changed request or a colleague being away. A tidy diagram can hide the part that makes the real task difficult.

Write down the starting point. How often does the task happen? How long does it take, including checks and corrections? What is the consequence when it goes wrong? These are observations to collect in your business, not figures a supplier should invent.

Find the cause before speeding it up

A repeated step may be unnecessary. A report might collect figures nobody uses. Two people may enter the same information because nobody agreed which record is current. Automating those steps keeps the confusion and makes it happen faster.

Ask what each step is for. Remove the ones that no longer have a job. Then agree who owns the record, which information is required and what the next person needs. A checklist or saved view may be enough.

For a lost enquiry, begin with ownership. Who receives it? Who is meant to reply? Where can the team see that action? Our working enquiry demonstration lets you inspect those choices with sample data. It is a fictional example, not a client result.

Check the software you already pay for

Before adding another subscription, inspect your current account. Look for saved views, exports, forms, reminders and supported integrations. A feature can exist but require a different plan or permission, so check the actual account rather than a marketing page.

If information must move between tools, ask which system owns it. Confirm the fields, direction and supported access. A connection that copies every change both ways can create conflicting records unless the rules are clear.

Tool fit is a real business problem. The Federal Reserve’s 2026 small-business survey identifies adapting AI tools to business needs and accuracy among the difficulties reported by AI users. That supports checking the task and the fit, rather than assuming a tool will be useful because it is available. The survey is a convenience sample; it does not establish a result for your company. Read the survey findings and methodology.

Choose the first useful change

A known rule and structured data often need ordinary automation. A task that involves messy notes may benefit from a draft a person checks. A missing view might justify an internal tool. The same symptom can have different causes, so the implementation should follow the review.

Ask for one use case people can try. Name the users, inputs, output and actions included. State what stays manual. A useful first version should address the original problem without requiring the entire business to change tools.

For AI-assisted work, include the review time in the test. A summary that takes longer to correct than to write has not earned its place. Decide what information may go to the provider and keep the ordinary process available.

Test what happens when it fails

A successful run is only one test. Try a repeated event, missing information, revoked access and an unavailable connection. Check the receiving system too. A green status does not prove the right person received a useful record.

• Who sees a failure?
• Can they identify the affected request?
• Can they retry without creating a duplicate?
• Can they stop the process or complete the task manually?
• Can a customer message be held for review when the information is uncertain?

Agree these behaviours before launch. Keep access limited to the people and information the task needs. Name who maintains the connection when a provider changes its API or a supported page changes.

Count the upkeep as well as the build

The purchase price is not the whole cost. Add subscriptions, usage, hosting, review time and maintenance. Ask which accounts you control and what is handed over. A new tool should have someone responsible for its operation.

Compare that ongoing cost with the observed problem. Useful evidence might be time spent per report, corrections, steps per lookup or unassigned requests. Keep the same definition before and after the change. A form submission is not a booked job; a generated draft is not an approved report.

Do not treat a short test as a permanent result. Use the first agreed review point to check normal cases and exceptions with the people doing the work. Expand when the first change is useful, rather than because more features are possible.

Give a supplier a useful starting brief

Send one short description: what happens now, what gets in the way, which tools you use and what would count as better. You do not need to choose an API, an AI model or a development framework.

A supplier should be able to explain the proposed change in the language of the task. Ask for the scope, cost, acceptance checks and upkeep in writing. If access or technical fit needs paid investigation first, agree that work separately.

CallCraft Studio starts with this kind of problem. Explore workflow automation, integrations or internal tools, or simply show us what is stuck.