The KAMM blueprint for automating request fulfillment

Most processes sit somewhere in the middle

Every business process starts with a request and ends with fulfillment. A customer places an order. An employee asks for a laptop. A contractor needs access to a system. An executive wants a report. Something has to happen between the ask and the answer, and in most organizations a person does most of it.

People usually describe a process as either manual or automated. That is too coarse to be useful. In practice there are several distinct steps between an email inbox and a request that completes itself in seconds, and for many processes the right place to stop is one of the steps in the middle.

The Kinetic Automation Maturity Model (KAMM) names six stages and explains how to move a process from one to the next. Every request process in your organization is at one of them today. Knowing which stage each process is at tells you where effort will pay off, and where it won’t.

There is a second reason to care. When the official way to ask for something is a shared inbox and a long wait, people find another way. They keep their own spreadsheets, build small apps on the side, and now ask AI assistants to do work outside any shared process or record. Each workaround solves one person’s problem and leaves the organization with less visibility than before. Moving a process up even one stage gives people a front door that is faster than the workaround, which is the most reliable way to retire it.

This e-book walks through all six stages, what each costs the organization, why processes get stuck, and how to make each transition, with a worked example for every step.

The six stages at a glance

Each stage is written as a short formula. R is the request, U is unstructured handling, A is approval, F is fulfillment by a person, and X is execution by a machine.

Stage	Formula	What happens	Typical time
1. Unstructured	R → U	A request arrives by email or free-text form. A person works out what it means and what to do. The requester sees nothing until it is done.	Weeks
2. Managed	R → F	A structured form, assignment to a team, an SLA with reminders and escalation, and status the requester can check. Fulfillment is still manual.	Days to weeks
3. Mapped	R → A → F	Approval routing is automatic. The fulfillment steps live in a workflow that guides the fulfiller one step at a time.	Days to weeks
Above this line a person decides each step. Below it, the system holds the map of the process.
4. Integrated	R → A → F → X	The fulfiller enters what is needed in one place, and the workflow makes the change in the other systems through an API or database update.	Hours to days
5. Approval only	R → A → X	A person approves when the rules require it. Everything else runs automatically.	Minutes to hours
6. Automatic	R → X	Requests that meet predefined criteria are fulfilled at once, with no human step, at any hour.	Moments

Each move from one stage to the next has its own section below, with the reasons a process might stay where it is and a worked example.

The line between stage 3 and stage 4

The most important boundary in the model sits between stages 3 and 4. Above it, fulfillment depends on a person working out what to do, even if a system reminds them of the steps. Below it, the system has stored the definition of the process and moves through it on its own, asking people only for the decisions it can’t make.

Crossing that line changes the economics. Structuring a process (stages 1 to 2) and mapping it (2 to 3) cut cost and time steadily. Once machines start doing fulfillment work, the cost of each additional request falls sharply, and the biggest single drop in our model comes between stage 4 and stage 5, when the human fulfillment step goes away altogether.

Not every process belongs at stage 6

Complexity, technology and volume all set limits. A process with dozens of variations, each requested twice a year, may never justify full automation. A process that touches a mainframe with no usable interface may stay at stage 3 for years. A request that carries legal risk may always need a person to approve it.

That is fine. The point of KAMM is to move each process as far as is practical and stop there, then do the same for the next one. Across a portfolio, that lowers fulfillment time and cost and gives managers a picture of the work they never had before.

What manual processes really cost

Reasonable people ask whether manual processes cost as much as vendors claim. Start with what a manual process actually consumes.

The first edition of this e-book began from a widely repeated analyst estimate of about $30 to handle one unstructured request, and assigned a lower estimate to each stage after it. Those per-stage figures were our own estimates, not measurements, so this edition leaves them out. The direction is what matters, and it holds in every organization we work with: cost per request falls at each stage, and it falls fastest once people stop doing the fulfillment by hand.

At the scale of a whole organization, an IDC study reported by Entrepreneur put the cost of inefficient processes at 20 to 30 percent of revenue each year. That figure seems high. Even if it is off by a factor of three or five, the cost is large.

