See how we shape the scope, work with your team and decide what is ready for everyday use.
AI consulting and implementation, shaped around the work your business needs to do.
01 / Understand
Make the scope worth agreeing to.
A good starting point is specific: one piece of work, the people around it and a useful improvement to investigate. The boundaries matter as much as the idea.
We look at the workflow, data and dependencies before recommending what to build. Sometimes the better answer is a simpler change, without AI.
The commitment
Scope and pricing are agreed stage by stage. Combined engagements are also available. Timing is agreed for each project.
Understand → Prove → Embed
Scope
Engagement brief01 / 03
Illustrative example / Service operations
A better route for every request.
An example brief for triaging incoming service requests.
01The work today
A person reads each request and assigns it to a queue.
02Inside the scope
Suggest a category and route. A person reviews uncertain suggestions.
03Outside the scope
Automatically replying to customers or closing their requests.
04Evidence we need
Representative requests, agreed categories and a comparison with the current process.
Still to establish
Is the improvement worth building?
01 — The scope sheetIllustrative engagement brief. The actual scope is agreed for your business.
Working together
Different responsibilities. Shared decisions.
The people who know the work are part of shaping it. We bring technical and commercial perspective; your team brings the context a system cannot discover on its own.
PI Square brings
The work of building.
Technical investigation, solution design, implementation and the evidence needed to evaluate the result.
Process knowledge, appropriate access, feedback from the people using the workflow and an accountable operational owner.
Begin with the people who do the work and the person responsible for its outcome.
Decided together
Scope boundaries / Evaluation criteria / Readiness for live use
02 / Prove
A working demo is a beginning.
The real question is whether it improves the work. Compare it with what happens today, including the effort of checking it and the cases it gets wrong.
Before live use, the review paths, access controls, monitoring and recovery arrangements need to be ready. A promising output alone does not make that decision.
Read the reasoning
Open a line on the evaluation sheet to see why it matters.
Three useful outcomes
Proceed
The evidence supports the next step, with the necessary controls and an accountable owner.
Revise
Narrow the scope, address a dependency or change the approach, then evaluate again.
Stop
The improvement is not convincing enough to justify further work. Keep the findings for future decisions.
Evidence
Evaluation record02 / 03
Illustrative example / Service operations
What would make this useful?
The same request-routing workflow, examined from four angles. These are evaluation questions, not measured results.
01Useful outputCompare suggested categories with the decisions your team would make.Needs representative requests and agreed categories.+
Why it matters
A plausible answer is not enough. Include ambiguous requests and examples the system should pass to a person.
02Human review effortCompare assisted review with the way requests are handled today.Needs a baseline from the current workflow.+
Why it matters
Count the effort of checking and correcting suggestions, not just the time it takes to produce them.
03Operating costExamine model, integration and operating costs against expected use.Needs expected volumes and a defined configuration.+
Why it matters
A useful trial also needs a credible operating cost. Include exceptions, retries and human support.
04Exceptions & recoveryCheck what happens when a request is unclear or a connected system is unavailable.Needs agreed review and recovery paths.+
Why it matters
Test the difficult cases deliberately. Someone must be able to see the problem, take over and restore normal work.
Decision pending · Evidence comes first
02 — The evaluation sheetIllustrative method. No customer results or performance figures are shown.
03 / Embed
The system stays. So does the knowledge.
Putting a system into daily use means making its operation understandable: who uses it, who can change it and what to do when something needs attention.
Your business owns the system. The operating arrangement should be just as clear as the build.
Your team operates it
Agree the handover, access, documentation and training needed by the people taking responsibility.
PI Square support by agreement
Choose optional support with an agreed scope and clear responsibilities.
Expansion is optional. Further improvements are a separate decision, based on evidence and your priorities.
Ownership
Operating pack03 / 03
Illustrative example / Service operations
In your hands.
A guide to running the request-routing workflow and knowing when to intervene.
01
Access & repositories
Where the system lives and who can change it.
02
System documentation
How the parts connect and what they depend on.
03
Runbooks & recovery
What to watch, how to respond and how to recover.
04
Training & limitations
How to use it and where human judgment is needed.
05
Ownership & support
Who is responsible, and how to get help.
A useful workflow can be a complete outcome.
03 — The operating handbookIllustrative contents. Your operating pack follows the agreed scope.
Before we begin.
How do we agree scope and pricing?
Scope and pricing are agreed stage by stage, with combined engagements available. The proposal defines what is included and the timing for your project. The decisions about readiness still matter in either arrangement.
What should we bring to the first call?
One workflow you would like to improve, who is involved and what makes it difficult. A short description is enough to begin; you do not need to upload business records to book a conversation.
What about our data and existing systems?
Access, hosting, retention and model-provider terms are decisions for the engagement scope. Start with the constraints your business needs to meet; those inform which architecture and integrations are appropriate.
What if the work is confidential?
Tell us before sharing confidential material so we can discuss the arrangements you need, including an NDA. Keep the initial booking note general.
What if the trial is not convincing?
We revisit the approach, narrow the scope or stop. Further work needs a reason to proceed. Expansion is optional; one useful workflow can be a complete outcome.
Who owns the code, documentation and system repositories?
We plan for client ownership and operation, with optional PI Square support. The written engagement defines the code, documentation and rights transferred to you, including any third-party components and their licences.
How is data handled during the initial assessment?
Discovery can begin with representative questions and synthetic or non-sensitive samples. Before accessing business data or live systems, we agree the necessary permissions, data protection terms and technical boundaries with your team.
Start with a conversation
Bring one workflow you would like to improve.
30 minutes. With Nikhil or Sanjin, depending on your enquiry.