No more tickets: what a prebuilt solution does that static software can't

Authored by:

Mark Geene

illustration of a woman walking a winding orange path through a desert of floating blue, gray, and orange blocks toward a sunlit stepped pyramid on the horizon

Summarize:

Almost every enterprise I talk to has a version of the same problem: the struggle between knowing a process needs to change and actually changing it. A payer updates a medical policy, or a regulator revises a screening threshold, and the people who run that process know within a day what needs to change. Then they file a ticket. The change lands in three weeks or three quarters, or if your team of application administrators can’t get it done it goes onto a vendor's roadmap and never arrives. For a process that rarely changes, that’s an annoyance you can tolerate. For the highly regulated, exception-heavy processes my team builds solutions for, it’s a heavy burden on the people who understand the work best, but who have the least ability to change how it runs.

This frustration came up in nearly every customer meeting I had at UiPath FUSION last month. Rather than asking about agents or models, customers wanted to know who decides which version of a policy applies, where the exceptions live and how the system can learn from these exceptions. Those aren’t AI questions. They’re practical questions about whether software can keep up with a business that keeps evolving.

What makes a solution different from software you can buy?

Take a manufacturer. There are certain processes that are theirs alone: several teams, a dozen systems, exceptions branching on disputed coverage, and judgment calls nobody outside the company would recognize. No vendor could have prepackaged that, so that process map has to be drawn with them. Their source-to-pay process is different. Manufacturers generally follow the same steps to buy and pay, even though each company has its own policies and rules. Because the process is standardized, much of its map can be built in advance. The same company can need a custom map for one process and a prebuilt solution for another.

That second case is what a UiPath Solution is, and it is not a template or a starter kit. The whole Map of Work arrives drawn, and it has three layers:

Structured knowledge: the ontology, the rules and policies, the exception taxonomy for the process
Operating knowledge: the precedents, the worked examples and the judgment your experienced people carry, which is the part that normally walks out of the building when they do
Decision Ledger, previewed at FUSION, which will record the reasoning behind each decision as the work runs

On top of the map ships everything that runs the work. All of it prebuilt, maintained, and improved by us, with no build phase and pricing set against the outcome rather than the effort.

Why SaaS can't keep up

A static application is configured once and then waits for you. A solution built on a Map of Work does something different, and it takes four things working together. The business ontology gives every agent, robot and person the same description of your business objects and how they relate. UiPath Policy Engine turns written policy into structured, versioned rules: the model reads your policy, Policy Engine decides. Maestro orchestrates the work end to end and holds the state of a case across days or weeks. And the decision ledger records the reasoning behind every decision and every correction as the work runs.

Policy Engine is what makes the whole thing work. It shows which criteria passed, failed, or need more documentation. The same case under the same policy version produces the same outcome every time, and the determination can be explained on the day it was made rather than reconstructed later. Costs stay predictable because you aren't paying a model to reason over every transaction.

Here is what that loop is designed to do. A ledger, by its nature, keeps everything: every decision, every override, every piece of feedback given in passing. Agents read that history continuously and propose improvements, each one evaluated against test data before a person ever sees it. What reaches the business team is a recommendation with its evidence attached, and they accept it or reject it. No ticket is filed. Nobody waits on an administrator.

The improvements aren't all the same kind, which is the part I find most interesting. Some take informal knowledge—the judgment an experienced person applied to a messy exception—and turn it into a structured rule anyone can see. Some sharpen an agent's instructions. And some change the shape of the process itself, routing around a bottleneck that only became visible once the work was running. All of it while the process runs, not in a release window. That is the real difference between a dynamic system and a static one. Not that it can be configured, because any SaaS application can be configured, but that it is evaluating itself in production and handing the people who own the work a decision to make rather than a queue to wait in.

There is a fair objection here. If the ticket goes away, what replaces it? It was slow, but it was also a control, and you can't pull a control out of regulated work and hope for the best. So the control moves into the system. Every change goes through an accountable owner, approvals can require a second reviewer on anything touching policy, and permissions are graded by how critical a rule is, so a pricing tolerance and a regulatory threshold aren't governed alike. Every version is retained, so when an auditor asks you to explain a decision from eight months ago, you can.

That is also the answer to the objection nobody voices until late in a deal: that anything prebuilt cannot really be yours. Every approval hierarchy in every company has the same structure—bands, escalation, delegation—and the only thing that was ever yours is the numbers in it and the judgment behind them. So you set your own tiers, your policy document goes in and your rules come out, and you decide how much the machine decides, a boundary you can move as confidence grows. An afternoon of configuration. Not a quarter of code. Everything common, already built. Everything that is yours, still yours.

Building it is easy now; trusting it isn't

In April, I wrote about when to build an agentic solution versus when to buy one. Since then, one part of that argument has changed: UiPath for Coding Agents went generally available last month. Your team can now quickly stand up an agent that reads a claim and drafts an appeal. Building the agent is no longer the hard part. The harder question is how to run it in production and keep it trustworthy as the work changes.

Now, the focus needs to be on trust. Trust in a production system depends on seven factors: agents, automations, integrations, the apps people work in, governance, evaluations, and learning.

Your team can build the first five, but it takes time. In regulated work, you don’t get to stop at 80%, and the cost of getting above that compounds unsustainably. But that said, with enough time and effort it is all buildable, and the tools keep getting better.

However, the last two points are different because they are the result of precedent rather than effort. Evaluation and learning are only as good as the data behind them. In an in-house system, your sample starts empty while ours arrives tuned across deployments and improves with every run. It's a flywheel that has been turning for a while, and it turns again when we deploy. The other issue is that trust decays: every system change, every policy revision, and every new model resets some of it. So the question isn’t whether your team could build this. It’s who keeps it trustworthy in eighteen months.

Proof in production

A solution has to prove itself in the work it runs. These deployments show the results UiPath customers are getting in production:

Healthcare: a U.S. revenue cycle management provider cut its cost per denied claim by 76%
Financial services: a Latin American retail bank took dispute resolution from 97 hours to under five
Manufacturing: a global home appliance manufacturer lifted invoice automation from 10% to between 80% and 90%
Finance and accounting: a global consumer goods manufacturer runs its purchase-to-pay agent at a 91% success rate

What comes next

The results point to an opportunity to bring more of this work into prebuilt solutions.

When the same process keeps turning up across companies with the same steps and the same hard-won judgment, it's a candidate for a complete solution. At FUSION, a bank offered to be first customer for one we haven't built yet: build it with us, then generalize it. Every map is a solution waiting to be built, and the ledger underneath each one is what will tell us which to build next.

It also changes who is in charge. The claims director, the utilization management nurse, and the AP manager stop filing tickets against someone else's software and start setting the rules their processes run on. That came up again and again at FUSION, and it will continue to do so wherever static SaaS shapes a business process.

Your business is going to change again next quarter. The question worth asking is whether your software will find out about it from a ticket.