Do you need AI, ordinary automation, or no new software?

Find the broken step first

An owner says, “We need AI to follow up on estimates.” Maybe. First ask where estimates are recorded, who follows up now, and how the team knows a job was won or lost.

If estimates live in a shared system and need a reminder after three days, that may be an ordinary automation. If replies arrive as messy emails and need to be interpreted, AI might help. If nobody owns follow-up and half the estimates are missing, new software is not the first fix.

These are illustrative situations. They are not claims about a particular customer’s results.

A practical decision path

Before choosing software

1. Can you describe the process and its owner?If not, agree on who does what and where the record lives first.
2. Can your existing software handle the step?If yes, test that capability before adding another subscription.
3. Can you write an exact rule?If yes, begin with ordinary automation and defined exceptions.
4. Does the step require interpreting varied language?Consider AI assistance, then test its mistakes and decide what a person must approve.

Use ordinary automation for clear rules

A rule-based workflow follows instructions such as: when an estimate reaches a defined status, create a follow-up task for its owner. It does not need to invent what should happen.

Common candidates include copying approved fields between systems, notifying someone when a form arrives, and assigning a task after a known event. Platforms such as Power Automate describe this work in terms of triggers and actions. Microsoft’s explanation.

Rules still need care. What if a record arrives twice? What if the customer already replied? What if the destination system is unavailable? A reliable automation records what happened and makes exceptions visible.

Consider AI for interpreting language

AI may help summarize a long conversation, suggest a reply, or sort varied customer messages into categories. These tasks involve language that will not always arrive in a predictable format.

The important word is “help.” A fluent answer can still miss a detail or make an unsupported assumption. Test with examples from the actual task, including confusing ones. Decide what the system is allowed to do and when it must ask a person.

For instance, AI might identify that a customer is asking to reschedule. A separate rule should still check the real calendar before offering a slot. The language model does not become the source of truth for availability simply because it can talk about appointments.

NIST’s AI Risk Management Framework provides a broader approach to managing AI risks. Our simpler recommendation here is to make the likely mistakes, their consequences, and the responsible person explicit before deployment.

Sometimes the answer is no new software

Start with a process change when the task happens rarely, the volume does not justify upkeep, or the team has not agreed on the desired outcome.

A shared checklist, a clearly assigned owner, or a feature already included in your CRM may be enough. That is not a lesser result. Removing a missed handoff is the goal; buying a new tool is optional.

Our bias is to begin with a small, measurable improvement. Do not automate five departments because one form is frustrating.

One workflow, three kinds of work

Consider an estimate follow-up process:

• A person defines the policy. Who should receive a follow-up, when, and when should contact stop?
• Rules handle the routine. Check the estimate status, schedule the appropriate task, and avoid duplicate actions.
• AI assists with messy input. Summarize a free-form reply or draft a response for review.
• A person handles the exception. Resolve an ambiguous request or approve a commitment outside the agreed limits.

This is often more useful than asking an AI to “manage sales” without defining the boundaries.

Bring these answers to a consultation

1. What event starts the process?
2. What information arrives, and where does it live?
3. Who owns the next action?
4. How often does this happen, and how much work does it create?
5. What would a successful result look like?
6. What mistakes would be expensive or difficult to undo?
7. Which decisions must stay with a person?

Write down the current baseline before testing a change. Depending on the process, useful measures might be time spent per item, missed follow-ups, correction rate, or support effort. Saving a few clicks is not a win if the team spends more time repairing errors.

You do not have to arrive knowing which software to buy. A useful consultation starts with the work and ends with a recommendation you can explain.