Start with a workflow you can judge
Good candidates have identifiable inputs, a repeatable task and a person who can judge the output: preparing information from documents, retrieving approved knowledge, drafting an operational response or assisting a CRM workflow.
A pilot is a poor starting point when the underlying data cannot be accessed, no one can define a correct result, or the expectation is to automate consequential decisions without review. We can begin with discovery or an existing-tool assessment when those questions are still open.
What the pilot includes
- A workflow map with the user, inputs, outputs, system boundaries and approval points.
- A scoped integration plan for approved data and tools; sandbox access where available.
- A working pilot around one agreed task, with visible failure and review states.
- An evaluation set and results against agreed quality, review, latency and cost criteria.
- A handover explaining limitations, operational responsibilities and the next production decision.
Connect it to the work your team already does
We assess your CRM, document stores, product APIs and cloud environment before choosing a model or orchestration approach. Our published LuckyTruck work includes Salesforce, Zoho, AWS, carrier quoting and document services. The Document OCR case demonstrates extraction connected to a human review flow.
These are examples of delivery experience, not a claim that every third-party system has a ready-made connector. Access permissions, vendor terms, API limits and the quality of the source data shape the implementation.
Agree the pass conditions before the demo
| Question | Evidence to agree |
|---|---|
| Is it correct? | A representative test set, field/task criteria and a comparison with the current workflow. |
| Does it know when to stop? | Missing-input, unsupported-request and low-confidence cases that enter review. |
| Can it act safely? | A defined tool allowlist, least-privilege access and approval before consequential writes. |
| Can the team operate it? | Useful logs, retry/recovery behavior and a named owner for exceptions. |
| Is the trade-off worthwhile? | Observed task cost, review effort and latency against the agreed baseline. |
How we quote and schedule it
The number of systems, data readiness, evaluation effort, security requirements and deployment scope determine the proposal. We confirm milestones and a delivery window after inspecting those dependencies; there is no universal pilot price or promised completion date.
The first call is free. Paid discovery, pilot implementation and production rollout are defined separately where needed. Model/API usage, third-party subscriptions and cloud costs are identified separately from our service fees. A pilot does not automatically include an unrestricted production release.
Ownership and the decision after the pilot
Before work begins, we agree on intellectual property, repository access, cloud and vendor account ownership, data handling and support responsibilities. Client-owned accounts are discussed during setup so the handover is practical.
The final review can lead to a limited rollout, another evaluation cycle or a decision to stop. Production hardening, additional integrations, monitoring and ongoing support are quoted against the next agreed scope.
Working across time zones
We work remotely with teams in the UK, Europe, the US and Australia. Delivery is in English; working-hour overlap, review cadence, billing currency and any data-location requirements are agreed in the proposal.
