Integrations & AI

To begin, it is enough to show how the process runs today — who enters what by hand, and where delays or mistakes appear. On the technical side we need documentation for the systems being connected and access to the relevant accounts; that access is granted from your own accounts and can be revoked at any time. Whether a given system exposes an API at all is something we check ourselves.

The accounts, the domain, the API keys and the code we write stay in your name — we keep none of it on our side. At handover we document which services the integration talks to, how data moves between them, and where each setting lives. That way another team can pick the work up later without having to reverse-engineer it.

What actually reaches the model is agreed openly before the work starts: customer personal data, payment details and sensitive documents are either never sent, or stripped before they are. Model usage is billed directly from your own account, so you can see which provider is in use and how much traffic goes through it. Those boundaries are written down alongside the agreed scope.

We agree on the measures before the work starts: how many operations a day were being re-keyed by hand, how many errors that duplicate entry produced, what share of enquiries was resolved without an agent. After launch we compare the same measures in the same way. We do not promise a number up front — we agree on how it will be measured, so the outcome is not left open to argument.

Providers update their APIs from time to time — that is normal, and it is why an integration is never a one-off job. The scope of support after handover is agreed separately: ongoing cover, or simply calling us when something comes up. In either case we find the cause first, then agree the size and terms of the fix with you.