Eleven places a manual process costs money

1. Direct time: the labor to complete the request, usually the easiest cost to measure.
2. People involved: everyone who touches the request between submission and completion.
3. Indirect time: the waiting. A lawyer whose laptop has failed can’t bill until the replacement arrives, and that week often costs more than the laptop.
4. Errors: rework, returns of the wrong product, and lost sales when mistakes reach customers.
5. Inaccurate data: records drift out of date, so leaders double-check numbers or decide on bad ones.
6. Finger-pointing: Milton Friedman’s line that when everybody owns something, nobody owns it applies to process steps too.
7. Lack of visibility: nobody knows how long a request type takes or who approved what, which also raises the risk of fraud.
8. Compliance risk: manual work is hard to audit, and in regulated industries that can mean penalties.
9. Siloed information: departments on separate applications wait on each other without knowing the status.
10. Poor employee experience: long waits and lost requests hurt engagement and retention.
11. Poor customer experience: delays and wrong orders or invoices cost sales and loyalty.

Twelve things automation changes

Automating a process removes most of those costs. People spend less time on fulfillment and waiting (1, productivity), make fewer mistakes (2, accuracy) and know who owns each step (3, accountability), which also helps departments work together (4). Staff move to work that needs judgment (5), and customers inside and outside get faster, more accurate results (6). Leaders see metrics and bottlenecks (7) and decide with better data (8). Nobody copies data between systems, which can also cut license costs (9). Processes are easier to change when the organization changes (10), every step is recorded for compliance (11), and volume can grow without headcount growing with it (12).

Ernst & Young frames the same idea as five areas of impact that build on each other as automation matures: fewer workers needed for routine tasks, scaled capacity, greater speed, higher quality and, at the top, new things the organization can do that it couldn’t before. EY also recommends that an automation business case look past net savings, ROI and payback period to four groups of value drivers: the customer (satisfaction, self-service), the employee (productivity, satisfaction), management (risk, compliance, agility, insight) and the corporation (cost, revenue growth, brand reputation).

Why so many processes are still manual

Given the costs and the benefits, why do organizations still run so many processes by hand? Four obstacles come up again and again.

• Integration. Large organizations run a mix of technology: legacy systems, external data sources, portals, scanners, sensors and mobile apps. Connecting a new process to all of it is hard, and the difficulty stalls automation.
• Exceptions. Real processes have exception conditions. Map them all and a simple flowchart starts to look like a plate of spaghetti.
• IT capacity. A typical enterprise runs hundreds of applications. IT teams are stretched across implementations, upgrades, support, security and strategy, and they can’t take on every project request.
• Inertia. When everyone is already busy, “if it isn’t broken, don’t fix it” wins. That is especially true for processes that cross departments, where the coordination doesn’t seem worth the effort.

The answer is to move one process up one stage at a time, rather than attempt full automation in a single large project. Start with structure: drop-down lists in place of free text, defined owners, automatic reminders. Then route requests by type, connect the systems, and remove steps that don’t need to happen. Automation changes what people do as well as the technology, and small, frequent changes are easier on both counts. Quick wins also build the momentum a program needs to survive its first year.

A platform helps by taking on the integration work and letting business teams build their own workflows, so IT is no longer the bottleneck for every change. Today that includes AI. In Kinetic, an AI assistant can generate a form or a draft workflow through MCP from a plain description, and a person reviews it before it goes live.

Stage 1 to stage 2: give the request a structure

Moving a process from unstructured to managed speeds up fulfillment and removes the back-and-forth that frustrates everyone.

What stage 1 looks like

Almost every new process starts at stage 1. In a startup, nearly everything does. In an established organization, stage 1 processes appear whenever something changes: a new product or service, a merger, a new partnership, a reorganization.

The setup is simple. The organization creates a generic web form or just an email address. An employee, customer or supplier types a description of the problem, clicks Submit, and waits, hoping someone will deal with it.

That is a wide-open funnel. An employee who just received new computer equipment might report a damaged item, a missing one, or the wrong items: a monitor and a keyboard when they ordered two monitors. Every kind of issue comes through the same box.

