Methodology
How We Work
Results first: one workflow is piloted, measured against an agreed baseline, and judged go or no-go — before anything scales. Every stage ends with a decision: continue, adjust, or stop, so you are never locked into a rollout that has not earned it.
The results spine: pilot, measure, decide
Everything on this page serves one sequence. Stages 1–3 set up a fair test: the workflow, its baseline, and a safe design. Stage 4 runs the pilot. The go/no-go criteria and section 4b decide whether it scales. Stages 5–6 follow only after a go decision.
One workflow, real permissioned data, human review on every material output.
The same measures, before and during the pilot, so the comparison is like for like.
Pass or fail is judged against the written measures — not by either side's impression afterwards.
No stage scales on a promise. A result earns the next stage, or the work stops, narrows, or pauses.
Five principles behind every engagement
These principles exist to protect one thing: a result you can trust before anything scales.
1. Measure first
We agree a baseline and the metrics that will define success before anything is built — response time, handling time, error rate, or another measure that fits the workflow. Without a baseline, there is no honest claim of improvement later.
2. One workflow at a time
We start with the workflow that costs the most time, loses the most leads, or creates the most rework — not with a company-wide programme. A narrow win is easier to test, staff, and learn from.
3. People approve what matters
AI drafts, classifies, and proposes. People approve customer-facing messages, financial or contractual actions, and anything irreversible. Escalation paths are designed in, not added after a mistake.
4. Work with your systems
We connect to the CRM, email, support, and operational tools you already use where practical, rather than asking you to replace them first. If a tool cannot support a safe integration, we say so as soon as it is found, and no later than Architecture stage — not after deployment.
5. No forced rollout
A pilot that does not meet its agreed baseline does not roll out. You keep the findings, the workflow map, and the evaluation — and you choose whether to adjust, narrow, pause, or stop. See “4b. If a pilot does not meet its agreed baseline” below.
What this means for you
You get a clear decision at each stage, a named owner on your side and ours, and deliverables you can keep even if you stop. Timings and scope are agreed per project at the start of each stage; this page does not promise a fixed duration, because a workflow with clean data and one approver moves differently from one spanning several teams. The method is deliberately conservative: it is designed to stop bad rollouts, not to slow good ones.
The journey at a glance
You approve the move from one stage to the next. Nothing proceeds on an assumed approval. Read the journey as a results spine: stages 1–3 prepare the test, stage 4 is the gate, and stages 5–6 follow only a go decision.
1. Discovery
Activities: Interviews with the people who actually do the work; workflow mapping end to end, including the exceptions and workarounds that never appear in a process diagram; baseline measurement of the current time, volume, error, and response measures; and a first look at where the data lives and how clean it is.
Decision point: Is there a measurable, automatable workflow worth pursuing — or is the real problem a staffing, policy, or data-quality issue that AI will not fix?
Deliverables: Workflow map, baseline metrics, opportunity list, and a plain-language note on anything that is not a good AI candidate and why.
Client responsibilities: Provide access to process owners and relevant data sources; name one decision-maker who can confirm priorities.
You will know: Exactly which workflow we are talking about, how it performs today, and what “better” would have to look like.
2. Opportunity Assessment
Activities: Ranking opportunities by value, risk, data readiness, and effort; an ROI estimation approach agreed before any build — what will be counted, over what period, and what will be excluded. The estimate is a hypothesis the pilot tests, not a return that is promised; and a check for risks that rule a use case out, such as sensitive decisions that should stay fully human.
Decision point: Which one or two opportunities go to design — and which are deliberately deferred?
Deliverables: Ranked opportunity scorecard, prioritised roadmap, success metrics and baseline for the leading candidate, and a list of deferred opportunities with reasons.
Client responsibilities: Agree priorities and the metrics that will define success; confirm who owns the workflow once it changes.
You will know: Why this workflow, why now, and what would have to be true for it to be worth continuing.
3. Architecture
Activities: Tool selection against your existing stack; integration design, including what happens when a system is down or returns unexpected data; security and permission design — who and what can see, change, and approve each step; escalation and fallback design; and a cost picture for running the workflow, including model, integration, and maintenance effort.
Decision point: Is the design safe, maintainable, and affordable to run — and is there a clear way to stop or roll back if it misbehaves?
Deliverables: Architecture and integration plan, security and approval design, data-access and retention requirements for the project, and a pilot plan with its pass measures.
Client responsibilities: Approve tools, data access, and approval rules; confirm the people who will staff approvals during the pilot.
You will know: What will be built, what it will touch, what it will cost to run, and how it can be stopped.
4. Pilot — the gate before scale
Activities: One bounded use case, tested with real, permissioned data and human review on every material output; quality evaluation against the agreed measures, including the error rate the workflow must stay within — not a demo on hand-picked examples; error and escalation review, so failures are counted and understood, not hidden; and a short, honest report on what worked, what did not, and what would need to change.
Decision point: Did the pilot meet the measures written in the pilot plan, with a workload your team can actually staff? Pass or fail is judged against those written measures, not by either side’s impression afterwards.
Deliverables: Pilot workflow, quality evaluation, measured result against baseline, and a rollout recommendation with its conditions — or a clear recommendation not to roll out.
Client responsibilities: Review pilot outputs, test the approval workload yourself, and approve or reject rollout. A pilot is not a purchase commitment to full deployment.
You will know: Whether this workflow, with this data and this team, genuinely improves on the baseline — before you commit to scaling it.
4b. If a pilot does not meet its agreed baseline
This is the other outcome of stage 4, decided by the same measures.
Then it does not roll out. That is the point of the pilot, and it is not treated as a failure of the engagement — it is the engagement working as designed.
From there, you choose one of four paths, with our recommendation in writing:
- Adjust and re-test once: fix a specific, identified cause — for example, cleaner source data, a tighter scope, or a different approval step — and run a bounded re-test against the same measures.
- Narrow the use case: keep the part that worked, and drop or defer the part that did not, rather than scaling a mixed result.
- Pause: stop work while a blocker is resolved on your side, such as a system change or a staffing decision, with the findings preserved.
- Stop: close the workflow and keep everything produced so far — the workflow map, baseline, architecture, and evaluation. No further rollout, and no obligation to proceed to another use case.
What does not happen: we do not average away a miss, change the measures after the fact to declare success, or roll out on the argument that value will appear later. If the measures change, they change before a re-test, openly, and with your agreement.
The pilot artefacts — blank templates, not results
The four documents below are the working templates used in a pilot. They are published blank on purpose: a template shows method, while a filled-in example would imply results that do not exist yet. Each template is completed jointly with the client before the pilot starts, and the completed version is what the week-4 review judges against.
1. Baseline-measurement sheet (blank)
What is counted, where it comes from, who counts it, and over what period — agreed before automation is switched on, and measured the same way before and during the pilot.
- What is counted: [measure, as defined in the pilot plan — for example, response time, qualification share, or record completeness]. Source: [system or record the figure comes from]. Counted by: [named role]. Period: [agreed baseline period].
- What is counted: [second measure]. Source: [system or record]. Counted by: [named role]. Period: [agreed baseline period].
- What is counted: [third measure]. Source: [system or record]. Counted by: [named role]. Period: [agreed baseline period].
No thresholds are pre-filled here. Thresholds are agreed with the client before the pilot starts and written into this sheet.
2. Pilot go/no-go criteria (blank)
The exact decision rules applied at the week-4 review. These rules are fixed before the pilot starts and are not changed after the fact to declare success.
- Go: every agreed measure meets its agreed threshold, with acceptable quality and an approval workload the client's team can staff. The rollout recommendation states its conditions in writing.
- No-go: any agreed measure misses its threshold. The outcome is one of the four paths already described on this page — adjust and re-test once, narrow the use case, pause, or stop — with the recommendation in writing.
- Decision recorded by: [named role]. Measures fixed on: [date, before the pilot starts]. Thresholds: [agreed values, filled in per pilot — never pre-filled on this page].
This section states decision rules only. It contains no commercial terms, fees, or scope promises; those belong in a separate agreement, not in a measurement template.
3. Sample weekly pilot report (blank)
The sections of the short report produced each pilot week. Section headings only — no figures are pre-filled, because no pilot has run yet.
- Period covered: [week dates].
- What was tested: [workflow variant and data used].
- Outputs reviewed: [what a person approved, edited, or rejected].
- Errors and escalations found: [what went wrong, what caught it, and what changed as a result].
- Measures this week: [figures against the agreed baseline, filled in during the pilot only].
- Decisions needed: [what the client is asked to decide before the next week].
4. Controls checklist (blank)
The controls confirmed before any pilot output reaches a real customer or system. Each item is confirmed per project, not assumed from this page.
- Access: only the systems, data, and people the workflow actually needs. Named systems: [list]. Named people: [list].
- Approval: a named approver for each decision type the workflow touches. Decision type: [type]. Approver: [name or role].
- Rollback / kill-switch: how the workflow is stopped, and who can stop it. Stop method: [method]. Who can stop it: [name or role].
- Escalation: where a case goes when it falls outside the approved sources or below the agreed confidence level. Escalation route: [route].
Retention is deliberately absent from this checklist: retention wording is still to be confirmed (see Skipped items) and will be added only once the owner confirms it. Nothing on this page should be read as a retention promise.
5. Deployment
Activities: Integration, testing, and phased rollout — one team, segment, or workflow variant at a time where that is possible; training for the people who will approve, monitor, and use the workflow; documentation of escalation, rollback, and support routes; and a go-live check that controls, permissions, and monitoring are actually in place, not just planned.
Decision point: Is the team ready, are controls in place, and is the rollout reversible if something goes wrong in the first weeks?
Deliverables: Live workflow, training, support process, rollback plan, and a first operating review date.
Client responsibilities: Adopt the new workflow, staff the approval roles, and raise issues through the agreed support route rather than working around the system silently.
You will know: The workflow is live, the people who run it are trained, and it can be rolled back.
6. Optimisation
Activities: Monitoring of quality, volume, cost, and error/escalation rates; regular review against the original baseline; improvement cycles for prompts, rules, knowledge, and integrations; cost review, including whether a simpler or cheaper approach would now do the same job; and periodic permission and security reviews.
Decision point: Keep, improve, narrow, or retire the workflow? A workflow that no longer earns its running cost should be retired, not maintained out of habit.
Deliverables: Performance reports against baseline, improvement backlog with expected effect, stated as an estimate to be measured at the next review, and a recommendation at each review: continue, change, or close.
Client responsibilities: Review reports, decide on further investment, and confirm any change to success measures before it is applied.
You will know: Whether the workflow still earns its running cost — and what to change, or close, if it does not.
What you can expect from us — and what we ask in return
From ProTech
Plain-language explanations, not jargon; decisions in writing at each gate; honest reporting of misses as well as wins; security and permission design for each project; and no rollout before a pilot has earned it.
From you
Access to the people who do the work, a named decision-maker, timely approval reviews, and staffed approval roles during pilot and rollout. Pilots often stall not on technology but on approvals sitting unreviewed — which is why approval roles are staffed before the pilot starts.
What we will not do
Guarantee an outcome before a pilot has measured it; promise a percentage saving or revenue lift before measuring a pilot; publish a client result without permission and a measured baseline; claim a certification, partnership, or SLA we do not hold; or automate a decision that should stay human without telling you.
Commitments you can hold us to
These are not slogans. Each one restates a decision point already described on this page, collected here so a buyer can test it in the first call.
- If the pilot does not meet its agreed baseline, it does not roll out. You keep the findings, the workflow map, and the evaluation, and our recommendation is given in writing. (See principle 5, "No forced rollout", and "4b. If a pilot does not meet its agreed baseline".)
- No rollout without a named approver for each decision type the workflow touches. Approval roles are staffed before the pilot starts, and the deployment go-live check confirms that controls and permissions are actually in place, not just planned. (See the pilot artefacts controls checklist and "5. Deployment".)
- You own the workflow documentation at every stage. The map, baseline, and evaluation are yours to keep, whether the pilot stops or proceeds, and you own the business workflow and its decisions after deployment. (See "4b. If a pilot does not meet its agreed baseline" and "Who owns the workflow after deployment?" below.)
If any of these is not true on your project, that is the first thing to raise on the call.
Common questions
Do we have to replace our software first?
Usually not. Discovery and Architecture start from the tools you already use, and a use case is only chosen if it can be integrated safely. If replacement is genuinely needed, that is a decision at Architecture stage, not a precondition for talking to us.
How long does a stage take?
It depends on the workflow, the data, and how many teams are involved. We agree scope and timing at the start of each stage, and a stage that needs more discovery is extended openly, by agreement, rather than rushed into a build.
What if our data is messy?
Then Discovery says so, and the pilot scope reflects it — a narrower use case, a data-cleanup step first, or a different workflow entirely. Messy data is a finding, not a reason to build on top of it and hope.
Who owns the workflow after deployment?
You own the business workflow and its decisions. We support, monitor, and improve the automation under the managed arrangement agreed for that project (see Managed AI Solutions), and the rollback and handover routes are documented before go-live.
Ready to find the first opportunity?
Book an AI Opportunity Discovery Call. It is not a guaranteed proposal, price, or implementation commitment — it is a conversation about one workflow, its baseline, and whether a pilot is worth testing.