How an engagement works

1. 1

   Understand the workflow

   You provide

   A walkthrough of how the process runs today, and who touches it.

   We return

   A written description of the steps, the inputs and where time goes.

2. 2

   Define scope and inputs

   You provide

   Sample files, system access where needed, and the volumes involved.

   We return

   A scope with what is included, what is excluded and the inputs required.

3. 3

   Build or configure

   You provide

   A named contact for questions during the build.

   We return

   The working system or script, plus notes on how it handles edge cases.

4. 4

   Test and review outputs

   You provide

   Review of the output against what you expected.

   We return

   Corrections, and a clear list of what the system could not decide.

5. 5

   Agree what happens next

   You provide

   A decision on whether to extend, hand over or stop.

   We return

   Handover notes, or a scope for the next piece of work.

Scope is written, not implied

What is included, what is excluded and which inputs are required, in a document you can hold us to. Anything outside it is quoted as further work rather than absorbed quietly and resented later.

Your approval process stays yours

We build things that produce outputs for a person to approve. We do not take over the decision, and we do not quietly move the sign-off into software.

Access is the minimum the step needs

Read-only where read-only will do. Write access only where it is in scope, agreed and tested first. Credentials are never stored in anything we ship to the browser.

Uncertainty is surfaced, not smoothed

Where a system cannot decide, it says so and hands over. Where we cannot estimate something honestly, we say that too, rather than giving you a number that sounds better.

Handover is part of the work

Notes on how to run it, what to check and what breaks it. If a colleague cannot pick it up, the engagement is not finished.

Do you need access to our systems?

Only where the scope requires it, and only to what the scope requires. A reconciliation can usually be done from exported files. An integration cannot. Access is agreed step by step rather than granted at the start.

What happens if the first step shows this is not worth doing?

We say so, and you get the written description of the process either way. A scoping step that ends in no is a cheaper outcome than a build that ends in nothing used.

Who owns what we build?

You do, as agreed in writing before the build starts, together with the handover notes. The point of the notes is that the work does not depend on us remaining involved.

How do you handle the cases the system cannot decide?

They are routed to a person, with the reason attached. A system that guesses to keep its numbers clean is worse than one that admits what it could not resolve.

Choosing which part of a process to start with is the decision that matters most before any of this begins. What to automate first in a manual process sets out how that choice is made here.