A stage 1 process doesn’t need much technology. Some organizations have quite sophisticated intake: a portal built in Remedy, ServiceNow or another ITSM tool. If all that portal does is collect free text and forward it, the process is still at stage 1.

What goes wrong at stage 1

Stage 1 processes get the job done, eventually. Along the way they frustrate the people asking, the people fulfilling, and the organization paying for both.

Back-and-forth. The employee who got a monitor and a keyboard describes the problem, and the fulfiller replies asking for the order number. The employee sends the shipping number by mistake, so there’s another round. It takes a couple of days, some people give up, and fulfillers have this exchange all day long.

Process knowledge lives in people’s heads. Experienced fulfillers know they need to match the complaint to the order, validate the issue, and send the requester an RMA number with return instructions. At a minimum those steps should be written down so anyone on the team can handle the request. At stage 1 they often aren’t.

No visibility. The requester doesn’t know who is working on the issue, whether anyone is, or when it will be resolved. Management doesn’t know how often this type of issue comes up or how long it takes.

Dropped handoffs. When more than one person is involved, things fall between them. Who tells the requester it’s resolved, the person who received the request or the person it was handed to? It gets worse when the handoff crosses functions, from IT to finance for instance.

Why stage 1 processes exist

Some stage 1 processes should stay that way. Many more would benefit from moving. They usually exist for one of these reasons:

• New processes, where it helps to gain some experience before adding structure.
• Legacy operations, such as support for older products, where the volume doesn’t justify the work.
• Non-core work. A tax agency automates returns and refunds, its core work, but a one-time relief program run under time pressure is far more likely to run on email and manual review.
• Technology laggards without competitive pressure to change.
• Low volume. An auto parts distributor may automate common parts and still handle an order for a 1957 Studebaker Golden Hawk tail light assembly through an inbox.
• Exceptions and customizations to otherwise automated orders.
• No time pressure, where requesters expect to wait and don’t mind.

The potential varies by function. Ernst & Young found that automation potential differs by more than two times across sectors and up to seven times between functions, from finance, where about 80 percent of tasks could be automated, to learning and development, at about 12 percent. EY also found that every sector could transform roughly a third of its work.

What stage 2 looks like

At stage 2, the organization applies structure and management. Instead of an open text box, the requester chooses from a list of predefined services, and each service asks for the specific information it needs.

Back to the wrong-equipment example. The form offers “Incorrect order” as an option. Choose it, and the form asks for the order number, what was expected, and what arrived. The fulfiller receives everything needed to act, and the several rounds of email disappear.

The form checks entries as they are typed. If order numbers always begin with “N” and run seven characters, anything else is flagged before it is submitted. With complete, correct information arriving every time, the organization can set SLAs for each service: incorrect orders resolved within three days, billing errors within four hours.

What the move buys you

• Visibility. Requesters see progress. Managers see volume, resolution time and satisfaction for each request type.
• Reliability. A stage 1 request can be forgotten or dropped in a handoff without anyone noticing for weeks. At stage 2 it has a ticket number, an SLA and visible status.
• Accurate assignment. Requests reach the right team with the right information the first time. Network specialists stop getting mainframe questions.
• Consistency. Everyone resolves the same request type the same way, and wasted steps become visible.
• Time and cost. Fulfillers finish faster and requesters wait less. In our model, cost per request roughly halves.
• Confidence. When requests are handled quickly and consistently, people use the system instead of working around it.

How to make the move

Three things are needed.

Process intelligence tells you which processes to start with and what each needs. Read your last few hundred or thousand unstructured requests and group them by problem: invoiced the wrong amount, shipped the wrong product, delivered the wrong quantity. Then list the information needed to resolve each one: order number, shipping number, items expected, items received. With that, a free-text form becomes a drop-down list of issues, each with its own required fields. An AI model can do the first pass of this sorting on a large export of past requests, with a person checking the groupings.

Process definition comes before any automation. For each request type, decide which team or person handles it, what information they need, how it is resolved, what the requester is told and when, and who must approve it above what threshold (finance approves anything over $100, for example). Automating a poorly defined process only produces bad results faster.

