Assessment at a fixed price — credited toward your pilot.
How a request travels · hover or tap a step to trace its path
AI inside the systems you already use
A standalone chatbot that people paste data into rarely becomes part of real work. We connect AI to your ERP, CRM and business systems, including non-standard and legacy configurations where logic lives in settings rather than code. The same team also handles infrastructure and cybersecurity, so responsibility stays in one place.
When you need this
Data is spread across systems
To answer a customer or a manager, someone opens the ERP, the CRM, their inbox and document folders one after another.
Incoming documents are keyed in by hand
Invoices, orders and emails are retyped into the business system, with errors and delays.
Sales reps don’t update the CRM
Call and meeting outcomes stay in people’s heads because filling in a record is slow and awkward.
Your team pastes data into public chatbots
No log, no rules and no idea where your commercial data ends up.
What to connect first
Search across documents and the knowledge base
Employees ask in plain language and get an answer with a link to the document. They see only what they’re allowed to see.
Processing incoming documents
AI reads invoices, orders and emails, fills in the fields and prepares a draft in your business system. A person posts the document.
Voice to CRM for sales
A sales rep dictates the outcome of a contact, AI structures it and proposes a CRM entry. The rep reviews and confirms it.
Onboarding new employees
New team members ask about processes, terms and rules and get answers from your knowledge base, with a link to the source.
How we work
We look at where your people move data between systems by hand and pick a candidate process.
What you get
2–3 candidate processes and a next step.
To move on
There is a process where integration can deliver a measurable result.
Stage 1 of 5 · 60 minutes
We choose a process and map its sources, access channels and permissions. Then we decide where the model runs, how a request travels and what gets logged.
What you get
An architecture diagram, an access map, metrics and a test question set.
To move on
Baseline metrics and the test question set are agreed before the pilot starts.
Stage 2 of 5 · about 2–3 weeks
We connect the model gateway and set permissions at the retrieval stage. At the end we run the test question set built from your cases, including traps for made-up answers. The questions are written by your people who know the process.
What you get
A working scenario on real data for a limited group of users, plus an acceptance record with the answer and source for every question.
To move on
The pilot passes acceptance against the agreed metrics and test set, including traps for made-up answers. Without that, we don’t scale.
Stage 3 of 5 · about 4–6 weeks
We extend to new processes, users and sources. Each extension goes through its own acceptance.
What you get
AI in the daily work of several processes.
To move on
The previous process holds steady on quality and cost.
Stage 4 of 5 · one process at a time
We monitor answer quality and request costs, update knowledge and test new model versions against the test set.
What you get
A regular report on quality, cost and incidents.
To move on
Any change of model or source goes through the test set again.
Stage 5 of 5 · ongoing
We look at where your people move data between systems by hand and pick a candidate process.
What you get
2–3 candidate processes and a next step.
To move on
There is a process where integration can deliver a measurable result.
We choose a process and map its sources, access channels and permissions. Then we decide where the model runs, how a request travels and what gets logged.
What you get
An architecture diagram, an access map, metrics and a test question set.
To move on
Baseline metrics and the test question set are agreed before the pilot starts.
We connect the model gateway and set permissions at the retrieval stage. At the end we run the test question set built from your cases, including traps for made-up answers. The questions are written by your people who know the process.
What you get
A working scenario on real data for a limited group of users, plus an acceptance record with the answer and source for every question.
To move on
The pilot passes acceptance against the agreed metrics and test set, including traps for made-up answers. Without that, we don’t scale.
We extend to new processes, users and sources. Each extension goes through its own acceptance.
What you get
AI in the daily work of several processes.
To move on
The previous process holds steady on quality and cost.
We monitor answer quality and request costs, update knowledge and test new model versions against the test set.
What you get
A regular report on quality, cost and incidents.
To move on
Any change of model or source goes through the test set again.
Connection rules
Standard channels only
We connect through APIs and official data exchange interfaces, never through direct database access that bypasses the license or system rules. At the start AI writes nothing. Write access comes later, and only with human confirmation.
AI never runs on a production server
Development and testing happen on isolated copies. AI has read-only access to live systems, and a person carries changes over.
One gateway to the models
Every request goes through a single entry point with a log, cost limits and a model chosen for the task. You see who asked what and what it cost.
Permissions at retrieval, a source in every answer
Most made-up answers come from retrieval errors rather than the model. So access rights apply before the model sees a document, and every answer links to its source.
What you get
Architecture diagram and access map
Which systems are connected, through which channels, who sees what and where the model runs.
A working scenario on one process
An integration your people use on real data.
Model gateway
A request log, cost limits and rules for choosing a model for each task.
Acceptance record
Results of the test question set, including traps for made-up answers.
User instructions
How to work with the scenario and exactly what a person confirms before anything is written to the system.
Regular support report
Answer quality, actual request costs and changes to the knowledge base.
Case studies
Trading company, EU (import and distribution)
In progress
Task
A non-standard business system where about 80% of process logic lives in the settings of its own process engine rather than in code. An earlier attempt to feed the configuration to AI as a flat folder export produced made-up answers.
What we did
The model works with a copy of the system kept apart from the live one. A register of real system objects carries source labels, and automated checks catch invented commands.
Result: Acceptance was defined before the start: 8 blind tests, including a trap for made-up answers that must be passed 5 out of 5 with no partial credit.
In progress; no impact figures yet.
SENSETI, built for ourselves
Trial operation
Task
Keep our website supplied with material without manual searching and screening.
What we did
An AI content pipeline automatically collects, digitizes and screens material. It runs under a $100 monthly budget cap, with a dry-run mode and manual confirmation.
Result: Actual spend is about $9 a month against the $100 cap.
Start with one process
In a consultation we’ll pick the process where integration pays off first and name the next step.
ERP, CRM and other business systems, including non-standard and legacy configurations where logic lives in settings rather than code. Also documents, email and phone systems. We decide how to connect during the readiness assessment.
No. We connect through standard channels, meaning APIs and official data exchange interfaces. We don’t use direct database access that bypasses the license or system rules.
At the start, AI changes nothing in the system. Anything risky is tried on a copy first, and a person confirms anything written to the live system.
That depends on how sensitive the data is: cloud models through a logged gateway, or local models inside your environment. For EU companies we separately check the processing region and the agreement with the provider.
Every request goes through a gateway with cost limits and a log, and we pick the model to fit the task. During support we report actual spend regularly.
Before the start we agree on metrics and a test question set built from your cases, including traps for made-up answers. Scaling begins only after the pilot passes acceptance.
No. You need a process owner and someone who knows the system. SENSETI handles the infrastructure, security and the integration itself.
