Approval workflow: turning email chains into clear states

Why email approvals stop working

Email works when a team is tiny and the decision is simple. One founder sends a note, one manager replies "approved," and everyone still remembers what happened two days later. That falls apart once more people join and a single request touches product, finance, operations, or legal.

The first problem is thread drift. One person replies to last week's message. Someone else starts a new email with a different subject line. A third person answers in chat because it feels faster. Now the same request lives in three places. People stop talking about the work and start arguing about which message counts.

Ownership breaks next. In a good approval process, one person owns the current step and everyone can see who acts next. In email, that usually turns into guesswork. A manager thinks finance will review it. Finance assumes the team lead already signed off. The requester waits, then follows up with five people. More messages do not create clarity. They hide the missing owner.

Inboxes also bury decisions. Even when someone approves a request, that approval sits next to newsletters, customer replies, and calendar notices. A quick "looks fine" in chat makes it worse, because nobody knows whether that comment was a real sign-off or just an opinion. Two weeks later, the team cannot tell whether the work stalled, shipped, or quietly died.

Growing companies hit the same pattern again and again. The team starts with common sense and goodwill. Then volume rises. Ten requests become fifty. People invent side rules just to keep work moving. If Sarah adds a thumbs-up in Slack, treat it as approved. If nobody objects by Friday, go ahead. Send urgent items to my personal email.

Those workarounds feel practical for a week. After that, each one creates a private version of the workflow. New hires cannot learn the process because there is no single process to learn. Managers cannot spot bottlenecks because the delays hide inside inboxes.

The cost is not only delay. Teams make duplicate purchases, ship without the right review, or hold work that someone already approved. Trust drops fast when people cannot answer a basic question: where does this request stand right now?

Email is still useful for discussion. It is bad at showing state. Once a company depends on approvals every day, the process needs one place where each request has a current status, a clear owner, and a visible next step.

What clear states look like

A clean approval flow gives every request one label at any moment. Not two labels, not a note in Slack plus a different note in email. One current state tells everyone the same thing, so people stop asking, "Where is this now?"

The names should be plain enough that a new teammate understands them on day one. Skip labels like "In validation" or "Under consideration" if people read them differently. Short names work better because they leave less room for debate.

Most teams need only a small set of states:

• Draft
• Ready for review
• Waiting for approval
• Approved
• Rejected

Those names are boring, and that helps. Boring names make a better approval process because nobody wastes time decoding them.

Each state also needs a person, or at least a role, that can move it forward. If a request sits in "Waiting for approval," the team should know who acts next. That might be a manager for budget, finance for payment, or legal for contract terms. When nobody owns the next step, the request just sits there.

One request should never live in several places at once. A purchase request cannot be both "waiting for finance" and "approved" because someone replied "looks good" in an email thread. The system record wins. Comments can add context, but the current state must stay singular.

Urgent work needs one written exception rule, not a second hidden process. A simple rule works well: only a team lead can mark a request urgent, and urgent means the reviewer answers within a fixed time, such as two hours. It should not mean "skip approval." It should mean "same path, faster response."

Teams feel the difference quickly. When sales asks for a rush vendor approval, everyone can see whether the request is still in review, who has it, and what happens next. That cuts the usual back-and-forth.

Before tools, dashboards, or automation, the team needs states it can trust. Once the words are clear, software can enforce them.

Name the states before you pick a tool

A good approval workflow starts on paper, not in software. If you skip that step, the tool just gives your old email habits a nicer screen.

Keep the first version small. Most teams can start with five states: "Draft," "Review," "Approved," "Rejected," and "Done." That is enough to show where work sits, who owns it, and what happens next.

Each state needs a plain meaning. Draft means the requester is still editing and can change it freely. Review means the request is ready for someone else to check. Approved means the reviewer said yes, so the team can act on it. Rejected means the reviewer said no, and the request stops unless someone rewrites it. Done means the approved work is finished and nobody needs to touch it again.

It sounds simple because it is. Simple beats clever here. If people need a diagram to tell the difference between "pending validation," "under assessment," and "ready for execution," they will go back to email by Friday.

Only add states that people use every week. A state that exists for one rare edge case usually creates more confusion than it solves. If finance asks for "waiting for budget" twice a year, keep that note in the request details instead of turning it into a permanent state.

Write one line for each state and keep those lines visible wherever the team works. That step matters more than the software choice. If the names are fuzzy, every tool feels messy.