Field-level validation makes sure fulfillers receive data they can use. The form builder should check each field as it is filled in. Phone numbers have ten digits. Order numbers start with an X. If an entry breaks the rule, the form says so and asks again.

With those three in place, pick the processes to move. Volume is the usual guide. Low-volume processes with legal or compliance stakes are also good candidates, because a lost or malformed request costs more than its volume suggests.

Worked example: DoD Form 2875

Stage 1 processes often run on paper. Anyone who works with the U.S. Department of Defense knows DD Form 2875, the System Authorization Access Request, which contractors, service members, civilian employees and other qualified people use to request access to DoD systems. It can be downloaded, filled in, and then faxed, mailed, emailed or handed over.

Each person on a project needs their own form, so a contractor may submit dozens or hundreds for one program. There is no confirmation of receipt, and an answer can take anywhere from a couple of days to several weeks. The form can be misrouted. The approver may hold it. A field may be wrong, such as an account code or a domain that doesn’t exist. Any of these sends the requester back to the start with a new form. Paper has no validation and no status.

At stage 2, the requester fills in the form online. Validation catches errors before submission. The requester gets a confirmation, then sees the status of the request at each step. Approval may still take time, but the requester knows exactly where the request is and who has it.

Kinetic is deployed in DoD customer environments at Impact Levels 4 and 5, with CAC and PIV sign-in for each approver. The DD-2875 automation use case shows how the approvals are routed and recorded once the form is online.

Stage 2 to stage 3: get the process out of the fulfiller’s head

At stage 2 the request is structured, but fulfillment is still entirely manual. At stage 3, the steps are mapped out and moved into a system, which guides the fulfiller and starts to automate parts of the work.

Why stage 2 isn’t enough

At stage 2, every step of fulfillment is still stored in the fulfiller’s memory. They know the process. In effect, the person is the workflow engine.

That works, but it needs a lot of training. Changing the process means telling every fulfiller and hoping they all adjust. Training new people is slow. And when an experienced fulfiller leaves, much of the know-how leaves too.

Visibility is also limited. Stage 2 shows that a request is open and with whom, but not where steps get skipped, where errors happen, or which step is the bottleneck.

Which processes to move

Most organizations have plenty of stage 2 processes that should be at stage 3. The Pareto principle applies: roughly 20 percent of request types account for about 80 percent of requests. Those repetitive, high-volume types are the prime candidates.

Low-volume request types without compliance implications can usually stay at stage 2. Getting knowledge out of someone’s head and into a process definition takes real work. For a task done twice a month, it probably isn’t worth it.

What stage 3 looks like

At stage 3 the whole process is broken into discrete steps. People still do the work, but the system guides them through it one step at a time, and at each step it shows only the information needed for that step. That last point matters more than it sounds. When fulfillers have to dig through details that belong to other steps, they make mistakes.

Take an order for a new phone. At the first step, the fulfiller needs to know who approved the request and when. At the second, they need the model and color to pull from inventory, but not the approval details. At the third, they need the list of apps to install, and nothing from the first two steps.

What the move buys you

• Lower cost. In our model, mapping the process takes roughly another third off the cost per request, mostly through fewer manual steps and more consistent work.
• Room to improve the process. Breaking fulfillment into steps exposes tasks to drop, combine or redesign.
• Visibility at the step level. You can see bottlenecks, measure performance on each step, and find where errors start.
• Easier training and change. New fulfillers get up to speed faster, and changing the process means changing the definition rather than retraining everyone.
• Fewer errors. Careful people still forget things. When the system manages the task flow, more requests are done right the first time.
• Scale. The same team handles more requests, with less rework for fulfillers and faster results for requesters.

How to make the move

This transition takes a lot of whiteboard time. Once you’ve chosen the processes, pull the recent stage 2 tickets for each request type and read them closely. What did the fulfillers actually do? What notes did they leave? Bring in the process owners. Break each fulfillment into discrete steps, lay them out, and look for improvements.

