Map the spreadsheet-and-email handoff before choosing software or AI

Before I recommend custom software or AI for a manual workflow, I want a clear description of the work. A spreadsheet and an inbox are a useful place to start. You can inspect the information people enter, the decisions they make, and the messages they send when something is missing.

Choose one handoff rather than trying to document the entire business. Pick a request that moves from one person to another: an order needing approval, a job ready for scheduling, or a document waiting for review. The goal is a map you can discuss with the people doing the work.

Start with a recent item

Ask the people involved to walk through one completed item using records they are authorized to view. Follow what happened, including the extra email or corrected spreadsheet row. Then examine an item that needed an exception.

Keep sensitive details out of the working map. Use role names instead of customer names and describe fields without copying their contents. You need to understand the process, not create another collection of confidential records.

Give each step an owner and an exit condition

Make a table with these columns:

• Step: the action someone takes.
• Owner: the role responsible for that action.
• Input: what must be available before work starts.
• Rule: how the person decides what to do.
• Output: what they produce or change.
• Next owner: who receives the work.
• Done when: the visible condition that completes the step.
• Exception: what happens when the normal route fails.

Write actions precisely. Replace "process request" with something like "check that the request includes an account number and requested date." Treat that wording as an example, not a requirement for your business.

Pay attention to the exit condition. An email marked as sent tells you about the sender's action. It does not tell you whether the next person accepted responsibility. Decide what acknowledgement your process needs.

Trace the information, not just the screens

For every field copied between the spreadsheet and another tool, note where it originates, who may change it, and which record wins when versions disagree.

Mark fields people calculate, infer, or look up elsewhere. Ask what happens if the value is blank or arrives late. If someone corrects a request after approval, write down whether the approval still applies.

This is also where I would separate a business rule from a habit. "The manager approves this category of request" describes a rule to confirm. "We email the file because that is how we started" describes a working practice to examine.

Record waiting and rework without guessing at savings

For a small set of authorized items, record when work arrives, when someone starts it, and when it moves onward. Keep hands-on time separate from waiting time. Note missing information, duplicate entry, corrections, and follow-up messages.

Label estimates as estimates. A person's recollection can guide a question, but do not turn it into a measured baseline. Avoid treating all elapsed time as labor or multiplying an unusual delay into an annual savings claim.

Ask the team what a better process would look like in observable terms. You might want every pending request to have an owner, or a corrected record to return for review. Write those acceptance conditions before discussing features.

Compare options against the same map

First consider whether clearer ownership, a shared status field, or a change to the existing tools would address the problem. You do not need to commission software to write down a rule.

If you evaluate an existing product, ask it to demonstrate your normal handoff and your exception path. Check access, corrections, exports, and who will maintain the setup.

If you consider custom software, use the map to define the smallest useful scope. Identify which systems need to exchange information and who owns those systems. Include maintenance and support responsibilities in the discussion rather than leaving them until launch.

For an AI-assisted step, specify the proposed task and its limits. For example, you could evaluate a draft summary for a person to review. Define the evidence the reviewer needs, what counts as an unacceptable result, and where uncertain items go. Do not authorize automatic approvals or outbound messages merely because a draft looks convincing.

Bring a workflow, not a shopping list

I would rather discuss one clearly described handoff than a long list of software features. Bring the owner, inputs, decision rule, exception route, and definition of done. Include what you have observed and what you still need to check.

If you want to discuss software development or AI automation for that workflow, send me a project inquiry through the contact form. Describe the process and the tools involved without including confidential records or credentials.