The map of work beats the demo

Every automation project has two moments. The demo, which goes well. And the following Tuesday, which does not.

The gap between them was the quiet theme of UiPath's Fusion conference last week. CIO's coverage (opens in a new tab) of the Cartographer launch is worth reading for the customer quotes rather than the product news, because the people running this work in production keep describing the same failure.

The blocker was never the model

The story the industry told for two years was that agents needed to get smarter. The story from the people actually deploying them is different. What kept the messiest processes out of reach was that nobody could describe those processes accurately.

Andrea Simpson, IT manager of automation at USI Insurance Services, put it plainly to CIO. So much knowledge is in a person's head, and it can be hard to get it out of subject matter experts. She also said that getting a full picture of a process often does not surface until well after a bot is already live.

That is the Tuesday problem stated precisely. The demo runs on the described process. Tuesday runs on the real one.

What the demo leaves out

When we map a workflow before building anything, the parts that never make it into a process document are fairly consistent.

• The exception that happens twice a month and takes an hour each time
• The step someone skips when the queue is long, and the conditions that make it safe to skip
• The handoff that happens by message rather than through any system
• The judgment call that one person makes well and nobody else has been taught

None of that is in the demo, because the demo is built from the version of the process that got written down. The agent then meets the real version on Tuesday and has no idea what to do with it.

Judgment is produced constantly and thrown away

There is a line in Dines' launch post (opens in a new tab) that stuck with us. Every time a reviewer approves something, rejects it, changes a recommendation, or escalates it, they produce judgment. Almost all of it is lost the moment the task closes.

For twenty years that was an inconvenience. It becomes expensive once you start handing work to a system that has no way to infer it.

Doug Marcey, CTO at Coronis Health, described the alternative to CIO as closer to on the job training for agents, where each new exception routes through a decision ledger for a human owner to approve before it feeds back into the map. Whatever you call that mechanism, the shape is right. Exceptions get captured as they occur, a person signs off, and the system gets less ignorant.

Some of it should stay out of the system

Worth being careful here, because the tempting conclusion is that everything should be captured. Simpson drew a line we would draw too. The biggest hole in her picture is what happens off the record, a phone call or a conversation at someone's desk. Her view was that they would not want that automated. They want to keep it human.

That is not a gap to close. That is the part of the job that is the job.

What we do about it

Nothing exotic. We treat the mapping as the deliverable for the first stretch of work, not as paperwork before the real build.

That means the exceptions get drawn before the happy path, a named person owns what happens when the agent flags something, and the first version ships narrow enough that a bad Tuesday is survivable. Then it widens.

Amy Loomis at IDC noted that the capture step will only be as strong as the tribal knowledge of teams and the ability to get it out accurately. True, and it is why this cannot be bought as a tool alone. Somebody internal has to be willing to sit down and say how the work really runs, including the parts that are slightly embarrassing.

That willingness is the actual prerequisite. Not the platform.

Tell us where the hours go

No pitch required. Name the team and what the work costs them in a week. That is enough to tell whether we are useful.

Contact