What Is a Workflow, Really?
The founder of one of our early customers told me: "We don't have a lot of repeatable processes or rigid workflows."
I asked him: "Don't your solutions engineers do the same thing 20 times a day after customer calls?"
He paused. "Well, yeah, they do."
This conversation happens constantly. Companies avoid workflow tools because they don't see themselves as having "workflows." But the problem isn't that they lack workflows—it's that tools have made "workflow" synonymous with rigid, top-down procedures.
The Misconception¶
Most people think workflows must be rigid, top-down procedures imposed by operations teams ten departments away. This narrow definition makes companies resist thinking about workflows entirely, missing out on opportunities to improve their efficiency and learn best practices.
The Reality: Workflows Are Everywhere¶
I spent 10 years at Asana leading its workflow and AI organizations. The most successful customers had something in common: they didn't think of workflows as rigid processes. They treated them like they treat their product - something core to their business that should be continuously improved.
Here's the truth: workflows are just how you want work to get done. That sounds almost too simple, but it can be eye-opening.
These are all workflows:
- Every morning I check community feedback and see what customers are saying
- When a customer asks a question, I first look at their recent usage and correspondences to see if there's context to be aware of.
- When reviewing a bug report, I consider if it affects all customers or is related to a recent change to determine whether to escalate to on-call engineers or make a ticket for the appropriate teams' backlog.
Workflows aren't binary. They exist on a spectrum from loose and bottom-up (how an SE follows up after calls) to tight and top-down (compliance checks with specific requirements).
When your product has a bug, you fix it. When your team has a "process bug" - discovering a better way to work like checking customer history before responding, routing cases differently, or adding a new approval step - they should be able to try it immediately. Not do it manually for weeks to prove it works. Not file a ticket with IT to automate it. Not wait for their SaaS tool to prioritize it.
This is what Malleable is built for: adaptive software for teams' workflows, not procedural automation. Workflows that evolve through use - which is exactly how they should work, but traditional tools don't support.
Here's what that looks like in practice.
How Workflows Actually Evolve¶
A solutions engineer at a B2B Support Platform spent the end of each day doing the same thing: scrolling through meeting transcripts and spreadsheets to find the right documentation links to send each customer. He knew exactly what each customer type needed, but the hunting took 30-45 minutes per call.
He set up a workflow in Malleable in under five minutes. A simple form where he'd paste the meeting link, and Malleable would find the right docs and draft the email. His teammate noticed the better follow-ups and asked to use it. He added a Slack trigger, and within days noticed his team adopting it. After a few weeks, they decided to run it automatically after each call. When their product launched new features, their workflow stayed up to date because it referenced live documentation.
Five minutes of setup, a couple minutes for each iteration. For a team of five SEs doing 4-5 calls daily, that's 50+ hours saved per week.
This is how everything else works. You don't wait until a dish is perfect before trying it - you taste and adjust. You don't wait until an email is perfect before drafting - you write, read it back, refine.
But traditional tools force you into procedural automation: specify everything upfront, map every customer type, build explicit routing rules, handle every edge case, get IT approval - then it immediately goes out of date. In practice, teams don't even start. The individual "papercuts" don't justify the slog.
The difference isn't just speed. It's a fundamentally different paradigm: workflows that evolve through use, rather than requiring perfect specification upfront.
And he wasn't alone. Across his company, every team had their own version: account managers manually tracking renewal signals, support engineers cobbling together ticket triage rules across three tools, product managers copying customer feedback between Slack, Linear, and Notion. Each one is a workflow that should be software - but SaaS vendors aren't able to build every feature, and it would take too long to build in traditional tools. So they just lived with the manual process.
Why Traditional Tools Don't Work¶
1. You don't know the edge cases until you run it¶
The people who know workflows intimately often can't articulate every detail upfront. They know it when they see it, but perfect specification is a different skill entirely.
Edge cases emerge through use, not specification. You can't predict them all upfront, and trying to is what makes procedural automation projects take months instead of days.
Learning through use is how humans actually work: you show someone once, they try it, you give feedback on what they missed, and within a few iterations they've got it.
2. Requirements change faster than you can rebuild¶
That solutions engineer? His company launched a new product feature that came up in customer meetings. With traditional tools, adding it would mean: update the documentation mapping, modify the routing rules, test all the conditional logic, redeploy.
With Malleable, the workflow stayed current because it referenced live documentation. When a call discussed a feature which wasn't documented yet, the workflow slacked him to ask: "This feature isn't in our docs - should I use the bug workflow to flag it?"
The velocity of business change has outpaced the velocity of workflow reconfiguration.
3. You need both domain expertise AND technical expertise¶
To specify a workflow perfectly upfront, you need complete understanding of both: (1) the workflow itself - what matters, what edge cases exist, and (2) the "art of the possible" - what integrations exist, how to optimize the technical implementation.
The people running workflows have the domain expertise but not the technical expertise. The technical people don't have the deep workflow knowledge. Traditional tools require both, which is why workflows either never get built or are poorly specified.
This is the self-service illusion. Tools promise "anyone can build workflows" but actually require expertise in API configurations, data mappers, and connector logic. The "no-code" promise becomes a maintenance nightmare.
The New Workflow Lifecycle¶
Software development used to work like this: spend months deciding the plan, build it, test it, ship it in a quarterly release - then wait another six months to fix what you got wrong.
Now? Code ships hundreds of times per day. Teams learn from real usage and iterate constantly.
Your workflows should work the same way.
A workflow isn't something you build once and freeze. It evolves, stabilizes, then continues to morph as your business changes. The software should support that natural process, not force you to rebuild from scratch each time.
When one team member refines the workflow, everyone benefits immediately. The organizational intelligence accumulates in the workflow itself, not just in people's heads.
Why This Matters Now¶
GenAI is making it easier than ever to adopt traditional workflow tools - or to vibe-code custom solutions from scratch. You can generate Zapier configurations faster. You can prompt an AI to build you a bespoke form in minutes.
But faster doesn't mean better. AI helps you build brittle workflows faster - you're just compressing the same problems into a shorter timeframe and creating more one-off processes that drift from how work actually happens.
Traditional workflow tools force a false choice: either spend weeks specifying everything perfectly upfront, or don't automate at all. Most teams choose the latter. They live with manual processes because the barrier to automation is too high.
But there's a third option: workflows that start simple and evolve through use. Workflows where you describe what you're trying to achieve and the software figures out how to do it. Workflows that get smarter each time they run.
Success is measured by how quickly your team adopts new workflows and what they can accomplish - not by how much effort went into building them.
Ready to try Malleable? We're working with fast-growing companies to transform how their teams work. Join our waitlist to get early access.
Next: How does this actually work? How can workflows be specified at a higher level and work without all the technical details? Read Part 2: The Three Layers of a Workflow (coming soon)