Where should the model sit in our stack?

Behind capture and beside the hub, not in front of the CRM. The CRM stays the system of record. The model proposes, the hub decides, the CRM stores what was decided and why.

What happens when the model is slow or down?

The integration falls back to a rule or a human queue, and the record still moves. If your design has no answer to this question, an outage becomes lost leads rather than delayed ones.

How do you stop duplicate records?

Idempotency keys on every write and deduplication before assignment. Webhooks retry by design, so any integration that assumes exactly-once delivery will eventually create duplicates.

Can you integrate with our custom internal system?

If it has an API and we can get a sandbox, yes. If there is no sandbox, we will not put an integration into production, because the first real test would be with your live data.

When is integration the wrong answer?

When the underlying data is inconsistent. Wiring a model into three systems that disagree about what a lead is produces faster disagreement. Fix the definitions first, which is cheaper than any integration.

Services

AI Integration Services

AI integration means wiring a model into systems you already run, rather than replacing them. OperStack places the model behind your existing capture and CRM, scopes what it may write, and makes every call inspectable so a wrong answer can be traced instead of argued about. Most engagements take 2 to 5 weeks depending on the number of systems.

Entry point	Setup · Custom quote Custom quote. Scope depends on how many boundaries need contracts.
Typical timeline	2 to 5 weeks depending on the number of systems Depends on how much of your data is already clean.
Updated	September 8, 2026 Reviewed by Maksim Shchegolev

Integration is a contract problem

The model is rarely the hard part. The hard part is the boundary: what exactly goes in, what is guaranteed to come out, what happens after four seconds, and who is responsible when the shape changes.

We write that contract per boundary, in plain language, before any code. Teams that skip it end up debugging by reading logs from three systems that each believe they succeeded.

The CRM stays the system of record

A common and expensive design puts the model in front of the CRM, writing records directly. Now the CRM contains values nobody can explain, and there is no layer that remembers what was true at the moment of capture.

The model proposes. The hub decides using inspectable rules. The CRM stores the decision and the evidence. That boundary is the subject of Lead Hub versus CRM.

Retries are not optional

Every webhook provider retries. That is the correct behaviour on their side and a duplicate record on yours unless you designed for it.

Idempotency keys, deduplication before assignment, and a dead letter store for payloads that never parse. None of this is glamorous and all of it is what separates an integration that survives a bad week from one that quietly loses a Tuesday.

When we will tell you not to integrate

If your form, your hub, and your CRM disagree about what counts as a lead, integration makes the disagreement faster and more visible, which feels like a regression.

The cheaper first step is a shared definition and a reconciliation count, described in the inbound lead audit. Integration after that lands cleanly.

What the engagement covers

Integration map: where the model sits relative to capture, hub, and CRM
Contract per integration point: expected input, guaranteed output, timeout behaviour
Write scoping: which fields the model may set, and which stay human or rule driven
Idempotency and retries, so a duplicate webhook does not duplicate a record
Fallback behaviour when the model is slow or unavailable, tested before launch
Logging and alerting on the integration boundary, not only inside the model

What you keep

Integration contracts in writing, one per boundary
Test payloads that exercise the timeout and failure branches
A monitoring view that shows the failure rate per integration point

What this does not cover

Replacing your CRM or form stack. Integration means working with what exists
On-premise model hosting. We integrate hosted models and say when that is a poor fit
Integrations we cannot test. If we get no sandbox, we will not put it in production

If one of these is the actual problem, say so on the audit call and we will point you somewhere better rather than sell you the wrong module.

Start with the written assessment

Free and in writing: send the site and how inbound works today, get the gap we see, the module that fixes it and a fixed price within two working days. No call at this stage.

Send the form → Pricing

Frequently asked questions

Where should the model sit in our stack?: Behind capture and beside the hub, not in front of the CRM. The CRM stays the system of record. The model proposes, the hub decides, the CRM stores what was decided and why.
What happens when the model is slow or down?: The integration falls back to a rule or a human queue, and the record still moves. If your design has no answer to this question, an outage becomes lost leads rather than delayed ones.
How do you stop duplicate records?: Idempotency keys on every write and deduplication before assignment. Webhooks retry by design, so any integration that assumes exactly-once delivery will eventually create duplicates.
Can you integrate with our custom internal system?: If it has an API and we can get a sandbox, yes. If there is no sandbox, we will not put an integration into production, because the first real test would be with your live data.
When is integration the wrong answer?: When the underlying data is inconsistent. Wiring a model into three systems that disagree about what a lead is produces faster disagreement. Fix the definitions first, which is cheaper than any integration.