Then build it in a workflow system that guides fulfillers through the steps and hands them the right information at each one. No software does the whiteboard work for you, but once it’s done the build goes quickly. In Kinetic, an AI assistant connected through MCP can turn the whiteboard map into a draft workflow and the forms that go with it, and the team reviews and adjusts it before it runs.

Worked example: ordering a phone

At stage 2, an employee’s request for a new or replacement iPhone goes to someone in IT, who takes a phone from inventory, loads the required software and delivers it. But the fulfiller’s first task is to check whether the request was approved.

Suppose IT gets 20 to 100 iPhone requests a month and decides to improve the process. At the whiteboard, it’s clear fulfillers can’t start until they confirm approval. So the first improvement is to route the request to the employee’s manager before IT ever sees it, which saves IT time on every phone request from then on.

At stage 2, the requester picked a few basic options, such as the model. At stage 3, the form offers drop-down lists for model, carrier, color, case and specific apps, and each choice is passed to the fulfiller at the step where it’s needed.

Some parts of the process start to automate at stage 3 as well. A fulfiller at stage 2 might know that when stock drops to five phones, it’s time to order ten more. The whiteboard session brings that rule into the open, and the system now places the order when inventory reaches the set level.

Stage 3 to stage 4: let the system make the change

The move from stage 3 to stage 4 is one of the biggest in the model, because it crosses the line. Above it, a person decides how to fulfill. Below it, the system holds the definition of the process and moves through it itself.

The frustration at stage 3: the swivel chair

At stage 3 the system manages the process, but a person still performs each task. A typical step looks like this: check off the task in the ticketing system, log into the finance system to update a record, then go back to the ticketing system to close the ticket.

At stage 4, closing the ticket updates the finance record automatically, and nobody swivels between screens.

When to leave a process at stage 3

Most mapped processes should move on. There are two common exceptions: a process with steps that are very hard to automate, where low volume means the effort won’t pay back, and a process that records its result in a legacy platform with no practical interface, such as an old mainframe application.

What stage 4 looks like

At stage 3, a fulfiller might work a ticket in the workflow tool, log into Salesforce to apply a discount code, and return to close the ticket. At stage 4, the systems are connected and the discount step is part of the workflow. When the fulfiller closes the ticket, the workflow updates the record in Salesforce. Tasks that used to be assigned to people are performed through an API.

The flow at stage 4 runs from request, to approval, to human fulfillment, to machine execution:

1. A person makes a request.
2. The workflow sends it to the right person for approval.
3. Once it’s approved, a fulfiller gathers the information needed, enters it in the workflow, and saves.
4. The system does the execution.

Consider adding a new hire to the executive group in Active Directory, which grants a set of security privileges. Once approved, the request goes to a fulfiller, who selects the relevant Active Directory attributes and saves. The moment they do, the workflow calls Active Directory, adds the person to the group, and sends a notification. A person still adds something before the request can move on. That is the defining feature of stage 4.

APIs are what make stages 4 to 6 possible

Every system that exposes an API is a system that can take part in fulfillment. The more of your systems do, the more of each process the workflow can complete. Kinetic connects to common systems of record out of the box, and the rule is simple: if a system has an OpenAPI spec, Kinetic can connect to it. It also reaches systems inside your own network, so an on-premises application isn’t automatically a reason to stop at stage 3.

Approvals can be handled by the system too. An approval step can be assigned to a rule rather than a person, with people involved only for the exceptions. An AI model can sit in that step as well, for instance to summarize the request for the approver or flag one that looks unusual. The workflow decides what happens next, and every step runs the same way each time.

What the move buys you

The two biggest gains are time and cost. Moving to stage 4 typically cuts completion time from weeks to days, or from days to hours, and in our model it halves the cost per request again. A computer doesn’t wait until it has a free moment, and it completes most add, change and delete tasks almost instantly.

Deloitte described an insurer where handling 500 premium advice notes used to take two days. After automation, it took 30 minutes.

Beyond time and money:

