Someone asks you to turn a spreadsheet into an app. You open the file, look through the tabs, and start making a list of tables and screens. There are some formulas to untangle, a few dropdowns, maybe an approval column. It looks manageable.
Then you sit with the person who uses it.
Before they mark a row approved, they check an email. The quantity comes from another system, but they don't always trust it. One customer needs a supervisor's sign-off. When something is urgent, the team handles it in chat and updates the sheet afterward.
You can reproduce every column and still leave those people doing most of the same work. The replacement needs to account for how a request gets from arrival to completion, including the parts that never made it into the file.
That's where I'd start scoping the build.
Follow one request all the way through
Take a recent request and ask someone to walk you through it using the actual records. Keep the spreadsheet open, along with whatever else they need to explain what happened. If they switch to email, another system, or a conversation with a colleague, follow that too.
Say the sheet tracks requests that need warehouse approval. The procedure might be to enter a request, review it, and mark it complete. During the walkthrough, you might discover that review means checking yesterday's inventory export, asking the warehouse about a discrepancy, and waiting for an account manager to approve a substitution. The final status doesn't tell you any of that.
It matters to the implementation. You need to know which system supplies the quantity, when that value was last updated, who can accept a substitution, and what the request should show while those decisions are pending.
Those surrounding activities form a shadow workflow: the checks, approvals, side conversations, and judgment calls that keep the documented process working. Some deserve a place in the new software. Others may disappear once the systems can exchange data. You have to understand why a step exists before deciding.
A useful question during that walkthrough is: “Which part of this file are you nervous about changing?” A copied formula or oddly named tab may have a dependency nobody has written down. Leave it in place long enough to find out.
Work out what the statuses actually mean
A yellow row is easy to replace with a status field. Figuring out what yellow means takes more work.
It might mean someone should review the request. It might mean the review happened and there's a problem. Two people can use the same color differently without noticing until you ask them to describe the next action.
Write down the states in ordinary language: new, waiting for review, blocked, approved, complete. For each transition, identify who can make it, what information they need, and what has to happen afterward. If approval starts work in another system, that update belongs in the specification too.
Include the people who never touch the sheet. The customer-service rep who submits the request and the finance person who reconciles the export can both depend on behavior that's invisible from the main user's screen. Ask what they receive, when they need it, and what they do when it is missing or wrong.
At this point, your notes should cover the file and its data sources, the people involved, the states and decisions, the exceptions, the side conversations, and the downstream outputs. Those are the seven parts of the workflow map. They don't need seven separate meetings; they need enough detail that you can explain how the work moves without asking someone to fill in the gaps from memory.
Ask about the last time it went wrong
A normal request won't tell you how the team handles a duplicate, a stale quantity, or an unavailable system. Ask for a few recent failures and follow those through as carefully as the successful example.
Who noticed? What stopped? Who was allowed to resolve it? Look for the record of the decision and how the request got moving again. Sometimes that record will be a message rather than a field in the spreadsheet.
For the warehouse example, a quantity mismatch should give you several concrete requirements. The request needs a visible blocked state and an owner. Someone needs to know what quantity was checked and where it came from. The person resolving the discrepancy needs the right permission, and the resolution needs to remain visible after the request moves on.
That gives you an acceptance scenario you can run with the team:
- Submit a request with a quantity discrepancy.
- Confirm it stays blocked while a named person investigates.
- Have an authorized person record the resolution.
- Check that the request moves to the correct next state and that downstream records reflect the decision.
Decide what should happen if that downstream update fails as well. A screen saying “complete” is misleading if the next team is still waiting for the information. The failure needs to be visible and there needs to be an agreed way to recover.
You don't have to turn every conversation into a form. A supervisor may still need to discuss an unusual case with an operator. Capturing the decision and who made it may be enough. The aim is to let someone picking up the work later understand where it stands.
Choose what to automate after you understand it
Once you have that map, you can make fairly specific decisions about the build.
Repeatedly typing the same value into two systems is a candidate for an integration. A report nobody uses might be removed. An approval that protects the business from an expensive mistake may need to stay, with a clearer record and less chasing around it. Where a rule is still disputed or changing, defer automating it until someone can explain what the correct behavior should be.
AI fits into this at the points where the input needs interpretation. It might extract details from a messy email, classify an incoming request, or draft a response for review. Stable validation rules and known routing conditions can stay in ordinary code. Decisions with expensive or difficult-to-reverse consequences should have a human checkpoint.
For example, extracting a requested quantity from an email doesn't establish that the stock exists or that the customer has permission to order it. Those checks still need a defined source and an owner. Giving an agent access to the spreadsheet won't supply the missing business rules.
Keep that distinction clear in the design. Specify what the AI produces, which checks follow, and where a person has to decide before anything consequential happens.
Build a first version the team can finish a job in
Choose one request type or approval process and support it from intake through the final system update. It should be possible to see who owns the work, what state it's in, and what needs to happen next. Include the common exceptions you found during discovery so the first awkward request doesn't send everyone straight back to the old sheet.
Try it with the people who do the work. If they keep reopening the spreadsheet, ask what they went back to find. It may be a missing piece of history, a check the new system doesn't support, or a decision that hasn't been represented properly. That is useful feedback before you extend the tool to another workflow.
There are also cases where the file should stay. A spreadsheet used by one knowledgeable person for a changing, low-risk process may only need clearer ownership or validation. Custom software has to justify the extra maintenance and the flexibility it takes away.
Before the next planning session, ask someone to show you one completed request and one that got stuck. Follow both past the edge of the spreadsheet. You'll have a much better idea of what the first version needs to do.
Adapted from Your spreadsheet isn't the problem. The invisible workflow around it is. by Stephen Talley at Stride Techworks.
Top comments (0)