Fictional sample report · Workflow Decision v1.1

See what we would recommend before paying for a build.

This invented example shows what you receive after a Workflow Decision for one client-onboarding process. It contains no client information, connects to no live software and makes no claim about real savings or customer results.

One part of the business · your team approves important decisions · written instructions included

Download the print PDF Compare services and prices How we work →

At a glance

What to know before you decide.

Invented UK service-business example.
One repeated process, one responsible person and one main problem.
Shows how value could be estimated using clearly invented figures.
Ends with a written recommendation—not an automatic decision to build.

In plain English

We examine one recurring process before recommending automation.

We find where work gets stuck, who should own it, whether your existing software can fix it, how improvement would be measured and whether building anything is worthwhile.

Pick one process

Focus on a recurring task that creates delay, chasing or rework.

Check what you have

See whether your current software can solve it before proposing a new build.

Estimate the value

Use your figures and show every assumption instead of promising a saving.

Give a clear answer

Recommend a small change, a build or building nothing—with the reasons written down.

Decision brief

One repeated task. One clear question.

Can accepted client work reach the right person with all the information they need, a clear warning when something is missing and a person approving the next step?

Process covered

Moving new client work into onboarding

Begins when the work is accepted. Ends when the person responsible for client service accepts or returns the onboarding record.

Who is responsible

The client-services lead

Decides whether the information is complete and the work can move forward. The process supports that decision; it does not replace it.

Systems in view

CRM + Microsoft 365

These are examples only. The Workflow Decision checks the real software, permissions and features already available to the client.

Decisions kept with people

Professional judgement and advice

The example does not automate professional advice, regulated decisions, identity checks, payment decisions or reviews of sensitive information.

How the work would move

Missing information gets a clear next step.

Each step shows who is responsible and what happens next. A person still decides whether important work can move forward.

Work begins

The authorised commercial manager marks the client work as accepted.

Create record

The person responsible for client service receives one visible onboarding record with the agreed due date.

Check

The information is checked against the agreed minimum list. Professional judgement always stays with a person.

Return missing information

Missing information goes back to the responsible person with a reason and clear next step.

Person approves

The client-services lead decides whether the work is ready to move forward.

Close and record

The process records the decision, any known problem and who receives the work next.

Check existing software first

Use the smallest useful change first.

This invented example uses existing CRM fields, a Microsoft 365 record and a simple approval step before considering a custom portal.

Check first

Existing features

Required CRM fields and stage-change rules.
Existing Microsoft 365 lists, forms and permissions.
Current notification and task-assignment behaviour.
The manual way of doing the work, which must remain available.

Fictional decision

Small change before build

Set the minimum required fields and create one clear record for missing information. Test it with approved invented data. Recommend a build only if the existing software cannot show the agreed information and approval step.

Recommending that nothing be built is still a valid paid answer.

How success would be measured

Agree what to measure before claiming an improvement.

This example shows a measurement plan. It does not invent a starting point, saving or return on investment.

Primary intended measureHow long it takes for a new client record to reach the responsible person

Start: The time the authorised commercial manager accepts the work.
End: The time the responsible client-services person accepts or returns the record.
Source: CRM stage history plus the controlled onboarding record.
Reporting: Median and range by week, with volume and exclusions stated.
Starting figure: Not supplied in this invented example. Measure before making a change.
What else may affect the result: Input quality, staffing and client response can affect elapsed time.

Example estimate using invented figures

Show how the estimate works—and what could change it.

These figures are invented only to show the calculation. They are not a measured starting point, saving, forecast or customer result.

New client cases each month160Fictional client estimate

Missing information first time35%56 cases · invented, unverified assumption

Time spent chasing each case12 minPer incomplete case · estimate

Possible time recovered5.6–8.4 hrs/monthIf one chase were avoided on 50–75% of incomplete cases

Visible calculation160 × 35% × 12 minutes × 50–75% ÷ 60 = 5.6–8.4 hours/month

We would check every figure against the client’s own information before using it to make a decision. Staffing, behaviour, missing information, software limits and the effort needed to change the process could reduce or remove this time saving. No cash saving or return on investment is claimed.

How we would test it

Set a clear pass check for every important situation.

The work passes only when it behaves as agreed—not simply because the screen looks finished.

Case	Condition	Expected behaviour	Pass evidence
A1	Complete record	When all required information is present, the process creates one onboarding record.	The responsible person and due date are visible.
A2	Missing information	When required information is missing, the work does not move forward.	The reason, responsible person and next action are visible.
A3	Human decision	The work cannot move forward without the agreed person approving it.	Who decided and when are recorded.
A4	Supplier interruption	If a connected service is unavailable, the process stops safely and keeps the last known information.	It does not claim success, and the manual alternative is shown.

Complete record

Expected behaviour: When all required information is present, the process creates one onboarding record.
Pass evidence: The responsible person and due date are visible.

Missing information

Expected behaviour: When required information is missing, the work does not move forward.
Pass evidence: The reason, responsible person and next action are visible.

Human decision

Expected behaviour: The work cannot move forward without the agreed person approving it.
Pass evidence: Who decided and when are recorded.

Supplier interruption

Expected behaviour: If a connected service is unavailable, the process stops safely and keeps the last known information.
Pass evidence: It does not claim success, and the manual alternative is shown.

This HTML page is the accessible reading version. The print PDF is not tagged for screen-reader navigation.

What you receive

What the client receives.

A map of how the process works now and how it could improve.
Who is responsible, what happens when information is missing and who approves the next step.
A check of the features already available in your software.
A written recommendation to make a small change, build something or make no change.
A clear way to measure improvement, with all assumptions and calculations shown.
Known limits and questions that still need an answer.

Download the print PDF

For screen-reader navigation, use this web-page version.