• The swivel chair is gone. People are more productive and less frustrated, and errors from re-keying data disappear.
• Visibility. You can see where each request is, how long each step takes, and where bottlenecks form.
• Scale without headcount. Placing thousands of orders by hand takes a team. A system places them quickly.
• Less vendor lock-in. If your workflows call a system such as BambooHR or BMC Remedy through a known set of tasks, evaluating a replacement like Workday or ServiceNow comes down to testing those tasks against it. You can even run both for a while, opening a ticket in Remedy and in ServiceNow for each request, and switch off the old connection when you’re satisfied. Nobody at the front end notices.
• Lower training and documentation costs. When SAP ships a new version, people who work directly in SAP may need retraining on 10 or 20 processes. People who fill out forms in a front end and click Save don’t.
• Easier change. Inventory, pricing or shipping practices can change on the back end without changing how anyone at the front end works.
• License costs can drop. Suppose hundreds of requests a month are handled by ten people, each with a license to the target system. Move 90 percent of those requests to stage 4, where the work happens through an API, and you may need one or two licenses instead of ten.

The risks at stage 4 are small

People do gradually lose the skill to do the work by hand. But knowledge is more likely to walk out the door at stage 3, where it still lives in people, than at stage 4, where the steps are documented in the system. Oversight improves too, because every task the system completes leaves a record.

The real risk is a back-end upgrade that renames “severity” to “priority” or adds a required field. Because the process is documented and visible, the break is easy to find, and you fix it once in the workflow.

Worked example: configuring a laptop

A new employee needs a laptop set up with the software for their role. At stage 3, a technician takes a laptop from inventory, looks up the software list for the role, and installs and configures each application by hand.

At stage 4, the technician plugs the laptop in and connects it to the network. Based on the role selected on the request, the workflow installs and configures everything required.

How Kinetic handles the move

At stage 4, the systems of record matter most. Kinetic sits across them and runs the tasks between them, whatever back-end systems you use. You keep the systems you bought and build the process on top, instead of replacing them.

Kinetic supports two patterns:

• Fulfillers work in Kinetic. The fulfillment team does all its work in Kinetic, which updates the back-end systems and completes the tasks there.
• Kinetic hands off to a system with a good workflow of its own. The requester asks in Kinetic, which opens a ticket in SAP, ServiceNow or another fulfillment system. When that ticket closes, the system notifies Kinetic, which runs the next step or tells the requester the work is done.

Either way, people work in one simple interface instead of several hard ones. Nobody has ever praised the SAP interface. A retailer could give store employees a simple mobile screen for the few SAP tasks they actually perform, showing only the fields each task needs. And when a system of record changes, the fix is made once in Kinetic, or the API connection is swapped, without rebuilding the processes that use it.

Stage 4 to stage 5: only the approval stays human

Time and cost fall at every stage, but the largest single drop in our model comes when a process moves from stage 4 to stage 5. Typical fulfillment time goes from hours or days to minutes or hours. Not every stage 4 process can make the move. For those that can, replacing human fulfillment with machine execution changes the economics of the request.

When to leave a process at stage 4

• Complexity. A process with many variations, each a low-volume version of a common request, may be too complex to codify. Automating every variant isn’t worth it.
• Several systems, partly reachable. The fulfiller may have to work in several back-end systems, only some of which can be automated. That’s common when one of them is a legacy platform.
• Several fulfillers. A process that passes through a chain of people, each adding something, may be too complex to automate fully.
• High-touch work. Some steps involve human interaction that doesn’t reduce to data, such as an interview. Many HR processes fall here: hiring, promotions, performance reviews and disciplinary actions. Other HR processes, like scheduling vacation, move easily to stage 5 or 6.

Software changes are another example. The process for collecting and prioritizing enhancement requests can be automated, but a developer still writes, reviews and commits the change, even with an AI assistant helping with the code. Closing the books each quarter is a third. The steps repeat every three months, but there’s usually a wrinkle that needs a person to gather or check information.

What stage 5 looks like

At stage 5 the flow runs from request to approval to execution. Someone makes a request. Someone else approves it. The system does the rest, and there is no fulfiller.

How to make the move

