The Lobbi Delivery Team
Operational Systems Engineering
The most common reason automation projects fail is not a bad vendor, an underpowered tool, or a budget overrun. It's that the team tried to automate a process they hadn't mapped. They knew roughly what they wanted the system to do. They didn't know precisely what the process actually was, where it broke, or what a successful outcome looked like in measurable terms.
You can't automate ambiguity. You can only encode it, at which point the automation reliably does the wrong thing faster than the manual process did.
The three questions that precede every build
Before any scoping conversation, before any tool evaluation, we work through three diagnostic questions with every client. The answers determine whether automation is the right move, and if so, what exactly to build.
What is the actual process?
Not the intended process, the actual one. The sequence of steps as they happen today, including every manual workaround, every exception path, every "that's just how Jessica handles it." The happy path is usually documented somewhere. The exception paths, which is where the operational cost lives, almost never are.
What are the failure modes?
Where does the process break, and how often? Where does work stall, get lost, get duplicated, or require re-entry? What percentage of items go through the exception path rather than the happy path? These numbers matter because they determine where automation delivers the most value, and because any automation that doesn't account for the failure modes will reproduce those failures at scale.
What does done look like?
What is the specific, measurable outcome you're trying to achieve? "Faster" is not a success criterion. "Reconciliation cycle reduced from 14 days to 2 days" is. Without a defined success criterion, there's no way to scope the build, estimate ROI, or evaluate whether the engagement delivered what was promised.
Process inventory: documenting current state
Answering those three questions requires a structured current-state investigation. We run this in two parts.
Stakeholder interviews are the primary input. The people doing the work know things that documentation doesn't capture, the undocumented workarounds, the informal approval paths, the step that always breaks when a certain carrier's system is down. A structured 45 - 60 minute interview with each key process participant surfaces the actual workflow, not the idealized version.
The output of each interview is a swimlane diagram: a visual map of who does what, in what sequence, with explicit handoff points and documented exception paths. Swimlanes force precision. "Operations handles it" becomes three distinct steps owned by two different people, one of which has a 30% exception rate that nobody had articulated before.
For each step in the diagram, we capture time-cost estimates: how long the step takes, how often it runs, and what happens when it fails. This produces a rough operational cost baseline, the total staff-hours consumed by the process per cycle, that becomes the denominator in any ROI calculation for the automation.
Bottleneck analysis: not all manual steps are equal
A process inventory with 40 steps does not mean 40 automation candidates of equal value. Manual steps are not equally expensive.
We rank each step across three dimensions:
Time cost, how many staff-hours does this step consume per month. High-volume repetitive steps score highest here even if each individual instance is fast.
Error rate, what percentage of instances require rework, produce downstream data quality issues, or trigger exception handling. Steps with high error rates are automation candidates even if the time cost is modest, because the cost of the errors extends far beyond the step itself.
Compliance risk, are there audit, regulatory, or contractual requirements attached to this step? Manual steps with compliance implications are high-priority automation candidates because the cost of failure isn't just operational, it's regulatory.
Multiplying these three dimensions produces a prioritized list of automation candidates. The top items on that list are where the build should start. not the steps that are most technically interesting, not the steps that the loudest stakeholder wants automated, but the ones that score highest on the three-dimensional ranking.
The output: a prioritized automation roadmap
The deliverable from a current-state mapping engagement is not a list of things to automate. It's a prioritized roadmap with three elements for each candidate:
Effort estimate, based on the technical complexity of the integration, the quality of available APIs, and the data normalization work required. Not a vague range, a specific week estimate tied to defined acceptance criteria.
ROI baseline, the projected reduction in staff-hours, error rate, and compliance exposure if the automation performs as specified. This is what gets measured at go-live and at 90 days post-launch.
Sequencing rationale, why this item comes before or after others. Some automation candidates are prerequisites: you can't automate the downstream step until the upstream data quality problem is solved. Making the sequencing explicit prevents the common failure mode of building automations that work in isolation but can't be connected.
This is the output our Discovery engagement produces. It's not glamorous, it's a scoped roadmap, not a working system. But it's the foundation that makes every subsequent build faster, more accurate, and more likely to deliver against the numbers the business actually cares about.
The teams that skip this step and start building immediately typically spend the first three months rebuilding what they built in the first month. The mapping work is not overhead, it's the project plan.
Topic clusters