A clear route from assessment to working AI.
A useful objective, realistic boundaries and a way to tell whether the solution works. Paid stages with a deliverable and a decision each, and rollout only when the evaluation supports it.
Timeline and outputs.
| When | Phase | Duration | You decide | You receive | Your input |
|---|---|---|---|---|---|
| Week 0 | Free fit call | 30 minutes | Whether AI is a sensible answer and what an assessment would cover. | A written note on the next step. | One workflow, described by the person who lives with it. |
| Weeks 1 to 2 | Readiness assessment | 1 to 2 weeks | Which opportunity to pilot first, and whether to build or buy. | Workflow map, prioritised roadmap, evaluation set, scoped pilot proposal with fee. | Two or three people for an hour or two each; sample material through an agreed secure route. |
| Weeks 3 to 6 | Pilot and evaluation | about 4 weeks | Roll out, adjust and re-evaluate, or stop. | Working pilot, evaluation report, documentation, recommendation. | A named reviewer who can look at results weekly. |
| After the evaluation | Rollout and support | Scoped separately | Owners, monitoring, support hours and which actions may run automatically. | Operating guide, handover, support agreement. | A named owner for the solution in your team. |
Four stages. Each with a deliverable.
Understand and build are paid stages with a fixed fee and a quote respectively. Evaluate is the final week of the pilot. Improve is scoped separately after the evaluation.
Understand
Map the workflow, data and decisions. Agree what a useful outcome means.
- Workflow map with friction points
- Evaluation cases agreed with your team
- Scope, success measures and pilot proposal
Build
Develop a focused pilot with visible progress and clear review points.
- Working pilot in your environment or ours
- Weekly review call and written update
- Review interface for exceptions
Evaluate
Check representative and difficult cases. Review errors, costs and usefulness.
- Evaluation report: accuracy, error types, cost per run
- Known limitations written down
- Recommendation to roll out, adjust or stop
Improve
Agree rollout, ownership and support. Expand when the evidence supports it.
- Operating guide and handover
- Monitoring of exceptions and costs
- Support hours and change process in writing
Progress you can see. Decisions you understand.
We agree the people, responsibilities and communication for the engagement before development starts.
Direct technical involvement
Work with senior expertise on scope, architecture and the decisions that shape delivery.
A weekly rhythm
A weekly review call and a written update every week. Meetings from 1 PM IST for the Gulf and from 3 PM IST for the UK and Europe.
Approval rules written down
During a first pilot, consequential actions such as sending a message or writing to a business record wait for a person to approve them. After the evaluation, automatic actions can be agreed per action, with validation rules, logging and exception handling written into the scope.
A practical handover
Identify deployment, documentation, access and ongoing ownership before rollout.
Supplier invoices, start to finish.
A worked example, written to show how the stages feel from the client side.
Fit call
A distributor receives supplier invoices by email all day. Two staff re-type them into the accounting tool. A short call confirms the fit and the assessment scope.
Assessment
We map the invoice path from inbox to ledger with the two staff, collect real invoices across every supplier format through an agreed secure route, and agree an evaluation set that includes the ugly ones: scans, handwritten notes, credit notes. Success measure and approval rules agreed in writing.
Pilot
A workflow reads the inbox, a model extracts the agreed fields, rules validate totals and supplier codes, and a review screen shows anything uncertain. The accounting entry waits for a person. Weekly review call; written update every week. In week 6 the evaluation set and one live week are scored.
Rollout, scoped separately
If the evidence supports it: rollout to the full inbox with the finance lead as owner, a monitored review queue, and support hours agreed in writing. Anything the pilot handled poorly stays manual until the next iteration.
Sample evaluation report
Counts and denominators are shown together, so a high accuracy on answered cases cannot hide a large review rate. “Sent to review as uncertain” counts cases the system was unsure about; a correct refusal is a case it recognised as out of scope and handed to a person, counted as a correct outcome.
| Case group | Cases | Correct outcome, no edits | Sent to review as uncertain | Wrong |
|---|---|---|---|---|
| Typed PDF invoices, known suppliers | 40 | 36 | 3 | 1 |
| Scanned invoices | 20 | 9 | 10 | 1 |
| Credit notes and corrections | 10 | 4 | 5 | 1 |
| Not an invoice (should be refused) | 6 | 6 correct refusals, routed to a person | n/a | 0 |
- Every wrong case described, with the reason
- Average review time per flagged document
- Cost per invoice for model usage and hosting
- A recommendation: roll out, adjust and re-evaluate, or stop
Who this suits, and who it does not.
A scoped, evidence-first approach is not for everyone. Better to say so here than in week three.
This approach suits
- Businesses with a recurring process that costs real time and can name who does it
- Businesses that have not yet chosen a first process; the assessment helps choose it
- Teams willing to review results weekly and supply real examples
- Leaders who want a written reason to continue, adjust or stop
- Companies without an IT team, as long as someone owns the decision
This approach does not suit
- Fully autonomous systems with no human review from day one
- Fixed-price, fixed-scope bids before anyone has looked at the data
- Projects where nobody on the client side can review results during the pilot
- A rollout decision taken on a demo rather than the evaluation
Rollout and support with a defined scope.
Rollout depends on the evaluation and is scoped separately. Support hours, response targets, maintenance responsibilities and changes are agreed in writing. Third-party services and usage costs are identified separately.
Before a production rollout
- Who owns and operates the solution
- Which actions need human review, and which automatic actions are agreed
- How exceptions and costs are monitored
- How access and information are managed
- What support includes and how changes are scoped
How an engagement runs.
How long does a first engagement take?
An assessment of 1 to 2 weeks, then a pilot of about 4 weeks including its evaluation. Together that is usually 6 to 8 weeks. The total depends on scheduling, access readiness and integration complexity. Rollout is scoped separately after the evaluation.
What do I receive at the end of a pilot?
A working pilot, an evaluation report with accuracy, error types and cost per run, documentation, and a recommendation to roll out, adjust or stop.
How does Blend decide whether an AI solution works?
An evaluation set of representative and difficult cases is agreed before building. Results and limitations are reported together, so the decision to roll out rests on evidence rather than a demo.
How often do we meet?
A weekly review call and a written update every week, plus named decision owners on both sides so questions do not wait for the next call.
Who does the work?
Blend is founder-led. Senior engineers handle scope, architecture and delivery, and the team for each engagement is agreed before it starts.
Who owns the code and the solution?
Ownership, licences and handover are agreed before development starts. Bespoke code written for you is yours under the engagement agreement; third-party components keep their own licences, and infrastructure and accounts are arranged in scope.
Which actions need a person to approve them?
During a first pilot, consequential actions such as sending a message or writing to a business record wait for a person to approve them. After the evaluation, automatic actions can be agreed per action, with validation rules, logging and exception handling written into the scope. Our products have their own review settings, described on each product page.
What if the pilot does not work?
Then the evaluation says so, in writing, with the reasons. You keep the workflow map, the evaluation set and the findings. Stopping after a pilot is a valid outcome and is cheaper than a failed rollout.
How is pricing structured?
A free fit conversation; a fixed-fee readiness assessment agreed before you commit; pilots and implementations quoted after the assessment; model usage, hosting and third-party services itemised at cost.
A worthwhile problem deserves a clear plan.
Start with the workflow and the outcome you need. We will map it to the phases and tell you what each would take.