Eight steps, with the paid work starting at step two

1. 01

   Workflow review

   No cost

   Purpose

   Understand one workflow well enough to say whether it is worth investigating further.

   A 30-minute conversation about one workflow: what arrives, who touches it, where it stalls, and which systems hold the answers. A written recap follows, normally within two business days.

   Produces

   • A concise written recap of the workflow as described
   • One or two plausible automation opportunities
   • The important uncertainties, stated plainly
   • Whether a paid assessment appears worthwhile, and a recommended next step

   Needs from you

   • 30 minutes
   • A willingness to describe how the work actually runs, including the parts that are held together informally
2. 02

   Workflow assessment

   Fixed fee

   Purpose

   Establish whether the automation is feasible, safe and economically sensible before anyone commits to building it.

   Structured sessions with the people who do the work, verification of what each system genuinely supports rather than what its marketing claims, and a review of real request samples to understand how much they vary.

   Produces

   • A current-state workflow map and the bottlenecks in it
   • A feasibility analysis with integration options and their risks
   • A future-state workflow and an implementation scope, with assumptions and exclusions
   • A rough implementation range and a go, no-go or investigate-further recommendation

   Needs from you

   • Access to the people who run the workflow
   • A sample of real requests
   • Read access to, or documentation for, the systems in scope
3. 03

   Scoped proposal

   No cost

   Purpose

   Turn an approved assessment into a fixed written scope with no ambiguity about what is included.

   The proposal states what is built, what is explicitly excluded, and the assumptions it depends on. Acceptance criteria are written so a non-developer can check them.

   Produces

   • A written scope with explicit exclusions and assumptions
   • Acceptance criteria stated in business terms
   • Price, payment schedule and expected sequence

   Needs from you

   • A decision
   • Confirmation of who signs off on acceptance
4. 04

   Build and integration

   Quoted

   Purpose

   Build the agreed workflow against real systems, in accounts the client owns.

   Credentials are created by the client and scoped to the minimum required — never a shared personal login. Idempotent writes, retries with backoff and an error queue are built in from the start, not added after the first incident.

   Produces

   • A working integration running in client-owned accounts
   • An error queue and retry behaviour that can be inspected
   • Progress demonstrated against the acceptance criteria rather than a percentage

   Needs from you

   • Scoped credentials created by the client
   • A technical point of contact
   • Timely answers on business rules when edge cases surface
5. 05

   Shadow-mode testing

   Quoted

   Purpose

   Prove the workflow behaves correctly on real inputs before it is allowed to affect anything.

   The workflow runs alongside the existing process and proposes outcomes without acting on them. Proposed results are compared with what the team actually did, and every disagreement is examined: rule error, data problem, or genuine judgement call.

   Produces

   • Evidence from the client’s own data about how the workflow performs
   • A corrected rule set, re-tested against the same inputs
   • An informed go-live decision, including the option not to

   Needs from you

   • A period of parallel running
   • Time from the people whose work is being compared
6. 06

   Approval and deployment

   Quoted

   Purpose

   Go live deliberately, with a way back.

   Written sign-off against the acceptance criteria, then a staged cutover — usually one workflow or one customer segment at a time. The rollback procedure is tested before it is needed, not written down and hoped for.

   Produces

   • The workflow running in production
   • A tested rollback procedure
   • Monitoring and alerting confirmed to reach a person who will act on it

   Needs from you

   • Written sign-off
   • A named owner for the workflow
7. 07

   Documentation and handover

   Quoted

   Purpose

   Make the client independent — including independent of AlloyPath.

   A runbook covering what it does, how to change the rules and what to do when something fails, plus architecture and field-mapping documentation that records the fields deliberately left out. A working session with the people who will own it day to day.

   Produces

   • Runbook, architecture and field-mapping documentation
   • Confirmation that code, accounts, credentials and documentation are in the client’s control
   • A handover session with the people who will own the workflow

   Needs from you

   • The people who will own the workflow, for the handover session
8. 08

   Support

   Quoted

   Purpose

   Optional, and never a condition of ownership.

   An agreed scope for changes, fixes and small extensions, with response expectations stated honestly for a founder-led engagement. Support can end without affecting the client’s ability to run what was built.

   Produces

   • A defined support arrangement, or no arrangement at all
   • Either way, a client fully able to operate the system

   Needs from you

   • A decision on whether ongoing support is wanted

Request a workflow review