PLEXUS ← Back to PLEXUS

The automation readiness guide

Find one process
worth improving.

You do not need a large team or an AI roadmap to start. You need a recurring task, a clear baseline, and a way to tell whether the change helped.

Use this guide to choose a small pilot and test the economics before committing to a build. Read it here, save the page, or print a copy. No email required.

Start with the checklist ↓

01 / Check readiness

Could someone else follow the process?

Choose one task and work through these six checks. An unchecked item is preparation work, not a verdict on your business. Your selections stay on this page and reset when you reload.

You can count how many invoices, requests, records, or reports come through in a normal week. Include busy periods and the time spent handling exceptions.

Someone can explain a correct result, review examples, and decide what happens when the process encounters a missing field or an unusual request.

You have representative examples, including errors and edge cases. The work has a defined start and finish; it does not rely entirely on unwritten judgment.

You know where the data lives, who can approve access, and whether an integration or export is available. Start with the smallest permissions the task needs.

Decide what requires human approval, such as payments or customer-facing messages. Establish which data and tools are permitted before using real records.

A person can stop the pilot, recover the queue, and complete the work manually. You have a place to record failures and a named person to receive them.

Start with a draft or a recommendation. Extracting fields for review, preparing a report, or routing a request gives you a way to compare results before allowing the system to take consequential actions.

02 / Measure the work

Write down what happens today.

Observe a representative cycle of the process. A weekly task may need several weeks of examples; a monthly close needs the full close cycle. Avoid building your forecast around the fastest or slowest single case.

Process and owner
What starts the task? What counts as finished? Who is responsible for a correct result?
Volume and time
Record items per week and hands-on minutes per item. Keep waiting time separate from labor time.
Quality and exceptions
Count errors, corrections, missing inputs, and unusual cases. Record the additional review and rework time.
Systems and data
List the source, destination, access owner, sensitive fields, and any approval needed to use the data.
What would improve
Choose a measurable goal: less handling time, fewer errors, faster turnaround, or more volume with the same team.
Where saved time goes
Name the work that will use the released capacity. Only count cash savings when a specific expense can actually be reduced or avoided.

03 / Check the economics

Time saved and money saved are different.

Five hours released from a salaried employee's week creates capacity. It does not automatically reduce payroll. Keep that value separate from identifiable reductions in overtime, contractor spend, or a planned expense you can avoid.

Capacity view

Estimate the hands-on time the process could release, after the human review and rework it still needs. Value those hours to compare opportunities. Do not call that amount cash savings.

Cash view

Count only a defensible reduction or avoided expense. Subtract ongoing software, model usage, monitoring, and support costs. Compare the remainder with the initial build and rollout cost.

The manual worksheet

  1. Weekly baseline hours = items per week × minutes per item ÷ 60.
  2. Weekly capacity released = baseline hours × the share of labor time saved after review.
  3. Monthly capacity value = hours released × hourly labor cost × 52 ÷ 12.
  4. Monthly cash savings = capacity value × the share tied to an expense you can reduce or avoid.
  5. Net monthly cash impact = cash savings − recurring operating costs.
  6. Simple payback = initial investment ÷ positive net monthly cash impact.

Use this as a first comparison. It does not model ramp-up, taxes, financing, changing volume, or revenue gains. A capacity project can still be worthwhile even when it has no direct cash payback.

04 / Run a small pilot

Prove the process before expanding it.

Choose the smallest useful slice of work with a clear owner and a recoverable outcome. A lower-volume, well-defined process is often easier to learn from than a large, messy one.

  1. Write a one-page pilot brief. Name the input, output, owner, systems, allowed actions, human approvals, and stop conditions. Set the success measures before building.
  2. Test representative examples. Include normal work, incomplete records, duplicates, and edge cases. Use approved sample data and compare the output with a human-reviewed answer.
  3. Start with human review. Keep a person in control of the final action. Track errors, review time, total handling time, and items that fall back to the manual process.
  4. Compare like with like. Measure the same type and volume of work before and during the pilot. Include ongoing review, maintenance, and operating costs.
  5. Decide whether to expand, revise, or stop. Broaden access or autonomy only when the observed results support it. Keep an owner, an error log, and a fallback in place.