Backward moves need as much care as forward ones. Decide who can send work back for changes. In many teams, the requester can move a draft to review, a manager can approve or reject it, and the reviewer can send it back to draft with a short reason. Do not let everyone bounce requests around. That creates blame, delay, and endless "I thought you had it" messages.

A small example makes the point. A marketing manager asks for a new vendor contract. She creates it in "Draft," moves it to "Review" when the price and terms are filled in, legal either sends it back with comments or marks it "Approved," and procurement marks it "Done" after the contract goes out. No guessing. No hunting through inbox threads.

If your team cannot agree on five state names, do not buy a tool yet. Fix the language first.

Build one path step by step

Start with the approval that slows work down every week. One is enough. If you try to fix every approval at once, people get lost, and the new process dies before anyone trusts it.

Pick a request that already hurts: purchase orders, content sign-off, release approval, or refund approval. The best choice is the one that keeps showing up in chat, email, and meetings because nobody knows who is waiting on whom.

Then build the path in a few direct steps:

1. Choose one request type and give it a clear starting point.
2. Write down who starts it, who reviews it, and who gives the final yes or no.
3. Add a time limit to each handoff.
4. Keep the request, comments, files, and final decision in one place.
5. Run one real request through the flow and watch where people hesitate.

Names matter. Use real job titles or team names, not vague labels. If two people can make the same decision, pick one owner and one backup. Shared ownership sounds polite, but it usually turns into delay.

Time limits matter just as much. Without them, a request can sit in "waiting" for five days and nobody feels responsible. You do not need harsh rules at the start. A simple deadline and one reminder already remove a lot of drift.

Keep everything together. When the file lives in one tool, comments sit in email, and approval lands in chat, the team starts arguing about the latest version instead of the decision. One record should show the request, the current state, the comments, and the attached file. That alone makes an approval process feel calmer.

A small test tells you more than a workshop. Put through one real request this week. Watch how long it takes to submit, where people ask questions, and which step feels unclear.

If the test stalls, do not add more rules. Remove a step or rename a state until the path feels obvious. People follow a process when they can see it, trust it, and finish it without asking three people what happens next.

A simple example from a growing company

A 30-person company needs a new customer support tool. The head of support wants faster replies, so she asks for a shared inbox with chat and ticket history. In the old setup, she would email finance, copy security, and wait. Someone would miss the thread, a manager would approve the wrong plan, and the team would buy the tool before anyone checked what data it could access.

A clean approval flow turns that mess into a few clear states:

• Requested
• Budget checked
• Security review
• CTO review if needed
• Approved for purchase

The request starts with a short form. The support lead names the tool, monthly cost, number of seats, and why the team needs it. That sounds basic, but it removes a lot of back-and-forth. Finance can see the expected spend right away and compare it with the team budget before anyone reaches for a company card.

If finance says no, the request stops there. The requester gets a clear reason, such as "not in this quarter's budget" or "use the existing tool for now." People may not love the answer, but they trust a process more when it ends cleanly instead of fading into silence.

If finance approves, security checks the real risks. Does the tool store customer data? Does it need access to email, CRM records, or internal files? Can the company use single sign-on, or will employees create loose passwords and forget them six months later? Security does not need a long report for every purchase. A short checklist is enough for most cases.

The CTO only steps in when the case is unusual. Maybe the tool overlaps with something the company already pays for. Maybe it asks for broad access to customer records. Maybe the support team wants an annual contract when the company is still testing the process. That is where a good CTO helps most: not by approving every small purchase, but by deciding the exceptions and fixing the rules behind them.

Once the decision is made, the loop closes. The requester sees the final status, finance knows whether to release funds, and IT or operations can buy the tool and record who owns it. No one needs to search five inboxes to answer a simple question later: "Who approved this, and why?"

Mistakes that make people ignore the process

People stop using a process when it feels slower, less clear, or less fair than the old mess. Once that happens, they go back to chat messages, side emails, and favors from managers. The tool may still look tidy, but the real approval process happens somewhere else.

The first mistake is adding too many states. Four clear states often beat ten clever ones. If a request can sit in "pending review," "manager review," "director review," "finance review," and "final confirmation," most people will not know what changes between each step. They only see delay.

A simple rule helps: every state should answer a different question. Is it ready? Is someone reviewing it? Is it approved? Is it done? If two states mean almost the same thing, merge them.

Another common failure is letting managers approve work in chat "just this once." That one shortcut teaches the team the wrong lesson fast. If people can get approval in a chat thread, they stop updating the system because the system no longer decides anything.

