Loading…
ES/EN
A workflow is a defined sequence of steps that moves a task from initiation to completion, with clear owners and explicit handoff conditions. The problem in most mid-sized businesses isn't a lack of workflows — the workflows exist but are implicit: they live in people's heads, not in any document. That creates errors, bottlenecks, and dependence on specific individuals. Designing a workflow that actually changes team behavior requires more than drawing a diagram.
In a company that's been operating for years, processes don't disappear — they evolve informally. The team develops a way of doing things that works most of the time, and that way exists in practice but not in any document.
This works reasonably well as long as the team stays small and stable, volumes remain manageable, and the most experienced people are available.
When any of those conditions change — turnover happens, work volume grows, new markets open up — the implicit system shows its limits.
The symptoms are recognizable. The same type of error recurs, with different people involved each time. No one knows exactly where a specific task stands in the process. A project stalls because the person who "knows how that part works" is on vacation or has left the company. Tasks fall through the gaps because everyone assumed someone else was handling them.
These are not attitude problems or capability problems. They're structural problems: the rules of the game aren't clear to everyone, and the consequences of that ambiguity accumulate over time.
An explicit workflow isn't bureaucracy — it's the mechanism by which operational knowledge stops living in individuals' heads and becomes part of how the team functions, regardless of who's in the room.
A well-designed workflow has five components. If any one is missing, the workflow will have blind spots.
The most common mistake in process documentation is describing how the process should work instead of how it actually works. A workflow designed around "what should happen" doesn't reflect reality, and the team won't follow it.
The first step is always to observe and document what actually occurs: talk to the people who execute the process, follow a task from beginning to end, identify the steps that exist even though they're not "officially" written anywhere.
This mapping usually reveals surprising things: duplicate steps no one had questioned, decisions that theoretically involve three people but in practice are always made by the same person, waiting periods no one had calculated that add days to the total cycle.
A workflow isn't just a linear list of steps. At every process there are moments where the next step depends on a condition: Did the client approve? Was the payment received? Does available inventory cover the order?
These decision points are where implicit workflows generate the most ambiguity. When the condition isn't clearly defined, each person decides differently — or worse, waits for someone else to decide.
In workflow design, every decision point needs two elements: the condition being evaluated and the possible routes based on the outcome. "If the amount exceeds X, it requires manager approval. If not, proceed directly." Without that clarity, the decision depends on who's available at that moment.
The riskiest moment in any process is the handoff between people or teams. It's where things fall most often.
A well-defined handoff has three components:
When handoffs are implicit — "they know when I finish, they take over" — tasks get lost, effort gets duplicated, and friction builds between teams.
Robust workflows assign responsibilities to roles, not individuals. "The credit analyst reviews the application" is more resilient than "Maria reviews the application," because the workflow doesn't depend on Maria being available.
This is especially important in mid-sized companies where there's little or no backup for critical functions. If the workflow says "Pedro does this," any absence of Pedro stops the process. If it says "the operations coordinator does this," the process can continue as long as that role is filled.
Every workflow has exceptions. The client who demands non-standard terms, the vendor who didn't deliver on time, the case that doesn't fit any predefined category. Well-designed workflows have clear escalation paths: when to escalate, to whom, and with what information.
Without this, exceptions always land with the same person — typically the manager or most experienced team member — interrupting their work with things that could be resolved at another level.
Many companies have process manuals that no one consults. The diagram exists, but the team keeps doing things the way they always have.
The difference between a documented workflow and an adopted one comes down to four factors:
Team participation in the design. Workflows designed by a manager or consultant in isolation and then "handed down" to the team have low adoption. Workflows built with the people who will execute them — because they know the details that don't appear in any diagram — have much stronger adherence.
Integration with real tools. A workflow that lives only in a PDF doesn't change behavior. A workflow integrated into the tools the team uses every day — a management system, a task board, an intake form — does. The friction of following the process has to be lower than the friction of improvising.
Compliance measurement. If no one measures whether the workflow is being followed, the team reverts to previous habits within weeks. Simple metrics — average time per stage, percentage of tasks that pass through all defined stages — make adherence to the process visible.
Periodic review. Workflows are not static documents. Business conditions change, the team grows, new tools emerge. A workflow no one reviews for two years probably no longer reflects operational reality.
A professional services firm in San José had a client onboarding process that in theory took two weeks. In practice, it took four to eight weeks because no one had clear ownership of what happened between contract signing and project kickoff.
Mapping the actual process surfaced nine steps — some formal, several informal — distributed across four people with no defined flow. The signed contract arrived with the sales manager, who eventually notified operations, who eventually assigned a coordinator, who eventually reached out to the client to schedule the first meeting.
The redesigned workflow didn't change the essential steps — it changed who activates them and when. A signed contract automatically triggers a task in the management system, assigned to the operations coordinator, with a 24-hour window to contact the client and 72 hours to schedule the kickoff meeting. Each handoff has a clear definition and a record in the system.
Onboarding time dropped to a consistent two and a half weeks. Not because the team worked harder — but because the rules were clear to everyone.
Does your company have processes that work when the right people are available but stall when they're not? Schedule a session and we'll review your most critical workflows, identify where the breaking points are, and define how to redesign them to operate predictably.
MORE IN THIS CATEGORY
What an Internal Ticketing System Is and When You Need One
What an internal ticketing system is, what problems it solves, and when it makes sense to implement one at a mid-size company. For operations leaders in LATAM.
How to Build a Weekly Operations Report That Generates Itself
How to eliminate the manual operations report with a system that collects, structures, and distributes data without human intervention. For companies in LATAM.
What to Automate First When Your Company Has 20 to 50 People
A framework for identifying the first automation target at mid-sized companies: frequency, time, and error cost. Common first candidates and why starting small works