What we integrate with,
and where your data sits.
The questions that decide whether a build is viable, answered before you ask them. How we connect to what you already run, what the delivery looks like, and how engagements are scoped.
We build into your stack, not beside it.
The default failure mode of operational AI is a parallel system nobody opens. We don’t introduce a new interface for your team to adopt. Work happens where it already happens — inside WhatsApp, inside the spreadsheet the team already maintains, inside the accounting or booking system already in use — and the AI sits behind it. Adoption isn’t a change-management exercise because there is nothing new to log into.
Where a system exposes an API, we integrate directly. Where it doesn’t, we work through the interfaces it does expose. The mapping phase establishes which of these applies before anything is committed to.
Self-hosted by default. No lock-in.
Automations run on n8n, self-hosted. The workflows are portable artefacts, not proprietary configuration held inside our account, so ending the engagement doesn’t end your access to what was built.
| Category | Where it lives | Retention |
|---|---|---|
| Operational data processed by automations | Your systems and the self-hosted runtime | Governed by your own systems |
| Project and account records | SolvTreeAI | Duration of engagement, plus a reasonable period after |
| Payment details | Razorpay (PCI-DSS compliant). Card details are never stored by us | Held by the gateway |
| Billing records | SolvTreeAI | 7 years, as required by applicable tax law |
Access to client data is limited to authorised personnel and to service providers bound by contract. Full terms are in the privacy policy.
Mapped first, then built.
Most operational AI fails because nobody mapped the operation before automating it. The sequence is fixed:
| Stage | What happens | Timeline |
|---|---|---|
| Map | Operational audit. Where work queues, where decisions bottleneck, where revenue leaks. You keep the scored breakdown regardless of what follows. | Day 1 |
| Fit | Design against the existing stack. Team trained during the build, not after it. | Days 3–7 |
| Run | First system live. Expansion reviewed monthly against what the data shows. | Days 11–14 |
Scoped to the work.
Three shapes, depending on what the map turns up. A single focused automation where one process is clearly the constraint. A multi-system build where several processes interlock and have to be sequenced. An ongoing programme on a monthly retainer covering hosting, optimisation and new builds as the operation changes.
The operational audit is free and carries no obligation. Pricing follows the scope the audit establishes, so it isn’t quoted before there’s something to quote against.