Stage 5 comes from watching patterns over time. This kind of request always gets this fulfillment; that kind always gets that one. Once you can see the pattern, you can write it down as a rule and remove the person who was applying it.

Take a request for more voicemail storage. At stage 4, the employee asks, a manager approves, and a fulfiller notes that the change needs to be made on Cisco server 12, enters the details and saves. The workflow does the rest.

Or a request to join a reporting group for a database. A fulfiller picks the right three of five data warehouses, saves, and the three are updated behind the scenes. A person is deciding which three.

Watch these for a few months and the pattern is plain. Voicemail changes always go to server 12. Requests from finance always use the same three warehouses. Those decisions become rules in the workflow, and the request goes straight from approval to execution. The workflow history in Kinetic is the evidence for this: it records which choices fulfillers made for which requests, and an AI model can help find the repeating ones for a person to confirm.

What the move buys you

Cost and time. At stage 4, people still collect information and enter it, either directly into a system of record or into a workflow that updates it. People are the expensive and slow part. At stage 5 the only human action is the approval. After that, the system takes over and does all the work.

The time savings come from the queue. At stage 4, an approved request sits in the fulfiller’s queue behind 30 other things and may not be touched for two days, while the requester waits. At stage 5 there is no fulfiller queue. The request is fulfilled the moment it’s approved. The requester gets their phone or laptop sooner and loses less working time, a saving that doesn’t show up in the cost per request at all.

New services. Running back-end systems through one workflow layer shows how the pieces fit together. Giving someone 10 GB more email storage stops being a chore. For a managed service provider or systems integrator, it becomes a service to sell. Inside an enterprise, it makes accurate department chargebacks possible.

Business rules where there were none. Many systems, cloud platforms in particular, assume anyone with administrator rights may do almost anything, immediately. That’s fast, and risky. At stage 5 the workflow puts business rules and an approval step in front of those actions. It slows things down slightly and lowers the risk considerably.

Customer experience. Satisfaction comes from speed and visibility together. Keep requesters informed (“You’ll receive your item on Thursday. Here’s the tracking number.”) and ask how it went once it arrives. Knowing where things stand gives people confidence the system is working for them.

What stage 5 means for MSPs and integrators

Because the back end is automated, service providers can offer standard add-ons at a good margin: an extra data backup, another voice line, more mailbox space, each with its safeguards built into the process. Lower service cost matters, but new services with full visibility into each request are where providers find growth. The managed service provider page shows how providers use Kinetic for this.

Stage 5 to stage 6: remove the approval where it’s safe

Moving from stage 5 to stage 6 removes people from the process completely. The request, which may or may not come from a person, goes straight to execution. Not every stage 5 process should make this move. For those that can, fulfillment time and cost approach zero.

The gain is bigger than internal savings. An organization that can fulfill a class of requests instantly can compete on speed, accuracy and cost in ways that are hard to copy.

When to keep a process at stage 5

The main reason is that you always want a person to approve. That can be for legal, regulatory, fraud prevention, security or policy reasons. Organizations keep high-value requests at stage 5, and more generally any request where the cost of a mistake is higher than the cost of a review.

What stage 6 looks like

At stage 6 the system approves the request by rule, without asking anyone. A system administrator making a change in AWS is a simple case: one person is the requester, the approver and the fulfiller. They ask, and it’s done.

There may still be a step for the requester, such as acknowledging the risks or agreeing to terms, as a legal or policy requirement. But there’s no separate approver.

Amazon is the familiar example of an organization that has spent decades shortening the time from order to delivery. Most of its fulfillment is probably at stage 4: largely automated, with people still packing boxes, loading trucks and delivering packages. Every one of those human steps it automates moves the order closer to stage 6.

What the move buys you

If a type of request is always approved, asking for approval wastes time. Approvers are busy and may not see the request for hours. Stage 6 removes that wait, turning hours into minutes and minutes into moments. In our model it also takes most of the remaining cost out of each request.

Stage 6 also suits processes where time is the variable that matters most. When a production line stops because a part failed in a key machine, the cost of approval is beside the point. What matters is getting the part to the plant as fast as possible and showing the requester exactly where it is.

