Use cases
Choose your industry. You will see the typical bottlenecks, what we built for them and an example from a real project. Client names stay confidential; the figures come from the projects.
Typical bottlenecks
What we built for it
The appraiser dictates at the vehicle. The system turns this into structured case data and writes it into the claims system once the appraiser approves.
An image model assigns each photo to a report category. We measured it against the assignments in past reports.
Names and personal data disappear from PDFs and images before a sample report is shared. The text is removed from the file itself.
Example from a project
| Metric | Before | After | Method |
|---|---|---|---|
| Photo categories correct | 11 / 18 | 15 / 18 | Compared with past reports |
| Time per photo | by hand | < 15 s | 20 real cases, acceptance criterion |
| Office time per case | evenings | 2.5 h | Target in the contract |
| Overwritten fields | Test 1: yes | 0 | Write single fields only |
In the first test the system wrote whole records back and emptied fields that were already filled. Since then it writes single fields only, and the appraiser creates the report in the system personally.
Before building, we ran an on-site potential check. It produced a nine-page process report with levers, effort and price.
Frequently asked questions
We write through the system's interface and only into single fields. Fields that are already filled stay unchanged.
On our own servers in Germany or in your infrastructure. We set this out in the contract, together with the data processing agreement.
The appraiser. Nothing goes into the claims system without the appraiser's approval.
Requests run across several providers with a fallback. If one fails, the next one takes over.
Typical bottlenecks
What we built for it
Before any code is written, we fix where the system talks to the practice software. For this we mapped the interfaces in 18 vendor specifications.
Names and personal data disappear from PDFs and images before a document is shared.
A portal in which each client has a sealed-off search space over their own documents.
Example from a project
Unclear which data a system may read and write
Every interface documented with version, permissions and data processing agreement
| Input | Vendor interface documentation, practice workflows |
|---|---|
| Output | Integration architecture with a fallback through the user interface |
| Stack | Interface analysis · UI automation · version pinning · DPA |
| Measured | 18 specifications, every interface with a pinned version |
| Limit | Without an open interface, only the user interface remains |
Frequently asked questions
We check your vendor's interfaces first. Where there is no open interface, the system works through the user interface, with a pinned version.
On our own servers in Germany or in your infrastructure. We set this out in the contract, together with the data processing agreement.
A person on your team. Before anything is written back to your systems or sent out, a person approves it.
Typical bottlenecks
What we built for it
New properties from the agency system are on the website within 15 minutes. Before that, about 1,950 records moved into the new CRM.
Emails are read, classified and matched to the right card. The system writes replies as drafts.
Contracts, minutes and reports searchable in plain language, kept separate for each client.
Example from a project
Listings maintained on the website by hand
Import every 15 minutes, with no manual step
| Input | OpenImmo export from the agency system |
|---|---|
| Output | Up-to-date property pages on the website |
| Stack | OpenImmo · Python · scheduled import · CRM migration |
| Measured | About 1,950 records migrated, import every 15 minutes |
| Limit | Images and texts arrive as the agency system delivers them |
Frequently asked questions
The import reads the OpenImmo format, which common agency software exports.
On our own servers in Germany or in your infrastructure. We set this out in the contract, together with the data processing agreement.
A person on your team. Before anything is written back to your systems or sent out, a person approves it.
Typical bottlenecks
What we built for it
Web search, reading company websites and scoring every contact against fixed criteria, with a cost cap per run.
Emails are read, classified and matched to the right card. A browser extension fills in web forms.
Five language models assess the same question without seeing each other's answers. A sixth combines the verdicts.
Example from a project
Research by hand, priority by gut feeling
Every lead with a score and a reason
| Input | Target industries, region, scoring criteria |
|---|---|
| Output | Prioritised list with a reason for each lead |
| Stack | Web search · scraping · LLM scoring · cost cap |
| Operation | Resumable, with a cost cap per run |
| Limit | The sales team sets the criteria |
Frequently asked questions
Always a person. The system writes drafts, and nothing is sent before approval. Forms are submitted by a person too.
On our own servers in Germany or in your infrastructure. We set this out in the contract, together with the data processing agreement.
Requests run across several providers with a fallback. If one fails, the next one takes over.
Typical bottlenecks
What we built for it
A portal with a sealed-off search space for each client. We made German-language search reliable with multilingual embeddings.
Names and personal data disappear from PDFs and images. The text is removed from the file itself, so nothing is hidden under a black box.
One decision question with its documents, five independent verdicts, one combined report as a PDF.
Example from a project
Sample reports with personal data that nobody was allowed to share
People as [PERSON 1], number plates as B-XX ####E, amounts and dates stay
| Input | PDFs, scans and images with personal data |
|---|---|
| Output | Redacted files with the content still readable |
| Stack | PyMuPDF · offline text recognition · rule engine · own server |
| Operation | Offline text recognition, results deleted after 30 minutes |
| Measured | Originals held in memory only, check recognition on every page |
| Limit | Text recognition barely reads handwriting, so give files a quick look before sharing |
Frequently asked questions
No. Text recognition runs offline on our server. Originals are never stored, and results are deleted after 30 minutes.
On our own servers in Germany or in your infrastructure. We set this out in the contract, together with the data processing agreement.
A person on your team. Before anything is written back to your systems or sent out, a person approves it.
How a project runs
Acceptance criteria are written into the contract, for example under 15 seconds per photo, tested on 20 real cases.
The potential check shows you, with a prioritised plan you keep.
Get in touch Calculate your potential