How to design and run a to-be business process

Your to-be process is the version of work that should exist after you’ve figured out what’s broken. Most teams skip the hard part - they jump to drawing fancy flowcharts without truly understanding the mess they’re trying to fix.

I’ve spent over a decade building Tallyfy, and one pattern keeps showing up. Teams get excited about process improvement, draw a beautiful future-state diagram, and then… nothing changes. The diagram sits in a shared drive. People keep doing things the old way. Six months later, someone asks “didn’t we fix that?” and everyone shrugs.

The gap between a to-be process on paper and a to-be process that’s running in the real world is where most improvement efforts die. Let me walk you through how to close that gap.

What a to-be process really is

A to-be business process is the redesigned version of an existing workflow - your “future state.” You’ve already mapped out how things work today (the as-is process), identified what’s wasteful or broken, and now you’re designing what it should look like instead.

Sounds straightforward. It isn’t.

The tricky part is that most people confuse “to-be” with “ideal.” They draw a process with zero friction, perfect handoffs, and instant decisions. That’s fantasy. A good to-be process is one degree better than your current mess - achievable, measurable, and specific enough that you can tell if it’s working.

One thing that keeps coming up with mid-market operations teams, the ones who succeed start small. They don’t redesign everything. They pick the three worst bottlenecks in their as-is process and fix those. That’s it. A to-be process map should highlight what changed and why - not reinvent the entire workflow from scratch.

How to document the future state

Before you can document a to-be process, you need an as-is process already mapped out. You can’t improve what you don’t understand. If you haven’t done that yet, start there.

Once you know where things break down, documenting the to-be state is about answering a few hard questions:

• Which steps can be removed entirely without losing quality?
• Where are the handoff delays, and can you eliminate any?
• What decisions are people making manually that could follow simple rules instead?
• Are there approval bottlenecks that exist because of tradition rather than necessity?

You can do this with pen and paper. Seriously. A whiteboard works fine for the first draft. The goal isn’t a polished BPMN diagram - it’s clarity about what changes.

If you need something more structured, you have a few options:

• Pen and paper - Grab a marker, draw the steps. Fast and cheap. Good for brainstorming sessions where you need people to argue about what’s really happening.
• Flowchart tools - Software for creating process maps. Better for sharing digitally, but the chart itself doesn’t enforce anything.
• Workflow software - Tools that don’t just document processes - they run them. The to-be process becomes a living workflow that people follow, not a static diagram they forget about.

The difference between these three options matters more than you’d think. I’ve probably seen a thousand process flowcharts that were beautifully drawn and completely ignored. A flowchart describes work. Workflow software runs it.

Why most to-be processes fail

Here’s the uncomfortable reality. Research from research suggests that roughly 70% of large-scale change programs don’t succeed. And separate research into continuous improvement initiatives found that up to two-thirds fail to deliver expected results.

Why? It’s almost never because the new process was badly designed.

The most common killers are human, not technical:

People resist change. Kotter and Schlesinger’s research from Harvard Business Review identified four root causes: self-interest, misunderstanding, disagreement about the need for change, and low tolerance for disruption. Even when the new process genuinely makes their jobs easier, people default to old habits within weeks.

This is probably the single most frustrating pattern in process improvement. You can design the perfect to-be state, get executive buy-in, run a pilot, prove it works - and people will still quietly revert to their old ways within a month. Nobody enforces the new way, either. You can’t just email a PDF of the new process and expect compliance.

We built Tallyfy because we kept seeing the same complaint from operations leaders: “We designed a better process, but nobody follows it.” Running Tallyfy taught us this so often that enforcement is baked into how the product works - if a step exists in the workflow, it has to be completed before moving forward.

Metrics are an afterthought. Teams launch a new process without baseline measurements. Three months later, someone asks “is this better?” and nobody can answer. You need to know what you’re measuring before you change anything.

How to roll out changes without chaos

Documenting the to-be process is maybe 20% of the work. The other 80% is getting people to do things differently. Here’s what I’ve found works:

Pick your metrics first. Before touching anything, write down the three numbers you’re tracking. Cycle time? Error rate? Handoff delays? You need a baseline from the as-is process and a target for the to-be process. Otherwise you’re just guessing.

Account for second-order effects. Sometimes improvements create new problems. I think about this a lot. If you speed up manufacturing output, does your defect rate climb? If you shorten approval cycles, do you lose oversight? My guess is that most teams skip this step because it’s uncomfortable - it forces you to admit your improvement might have downsides.

Start with one team. Don’t roll out company-wide on day one. Pick one team, one process, one workflow. Run it for two to four weeks. Collect data. Fix what’s broken. Then expand. In our experience, the teams that start small and iterate consistently outperform the ones that try to transform everything at once.

Enforce the process, don’t just describe it. This is where workflow software earns its keep. When you run a process in a tool like Tallyfy, every step has an owner, a deadline, and required fields. You can’t skip steps or pretend they didn’t happen. That’s fundamentally different from sending someone a flowchart and saying “please follow this.”

AI makes getting this right even more urgent

Here’s a mega trend that I think about constantly:

Forrester published a piece that nails this: if your workflows are fragmented or unclear, AI will accelerate the confusion, not the impact. And research from MIT and the U.S. Census Bureau found that firms without disciplined management practices actually saw productivity decline after adopting AI - with older firms losing ground on basic operational metrics.

This matters for to-be process design because we’re entering an era where every company wants to “add AI” to their operations. But AI agents need structured workflows to follow. Sequential steps, clear decision points, defined handoffs. Without that structure, you’re just amplifying confusion at machine speed.

The to-be process you design today is the foundation that AI will run on tomorrow. Get it wrong, and AI will scale the mess. Get it right, and AI will scale the improvement.

We’ve been thinking about this a lot at Tallyfy. The workflow patterns that make processes work for humans - sequential, parallel, evaluation loops - are the same patterns that AI agents need to operate effectively. Defining your processes isn’t just good management anymore. It’s infrastructure.

After rollout - tracking what matters

You might think you’re done once the new process is running. You’re not.

The to-be process needs monitoring. Continuously. Not a quarterly review where someone pulls together a slide deck - real, ongoing measurement against the KPIs you set before launch.

Here’s what to watch for:

• Are cycle times actually shorter? If the to-be process was supposed to cut turnaround from five days to three, is it?
• Has quality changed? Sometimes faster means sloppier. Track error rates alongside speed.
• Are people following the process? If completion rates drop after the first month, you have an enforcement problem, not a design problem.
• Are there unexpected bottlenecks? New processes create new constraints. The bottleneck just moves somewhere else if you’re not careful.

If something isn’t working, roll back. That’s not failure - it’s data. The to-be process is a hypothesis, not a commandment. Test it, measure it, adjust it.

Using workflow management software makes this dramatically easier because you get real-time data on every step. Who completed what, when, how long it took. No guessing, no surveys, no manual tracking. That visibility is what makes the difference between process improvement that sticks and process improvement that fades.

Example to-be process templates

Example Procedure

Quarterly Strategic Planning & Goal Setting Workflow

1Revisit annual plan goals

2Break down goals into smaller chunks

3Review budget and benchmarks

4Create action steps and benchmarks

5Set expectations and timelines

+2 more steps

View template

Example Procedure

Employee Onboarding

1Save offer letter to employee file

2Send welcome email to new hire

3Set up HR system account

4Create onboarding task list

5Schedule onboarding activities

View template

Example Procedure

Client Onboarding

1Gather Basic Information

2Send Welcome E-Mail

3Conduct a Kick-Off Call

4Conduct a 1 month check-in Call

5Request Feedback

+1 more steps

View template