The fix is not strict policing for its own sake. The fix is making one place count as the source of truth, then asking managers to use it every time, even for small requests.

Rules also break down when teams hide them in long documents nobody opens. If staff need to read a six-page policy to know who can approve a refund or a budget change, they will guess. Then each manager applies different rules, and the team starts treating the workflow as paperwork instead of a real decision path.

Short rules inside the flow work better. A person should see the next step, the owner, and any limit that matters right where the request lives.

Another mistake hurts trust more than teams expect: changing steps without telling anyone. A request that took two approvals last week now needs three, but nobody explains why. People assume the process is random, or worse, political. Even a small change needs a short note, a date, and one reason people can understand.

The last trap is tracking exceptions in a separate spreadsheet. Teams do this because special cases feel easier to handle outside the system. Then the exceptions pile up, nobody knows which version is current, and audits turn into detective work. If exceptions happen often, they are not exceptions anymore. They belong in the workflow.

You can watch a clean purchase flow break this way over time. New states appear for rare cases. Directors approve urgent requests in chat. Finance rules stay buried in an old document. Steps change after one bad incident. Exceptions move into a private spreadsheet. After a month, nobody trusts the board, the spreadsheet, or the chat log. They trust whoever they know personally. At that point, the process has turned back into office memory.

Quick checks before you roll it out

A clean approval workflow should survive a busy Monday, not just a demo. Before you switch the team over, test it with a few real requests. If people get confused once, they usually fall back to email and side messages.

Start with the simplest test: give the flow to someone new. If a new employee cannot explain what each state means in plain words, the states are too vague. Rename them now. Teams trust simple labels faster than clever ones.

Then check ownership. Every state should answer one question right away: who moves this forward now? If a request sits in review and three people think someone else owns it, the queue stalls. One state should point to one owner and one next action.

A few dry runs are usually enough:

• Ask a new teammate to read the state names and tell you what each one means.
• Open test requests and confirm that the next owner is visible without asking in chat.
• Reject one request on purpose and make sure the reason stays attached to it.
• Try an urgent request and see whether the written shortcut works without special favors.
• Check email, chat, and the tool. Only one place should show the latest status.

Rejections need extra care. "Rejected" by itself starts arguments. A short reason such as "budget missing" or "missing manager sign-off" saves time and cuts repeat work. People handle a no much better when they can see why it happened and what they need to fix.

Urgent cases also need rules on paper. Every team has them, even if nobody says it out loud. Write down who can mark something urgent, what changes when they do, and when that shortcut ends. If you skip this, people treat every delayed request as an emergency.

One last test catches more problems than it should. Pick five active requests and ask where each one lives right now. If the answers come from email, a spreadsheet, and memory, the system is not ready. One place must hold the latest status, or the approval process splits in two.

This step looks small, but it decides whether the workflow sticks. If one person can submit a request and another can approve it without side messages, the rollout is probably safe.

What to do next

Start small. Pick one approval that already causes friction and fix that first. A purchase request, a pricing exception, or a content sign-off is enough. If you try to rebuild every approval path at once, people will stop paying attention before the new rules settle.

Write the current path in plain words. Who starts it, who reviews it, what counts as approved, and where the final decision lives. Keep it short enough that one manager can read it in under two minutes.

Then put the new workflow into use and watch what happens for two weeks. Do not judge it by opinion alone. Track a few numbers that show whether the flow is actually easier to follow:

• wait time from request to decision
• how often work goes back for fixes
• how many approvals people skip outside the system
• how often someone asks, "Who owns this now?"

Those numbers tell you more than a polished diagram. If wait time drops but rework goes up, the states may be too loose. If people still skip steps, the flow may ask for approval too early or involve the wrong person.

After those first two weeks, rename anything that feels fuzzy. "Pending" is often too vague. "Needs finance review" or "Waiting for legal" is harder to misunderstand. Ownership needs the same cleanup. A team cannot own a step in practice. One role, or one named person, should own it.

Cross-team approvals need extra care. Sales, finance, legal, and engineering often use different tools and different words for the same status. That is where outside help can save a lot of time. Oleg Sotnikov, through oleg.is, works with startups and smaller companies on this kind of cleanup: clarifying workflow states, reducing tool sprawl, and adding automation where it actually helps.

A good result is boring in the best way. People know where a request sits, who needs to act, and what happens next. If your team can answer those three questions in a few seconds, the process is doing its job.