Efficiency matters most where work passes between people and systems. Manual processes, bottlenecks, and fragmented workflows can hinder productivity, increase costs, and impact employee satisfaction. Oblytech’s Process Optimization & Automation services use ServiceNow to streamline your operations, automate repetitive tasks, and free your team to focus on high-value activities.
Automation can significantly reduce labor costs, improve resource utilization, and eliminate the need for costly manual interventions.
Streamlined processes and self-service portals provide a better experience for your employees and customers.
Gain real-time visibility into your workflows and processes, enabling you to track progress, identify bottlenecks, and make data-driven decisions.
Automated workflows can easily scale to handle increasing volumes of requests and transactions, ensuring your processes can support your business growth.
Automated workflows eliminate manual tasks, reducing errors and improving processing times, leading to increased productivity and cost savings.
Automation requests tend to arrive as a list. Every department has a process that is slow, manual or annoying, and every one of them wants a workflow. The difficulty is that a workflow copies whatever the process does. If the process routes requests through three approvers who never look at them, the workflow will route them through the same three approvers, faster, and the backlog will grow at the new speed. Process optimization and automation, as a consulting subject, is about deciding which processes deserve automation, what they should look like before they are automated, and which ones should be left alone.
This page is for the owner of an operational process, or the platform lead who has been asked to deliver automation for several of them, and who needs a way to choose. It sets out a method for sorting candidates, the outputs a useful engagement should produce, and the points at which automation is the wrong answer.
A candidate process is worth examining when it has a clear trigger, a clear end, and a recognizable cost when it goes wrong. Those three properties matter more than volume or irritation, because a high-volume process with unclear ownership will resist automation however many workflows are built for it. The table below separates the situations in which automation usually helps from those in which it usually does not, and the first step each situation needs.
| Situation in the process | Automation usually helps? | Step that should come first |
|---|---|---|
| Steps are stable, the owner is named, and the same decision is made each time | Yes | Confirm the decision rules in writing with the owner |
| Steps vary by requester and nobody can describe the usual path | Not yet | Map the real paths by sampling completed work |
| Approvals exist mainly to satisfy a historical control that no longer applies | Only after the control is reviewed | A decision on whether the approval is still required |
| Data needed for the decision is held in several places and disagrees | Only for the part that is reliable | A data source decision, so that the workflow reads from one place |
| Work is repeated because people cannot see the status of earlier steps | Often yes | A status view that is agreed and visible to requesters |
The table describes tendencies. A process can sit in several rows at once, and the right answer is often a partial one: automate the stable part, and redesign the rest before anyone builds for it.
Optimization work that jumps straight to a workflow build skips the stage where most of the value sits. The outputs a useful engagement produces before build are concrete, and they are what the buyer should ask to see.
A target process describes who does what, in what order, with what information, and what happens when the information is missing. The workflow is one way of implementing that description. Designing the target first means the automation can be judged against it. A workflow built without a target often does exactly what it was asked to do and still fails the people who use it, because nobody agreed what success looked like.
The target should also say what does not change. Requesters often assume automation will remove approvals, reduce communication or shorten every step. Sometimes it does. Sometimes the right design keeps a human decision in place and removes only the waiting around it. Making that explicit avoids a common argument at go-live, when a stakeholder discovers that the change they assumed was included was never planned.
The payback of automation is harder to show than vendors suggest, mostly because the baseline was never measured. The first question to ask any provider is what will be measured before the change and after it, and who will own the comparison. Measures that rely on the platform’s own reports are useful, but they should be checked against a sample of records read by a person, because a report can show a fast cycle time for requests that were closed without being resolved.
A common mistake is to measure the workflow instead of the outcome. Counting how many tasks a workflow completed says little about whether the people who raised them received what they needed sooner. A short set of questions sent to requesters before and after the change, asked in the same words both times, captures that outcome cheaply and gives a fairer comparison than platform reports alone.
It is also worth watching for work that moves rather than disappears. Automation sometimes shifts effort from the requester to a reviewer, or from the process owner to the person who handles the exceptions the workflow cannot manage. The overall effort may be lower, but it lands on a different team, and that team should be part of the design.
Processes with frequent judgment calls, low volume and high consequence are often better kept manual, with better information provided to the person making the decision. Automating them can create a false sense of control.
Usually a partial one. The branches that everyone agrees on can be automated first. The contested branches need a decision from the owner before anyone builds them.
Process automation changes how an existing business process runs on the platform. Application development creates new capability that did not exist before. The governance requirements differ, and the two should be planned separately.
The decision table, the owner for each decision, the exceptions and their handling, and the measure used to judge the change. Without those, the next person to change the workflow will not know which behavior is intended.
A first conversation is most useful when it starts with a short list of candidate processes, each described by the trigger, the outcome and the person who owns it. Add a note on where the process currently fails, in the words of the people who experience the failure. The number of processes examined, the number of decision owners involved and the amount of current-state mapping needed before any design can start all set the size of the work.
The related pages show how this route connects to the rest of the platform. The workflow data and context design page covers the meaning, ownership and evidence that should travel with a workflow, and the low-code governance and citizen development page covers guardrails for people close to a business process who build or change workflows within an agreed platform boundary. The integrations and workflow orchestration page is a natural next read if the process crosses into other systems.
If you have a process in mind and want to test whether it is ready for automation, discuss your process candidates with OBLYTECH, and bring the trigger, the outcome and the owner for each so the question of automation or redesign can be put clearly.
A ServiceNow process optimization review is a sequence of decisions, not a build. It chooses one process, confirms that the process has a stable decision at its centre, and agrees what success looks like before anyone configures anything. The review may end early, and if the process needs redesign outside the platform first, that is a good result.
The first step is a walk-through of recent completed records with the person who closes them. The aim is to see which steps happen every time and which happen only when someone remembers. In most implementations the task and approval records already show where items wait and which group holds them longest, which is a faster starting point than a workshop.
The second step is a go or no-go on the decision rules. If the process owner cannot write the rules down and sign them, stop there. That outcome is useful, because the problem is a policy question that no workflow will answer. Teams that push on to a build at this point tend to build the same flow twice, once when the rules are argued and again when the first real exception arrives.
A go decision still faces three stop conditions in the readiness check:
Only branches that pass go into the first release. Branches that need a person’s decision are routed to that person rather than coded around, and deferred branches stay on a visible list with an owner. The data each branch reads is its own design task, covered on the workflow data and context design page.
Before configuration starts, the build team should walk the target path back to the process owner, including the failure path where information is missing or an approver is absent. After go-live, compare the baseline with the same measure after a full cycle rather than after the first week, because early results mostly reflect people learning the new route.
If the walk-through shows the platform itself is not ready to carry new automation, review the instance first. A ServiceNow health check and audit separates platform problems from process problems. Whether the next step is a one-off review or ongoing support is covered in this comparison of consulting and managed support.
Guides from the Oblytech ServiceNow library that explain the practice behind this page.