Find the Work Software Should Take Over

Task

Identify which delivery steps can be automated, templatized, or made self-serve.

Summary

Map the repeated workflow and identify what can be automated, templatized, guided, or made self-serve.

Turn a Repeatable Service Workflow Into Product Capabilities

Task ID: S3-01

Building software too early often preserves the worst parts of a service in code. This article explains how to map one real delivery workflow, decide which steps should be removed, templatized, assisted, automated, or made self-serve, and convert the result into a ranked product backlog supported by evidence, controls, and practical measures.

A design partner buys the new product. Within days, the founder is collecting missing information, cleaning customer data, configuring the account, interpreting unusual cases, preparing outputs, explaining results, and answering questions.

The sale is described as product revenue, but the work still behaves like a custom service.

That situation does not mean the product has failed. It means the company has not yet decided which parts of delivery belong in the product, which should remain human-led, and which should disappear altogether.

The operating principle is simple:

Do not automate a service as one large block. Break the real workflow into steps, then give each step the lightest dependable treatment that produces the required customer result.

That treatment may be removal, a reusable template, software-assisted work, rules-based automation, guided self-service, or continued human judgment. The objective is not to maximize the amount of automation. It is to reduce avoidable labour and variation without weakening the result, trust, usability, or economics of the product.

Executive summary

This work should begin only after the company has learned enough from actual customer delivery to describe the customer, problem, expected result, normal scope, and recurring workflow. Otherwise, the team risks automating assumptions, exceptional cases, or unnecessary work.

Research on automation increasingly evaluates tasks rather than whole jobs or processes. The International Labour Organization’s 2025 exposure index, for example, combines task-level data, expert review, and model-assisted assessment, while concluding that transformation of work is generally more likely than complete replacement. Research from the Organisation for Economic Co-operation and Development reaches a similar practical conclusion: even work considered highly exposed to automation usually contains a mixture of replicable tasks and human capabilities.

The required evidence is an automation map that connects observed service steps to proposed product capabilities. Each row should show the customer result, inputs, current work, frequency, time, variation, exceptions, judgment, risk, proposed treatment, required product capability, and evidence behind the recommendation.

The primary measure, automatable workflow percentage, should be calculated using labour time rather than a simple count of steps. A thirty-second confirmation email and a two-hour analysis should not carry equal weight. The company should also distinguish:

from:

Neither percentage is a universal target. Appropriate levels depend on the stakes of the work, the stability of inputs and rules, customer capability, exception frequency, regulatory obligations, price, and the cost of an incorrect result.

The output should be a ranked backlog, not a declaration that every repeatable step must become software. The best first candidates normally combine high frequency, meaningful customer or staff friction, stable inputs, predictable outputs, low failure severity, and measurable success.

Map the work customers actually experience

The starting point is not a feature list. It is one complete customer journey, from the moment a sale is accepted until the customer receives the promised result and can continue without unusual support.

A useful map includes both visible and invisible work:

• what the customer is asked to do;
• what sales promised;
• what employees perform;
• what software already performs;
• what information moves between systems;
• where work waits;
• where errors or rework occur;
• where senior judgment is required;
• where the customer asks for help.

Service blueprinting was developed to make these interdependencies visible. It places the customer’s experience beside front-stage interactions, back-stage work, support processes, and technology. This prevents a common error: optimizing an internal task while making the customer’s experience slower or more difficult.

Observe completed cases, not the official procedure

Written procedures often describe the intended process. Product decisions need the process that people actually follow.

Review a representative group of completed customer cases and reconstruct the sequence from evidence such as:

• project records and checklists;
• product and application logs;
• customer emails and support conversations;
• call recordings;
• working documents and spreadsheets;
• handoff records;
• elapsed time between events;
• corrections, approvals, and escalations.

Where enough digital event data exists, process-mining methods can reveal recurring routes, loops, variations, and exceptions that interviews miss. Research on combining process mining with robotic process automation finds that such logs can help identify candidate routines, but also warns that data collection and preprocessing remain substantial limitations. An elegant map generated from incomplete events can be less useful than a carefully observed sample of real cases.

For every step, separate active labour time from elapsed time. A task may require only five minutes of work but leave the customer waiting for two days because it sits in a queue. Product capabilities may therefore create value in different ways:

• removing labour;
• reducing waiting;
• preventing errors;
• making status visible;
• eliminating a handoff;
• allowing the customer to proceed at a convenient time;
• moving a decision to the point where the necessary information is available.

Separate the normal path from exceptions

A product should first handle a valuable, frequent, and coherent path through the work. It does not have to absorb every historical variation.

For each case, mark whether a step was:

• part of the standard path;
• an optional module;
• caused by missing or invalid information;
• required by a particular customer segment;
• a genuine expert exception;
• created by an internal defect or unclear instruction;
• performed only because an old tool could not support a better process.

This distinction matters because exception frequency is often understated. Employees become skilled at quietly correcting poor inputs, reconciling contradictions, and adapting outputs. That invisible work may make a proposed automation appear more reliable than it is.

It also prevents the team from treating every variation as a product requirement. Some variations should become configurable modules. Some should remain paid specialist work. Others should be excluded from the standalone product.

Research on service standardization and modularization supports this separation of a reusable core from configurable parts. An exploratory professional-services case found that clearer modules and standard procedures reduced complexity, shortened setup, supported clearer pricing, and made the service easier to explain. Because it is a single-company case, it is evidence of a useful method rather than proof that the same design will work in every market.

Choose the right treatment for each step

Automation is only one possible treatment. In many early products, a template or assisted workflow creates value sooner, costs less to build, and exposes exceptions that the company needs to understand before committing them to code.

Remove before automating

Ask first whether the step should exist.

Typical removal candidates include duplicate data entry, unnecessary status meetings, repeated formatting, approvals that do not change decisions, and rework caused by unclear intake requirements. Automating such work makes the waste faster and more permanent.

A good test is:

If the company were designing this delivery process today with no legacy tools or habits, would this step still be necessary to create the customer’s result or control a material risk?

If not, remove or redesign it before discussing product capabilities.

Templatize stable structures

A template is appropriate when the sequence or output format repeats but the content still requires judgment.

Examples include:

• intake questionnaires;
• diagnostic guides;
• decision checklists;
• report structures;
• calculation workbooks;
• review criteria;
• communication sequences;
• onboarding plans;
• implementation configurations.

A useful template does more than standardize appearance. It defines required inputs, valid choices, completion criteria, owners, and escalation conditions.

Templates can also reveal whether the process is ready for software. When employees repeatedly overwrite sections, add side calculations, or bypass fields, they are producing evidence about missing rules and important exceptions.

Assist before fully automating uncertain knowledge work

Assistance is often the best intermediate product capability. Software can retrieve information, prepare a draft, classify an input, propose a recommendation, or highlight inconsistencies while an employee remains responsible for the result.

A study of 5,179 customer-support agents found that an artificial-intelligence assistant increased issues resolved per hour by 14% on average, with a 34% improvement among novice and lower-skilled workers and little benefit for the most experienced group. The results suggest that assistance can help distribute established practices, but its effect varies substantially by user and task.

A field experiment involving 758 consultants likewise found large gains in speed and assessed quality for tasks inside the tested technology’s capabilities, but poorer results on tasks outside that boundary. The researchers called this a “jagged” frontier: adjacent-looking tasks can have very different automation suitability. The business implication is that capability must be tested step by step, not inferred from an impressive general demonstration.

For assisted work, record whether employees accept, edit, reject, or override each recommendation. Those actions reveal where the software is reliable, where training is needed, and where judgment remains indispensable.

Automate stable, observable decisions

A strong automation candidate usually has most of these characteristics:

• meaningful frequency or labour consumption;
• structured and available inputs;
• explicit rules or a demonstrably reliable model;
• a clear start and finish;
• objectively testable output;
• limited and recognizable variants;
• low or controlled failure severity;
• a practical rollback or correction route;
• data that can be logged;
• an owner responsible for performance.

Examples may include validating required fields, transforming file formats, checking values against known rules, creating standard records, calculating deterministic outputs, routing work, scheduling notifications, and producing status updates.

A step is weaker when employees cannot explain the decision rule, required information arrives through informal conversation, cases frequently conflict, or a plausible-looking wrong answer would be difficult to detect.

Make work self-serve only when the customer can succeed

Self-service is not simply employee automation with the interface turned toward the customer.

The customer must be able to:

1. understand what the product is asking;
2. obtain and provide the required information;
3. correct input errors;
4. make choices without hidden expertise;
5. understand progress and completion;
6. recognize whether the result is credible;
7. recover from a mistake or obtain timely help.

An open study of 182 knowledge workers assessed business self-service through four dimensions: functionality, security, design, and customization. Although limited to one organizational setting, those dimensions provide a useful warning against measuring self-service only by whether an employee was removed from the transaction.

If customers regularly abandon the process, contact support, submit unusable information, or complete the workflow without reaching value, the company has transferred labour rather than designed dependable self-service.

Build the automation map and ranked backlog

The automation map should make it possible to trace each proposed feature to repeated customer work and a measurable business result.

A practical map contains the following fields:

The relationship from service work to product capability can be summarized as follows:

flowchart TD
    A[Observe completed customer workflows] --> B{Does the step add customer value or control material risk?}
    B -->|No| C[Remove or redesign it]
    B -->|Yes| D{Are inputs, rules, and outputs stable?}
    D -->|Yes| E{Can failures be detected and corrected safely?}
    E -->|Yes| F{Can the customer complete it reliably?}
    F -->|Yes| G[Build guided self-service]
    F -->|No| H[Automate for internal delivery]
    E -->|No| I[Template or assist with human review]
    D -->|No| J{Can recurring judgment be guided?}
    J -->|Yes| I
    J -->|No| K[Keep human-led and record exceptions]
    G --> L[Pilot and measure]
    H --> L
    I --> L
    K --> L
    L --> M[Rank the next product capabilities]

Text description: observe real workflows, remove non-value work, test stability and recoverability, decide whether the customer or an employee should operate the capability, retain human judgment where necessary, and rank further work using pilot evidence.

Rank opportunities by value, feasibility, and risk

A backlog should not be ranked by enthusiasm, technical novelty, or the number of customers who have casually requested a feature.

A practical scoring model is:

The factors can be measured directly where data exists and scored on a consistent scale where it does not. The score is a decision aid, not an objective truth. Keep the underlying evidence visible so that a high score cannot conceal weak assumptions.

A sensible first backlog often favours:

1. intake validation and collection of missing information;
2. repeated transformations, calculations, and record creation;
3. status communication and routine scheduling;
4. reusable configuration and output templates;
5. employee assistance for preparation and review;
6. guided customer setup;
7. complex judgment automation only after the earlier capabilities generate reliable data.

The team should also consider dependency value. A capability that standardizes customer identifiers, input formats, or event logging may not create the largest immediate labour saving, but it may enable several later features. Conversely, a large automation opportunity that depends on six fragile integrations may not belong near the top.

Pilot one bounded capability

The first test should normally address one coherent and measurable section of the workflow, not the entire end-to-end service.

For a demo-led sale or design-partner conversion, agree in advance on:

• the cases included and excluded;
• the old and new workflow;
• the customer’s expected result;
• which actions remain manual;
• what counts as successful completion;
• how exceptions will be handled;
• which data will be collected;
• who can stop or reverse the pilot.

Run the old and proposed processes in parallel where failure would be costly. Review every intervention rather than celebrating that the “happy path” worked in a demonstration.

The main learning is often not whether the feature can work. It is whether it can work repeatedly without hidden founder rescue, customer confusion, or unacceptable support.

Measure the work that actually disappeared

Automatable workflow percentage is useful only when its numerator and denominator are explicit.

Use time-weighted measures

A step-count calculation can produce misleading results. Automating eight tiny notifications while leaving two large analytical tasks unchanged may produce an 80% step-automation claim with almost no economic effect.

Use baseline active human minutes:

Calculate it for a defined customer segment, use case, and delivery period. Do not combine unlike workflows merely to obtain a larger percentage.

Then report what reached production:

This measure should include rescue work, quality review, exception handling, maintenance attributable to delivery, and support generated by the new capability. Otherwise, labour has merely moved to a less visible place.

Pair efficiency with customer and control measures

No automation measure should stand alone. A useful scorecard includes:

For artificial-intelligence-based capabilities, the National Institute of Standards and Technology recommends documenting human oversight, system overrides, errors and complaints, response times, adjudication activities, exceptions, escalations, and accountable go or no-go decisions. These are also sound operational controls for other consequential automation.

Treat the target as a working hypothesis

There is no defensible universal percentage of service delivery that should be automated.

A low percentage may be appropriate when the product supports high-stakes decisions, unusual customer environments, sensitive information, negotiation, or accountable professional judgment. A much higher percentage may be viable for stable data transformations, routine scheduling, deterministic calculations, and standardized transactions.

The useful question is not:

How can we increase the automation percentage?

It is:

Which remaining human work creates differentiated value, and which remaining human work exists because the product is incomplete?

That distinction protects the company from removing the expertise customers are paying for while preserving clerical work they do not value.

Learn from layered and hybrid products

Public product designs show that self-service and human support are not binary alternatives.

Stripe exposes different levels of the same capability

Stripe’s payment products illustrate how a standardized capability can be offered at several levels of customer control.

Payment Links lets a business create and share a hosted payment page without writing code and is rated in the documentation at the lowest integration-complexity level. Checkout provides prebuilt interfaces through an application programming interface, while Elements and lower-level payment interfaces allow more customization and ownership of checkout logic at the cost of greater implementation complexity.

The lesson is not that every product should copy a payments platform. It is that one underlying capability can support different routes:

• a constrained self-service path for a common job;
• a configurable path for customers who need more control;
• deeper integration for sophisticated or unusual use cases.