Stage 6 also lets processes start without a person at all. A scheduled or event-based trigger can act as the requester. Time-based triggers enforce a password change every 90 days or run the full data warehouse backup every Sunday morning. Event-based triggers fire when a server goes offline, a new employee is hired or someone leaves. Today, an AI agent can be the requester too. Through MCP, an agent can create a record or start a workflow within the permissions of the person it acts for, and the workflow runs the same way it would for anyone else. Native agent work exchange, where agents pick up and hand off work as participants in the process, is in development.

How to manage the risk

Without an approval step, there is some risk of fraud or misuse. Two methods keep it small without slowing anything down.

Execute now, audit after. The request runs immediately, and an audit step reviews it afterward. If something wasn’t legitimate, the action can be reversed. Things get done quickly, and there’s still a way to put them right.

Qualify the request. Add conditions that decide when approval can be skipped. For example, if the value is under $100 and the person hasn’t made a similar request in the past 30 days, skip approval and keep going.

Even if a few of those requests turn out to be illegitimate, the savings across all the legitimate ones usually outweigh the small losses. Online retailers work this way when they refund a defective item and tell the customer to keep it. With checks for abuse, that costs less than return shipping and handling.

Worked example: voicemail space

Anyone who has seen the Cisco call center administration console knows how long it takes to learn. A common request is simple: an employee going on vacation needs ten more minutes of voicemail space.

• Stage 4. The employee requests it. A trained technician logs into the call center console, finds the employee’s account, and adds the ten minutes.
• Stage 5. The employee requests it through the portal. Someone approves it, and the workflow makes the change in the call center system.
• Stage 6. If the request meets the predefined criteria, the system makes the change immediately. No person is involved, and requests can be made and fulfilled at any hour of any day.

What AI does and does not do here

AI speeds up building at every stage of this model. An assistant connected to Kinetic through MCP can generate forms, portals and workflows from a description, and it can create records and start workflows within the signed-in user’s permissions. AI models can also act as steps inside a workflow, for example to sort past requests, summarize a request for an approver or spot repeating decisions.

AI does not run the process. Once a workflow is live, Kinetic executes it the same way every time: the same steps, the same rules, the same approvals. People decide which requests need approval, and people review what AI builds before it goes live. You choose the model, whether that’s Anthropic Claude, Amazon Bedrock, Azure OpenAI or a model running on your own hardware.

Putting the model to work

The six stages are a way to have a specific conversation about each process: where it is, where it should stop, and what the next step requires. Figure 5 summarizes each move.

A practical way to start is to list your twenty highest-volume request types, mark the stage each is at today, and pick the one where a single move would remove the most waiting. Most organizations find their first candidates at stage 1 or 2, where the work is mostly about structure and a few weeks of effort makes a visible difference to the people asking.

Few organizations have got this far. In a McKinsey survey, most respondents said at least a quarter of their organization’s tasks could be automated within five years, but fewer than 20 percent said their organization had already scaled automation across several parts of the business. The gap is rarely the technology. It’s the habit of moving one process, one stage, at a time.

To find out which stage your own processes are at, book a working session. In two hours we map one process with you and send a written plan for moving it up a stage.

What you can build next

Once a few request processes are running on Kinetic, the same forms, workflows and connections carry over to the next ones.

• Access request automation applies the stage 2 to stage 5 pattern to system access across your organization, with approvals and provisioning in one workflow.
• The workflow layer explains how Kinetic runs the processes described here, how AI builds them, and how they connect to the systems you already own.

Sources

Research figures in this e-book were cited in its 2024 edition and are attributed as they appeared there.

• IDC, as reported by Entrepreneur: inefficiency costs companies 20 to 30 percent of revenue each year.
• Ernst & Young: automation potential across sectors and functions; the five areas of automation impact; value drivers for an automation business case.
• Deloitte: an insurer’s handling of 500 premium advice notes, reduced from two days to 30 minutes.
• McKinsey: survey on automation potential and the share of organizations that have scaled automation.