The Bottom Line, First
“Start with one workflow” is good advice. But which one matters enormously. The right first pilot builds confidence and creates momentum for everything that comes after. The wrong one wastes time, disappoints the team, and makes the next attempt harder to sell. The best pilot shares three traits: it hurts enough to matter, it’s clear enough to define, and it’s small enough to prove. Pick that one. Get it right. Then expand.
And now for the details.
Why the First Workflow Matters More Than You Think
Most teams that start automation with a bad first project don’t just fail at that project. They become automation-averse. The team loses confidence. Leadership loses patience. The next initiative, even if it’s better-scoped, faces resistance from people who remember what happened last time.
Why most automation projects fail comes down to approach, not technology. And the most common approach mistake is picking the wrong starting point: the workflow that sounds most impressive, or has been on the whiteboard the longest, or feels like it should be automatable. Not the one that will actually prove the concept cleanly.
The right first workflow does something specific. It delivers a visible, undeniable improvement in something the team already cares about. It makes the second project easier to scope and easier to approve. It turns skeptics into supporters.
Starting small isn’t a compromise. It’s how you build the trust that makes everything else possible.
Three Signs a Workflow Is Pilot-Ready
Not every painful workflow is a good starting point. The best first pilots share three characteristics.
The pain is felt, not theoretical. The team knows this workflow is broken. They talk about it. Requests get dropped. Clients follow up because nothing happened. The cost of the current state is obvious and immediate, not something you have to convince people to care about.
A workflow that “could probably be more efficient” isn’t a strong pilot. A workflow where your team dreads the volume that accumulates over a long weekend? That’s a pilot.
The workflow is clear enough to describe. You don’t need a perfect process to automate. But you need to be able to explain it. Who handles it? What triggers it? What does done look like? If the team can’t agree on how the workflow runs today, even roughly, automation will just encode the confusion. Clarity first, then automation.
Success is measurable. A good pilot has a visible finish line. Response time drops from three days to one. Drop rate goes from one in ten to nearly zero. Clients stop sending follow-up emails to ask if their request was received. These are specific, observable improvements. Vague goals like “run more smoothly” don’t give you a way to know if the pilot actually worked.
What to Avoid Starting With
Some workflows look appealing as pilots and almost always disappoint.
Complex, multi-step processes. End-to-end onboarding, full renewal cycles, billing workflows: these involve too many handoffs, too many stakeholders, and too many edge cases. Even when they eventually work, it takes so long to get there that the team loses faith before the results show up.
Workflows nobody fully understands. If the one person who runs this process is also the only one who knows how it works, automating it will surface every undocumented exception and informal rule. That’s valuable eventually. It’s not a clean pilot.
Low-volume, low-stakes work. If the workflow happens twice a month and nobody minds doing it manually, automation won’t generate visible improvement. Pick something that happens daily or weekly and creates real friction when it goes wrong.
Politically charged processes. Workflows tied to performance decisions or internal territory disputes are the wrong place to start. Automation should reduce operational friction, not get caught in organizational friction.
How to Evaluate Your Options
Here’s a practical way to narrow down candidates without overcomplicating it.
List three to five workflows that cause the most pain right now. Then ask three questions about each one.
How often does it go wrong? Frequency matters. A workflow that drops requests several times a week has more upside than one that’s occasionally a problem. Higher volume means faster feedback and more visible improvement.
How quickly can you tell if it’s working? Some improvements take months to surface. Others show up in two weeks. The faster the feedback loop, the faster the pilot builds credibility. Prefer workflows where you can measure results within the first month.
Can one person walk you through it in 30 minutes? If understanding the workflow requires six meetings across multiple departments, it’s not ready. If a single team member can describe it, including the common edge cases, clearly enough to design around, it probably is.
Run through your candidates honestly. The one with the clearest pain, fastest feedback loop, and most describable process is your starting point.
Where Good Pilots Usually Start
The pattern is consistent across different business types: the right first workflow is usually upstream, where requests first arrive, not downstream, where the work gets complex.
Property management: Start with maintenance request intake and routing, not lease renewals. Maintenance requests are high-volume, time-sensitive, and painful when missed. Renewals involve too many variables and relationships to be a clean first pilot.
Accounting: Start with document intake: getting the right files from clients at the right time. Not tax return preparation, which is complex and high-stakes. Getting documents in cleanly is a discrete workflow with measurable success criteria.
Professional services: Start with client question routing. Which questions go to billing? Which go to the technical team? Getting that routing consistent and visible is a bounded first step with immediate impact on response times.
Home services: Start with quote request triage, not scheduling. Capturing and categorizing incoming quote requests is well-defined. Scheduling involves availability, geography, and customer preference. Too many variables for an early pilot.
In every case, the inbox is where most requests first appear, and it’s already a system whether you designed it or not. Starting there keeps the scope manageable while targeting the moment where the most drops occur.
After the Pilot Works
A successful pilot doesn’t mean you’re done. It means you have proof.
Use it. The team now knows what reliable looks like in at least one workflow. The edge cases are documented. A good pilot also surfaces which exceptions actually occur in practice. Designing for them before you expand is how you avoid rebuilding the same gaps in the next workflow. Ownership is clear. Measurement is in place. From there, expansion is straightforward: pick the adjacent workflow most similar to what you just got right, and apply what you learned.
Each iteration gets faster. Each workflow builds on the foundation of the last. Reliable operations develop this way: not through a single overhaul, but through a series of deliberate improvements that compound over time.
That’s what starting small actually looks like. Not a limitation. A strategy.
Where DST Fits
At DST, every engagement starts with a pilot. But whether you work with us or not, the principle holds: one reliable workflow is worth more than five half-working ones. Start there, and the path forward becomes clear.