A service company can use the same design logic. The normal workflow becomes guided product functionality. Common variations become configuration. Rare or high-risk requirements remain specialist work or require a different package.

LegalZoom combines software paths with human expertise

LegalZoom describes its offerings as ranging from technology-enabled do-it-yourself services to full-service, do-it-for-me solutions led by concierge managers and attorneys. Its 2025 annual filing also reported an independent network of more than 1,000 attorneys available for legal questions and document review.

This example demonstrates an important boundary: simplifying intake, document preparation, coordination, tracking, and standard transactions does not require pretending that every legal question is a deterministic software task.

For other products, the equivalent boundary may be between:

• data preparation and strategic interpretation;
• routine compliance checks and accountable legal advice;
• standard configuration and architecture decisions;
• scheduled reporting and management judgment;
• initial triage and clinical diagnosis.

A credible product makes the boundary explicit. It does not hide continuing expert work or imply that software alone supplies a result that still depends on qualified judgment.

Avoid false completion and decide what comes next

An automation map can look finished while remaining commercially useless.

Common failure modes

Mapping the official workflow rather than real cases. The map omits workarounds, waiting, rework, and founder intervention.

Automating before simplifying. The team encodes duplicate approvals, poor handoffs, and unnecessary formatting.

Counting steps rather than effort and outcome. A high automation percentage produces little customer or financial value.

Treating one design partner as the market. Customer-specific rules become permanent product architecture.

Calling a form self-service. Customers enter information, but employees still interpret, correct, and re-enter it.

Hiding review and exception labour. The feature appears automated because rescue work is not measured.

Using average performance to conceal risky failures. A mostly accurate capability may still be unacceptable when its rare errors are costly or difficult to detect.

Removing useful judgment. The company reduces labour but also removes the advice, reassurance, adaptation, or accountability that customers valued.

Building a broad autonomous system too early. A narrow assisted capability could have produced faster evidence with less risk.

Ignoring ownership after launch. No one is responsible for monitoring exceptions, maintaining rules, reviewing incidents, or deciding when performance has deteriorated.

Automation has long carried the risk that people are left to handle only rare, difficult, and abnormal situations after routine work disappears. That can make human intervention slower and less reliable unless the product deliberately preserves context, skills, and escalation procedures.

What should be true when the task is complete

The work is credible when:

• the scoped workflow comes from observed customer cases;
• the normal path and meaningful exceptions are visible;
• each step has a reasoned treatment, not an assumption that software is always preferable;
• proposed product capabilities trace directly to customer results and recurring work;
• time, volume, variation, and failure impact are documented;
• potential automation is separated from production results;
• self-service includes validation, guidance, recovery, and access to help;
• human review remains where the stakes or uncertainty justify it;
• the backlog is ranked using evidence, value, effort, dependencies, and risk;
• the top item can be tested with a bounded group of suitable customers;
• the company can measure whether labour, delay, support, and errors genuinely decline;
• the product can deliver value without routine founder rescue.

The resulting decision may be to build a self-service capability, automate an internal step, introduce an employee-assistance tool, standardize the work with templates, retain a paid expert component, or remove a step entirely.

That is the purpose of the task. The company should finish with a clearer boundary between product and service, a defensible first product-capability backlog, and evidence about whether customers can receive the promised result without recreating a custom project behind the interface.

Sources

Primary and official sources

• International Labour Organization, Generative AI and Jobs: A Refined Global Index of Occupational Exposure, May 2025.
• Organisation for Economic Co-operation and Development, What Skills and Abilities Can Automation Technologies Replicate and What Does It Mean for Workers?
• National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework Playbook, Measure function.
• Stripe documentation for Payment Links, Checkout, and Payment Element.
• LegalZoom.com, Inc., Annual Report on Form 10-K for the year ended December 31, 2025.

Open research

• Bitner, Ostrom, and Morgan, “Service Blueprinting: A Practical Technique for Service Innovation.”
• Brynjolfsson, Li, and Raymond, “Generative AI at Work,” National Bureau of Economic Research Working Paper 31161.
• Dell’Acqua et al., “Navigating the Jagged Technological Frontier,” field experiment involving 758 consultants.
• Shamsuzzoha, Blomqvist, and Takala, “Service Productisation Through Standardisation and Modularisation: An Exploratory Case Study.”
• El-Gharib and Amyot, “Robotic Process Automation Using Process Mining: A Systematic Literature Review.”
• Leno et al., “Robotic Process Mining: Vision and Challenges.”
• Considine and Cormican, “Self-Service Technology Adoption: An Analysis of Customer-to-Technology Interactions.”
• Bainbridge, “Ironies of Automation.”