Automation that takes routine off people's backs, not their jobs
Retyping orders from e-mail into the system, hunting for a price across ten price lists, filling out the same forms over and over — this is work for a machine, not a person. We build automation tailored to your real processes and systems, not generic templates that nobody ends up using.
Routine doesn't just cost time. It costs people and know-how.
These aren't hypotheses from a slide deck. They're things we've seen exactly like this at real companies — and they can be measured in hours and money.
The order arrives by e-mail and someone retypes it
At an IT hardware wholesaler, orders came in by e-mail and the back office retyped them into the system — item by item, day after day. Same with attendance: manual records, prone to errors. The classic work nobody wants to do, where a single typo is enough to cause trouble.
A process engineer spends hours creating near-identical items
At a machine shop, an order arrives as a single top-level item in the ERP. The process engineer then manually downloads a PDF for each part, creates the component items in Helios, saves the drawings, and fills in the routing and the time standard. That's 15–25 assemblies a week, or 70–120 items — all entered by hand.
A salesperson clicks through exports to find a price
At a shading-systems manufacturer, sales pulled data manually from the K2 ERP and from Excel price sheets. Figuring out which products matched a given dimension–material–color–price combination meant tens of minutes of clicking — and with every query, the risk of overlooking a newer version of the price list.
Management signs off, but doesn't know who saw the document
At a trading company, management signed documents over 20 pages long with no assurance they had passed everyone who was supposed to see them. Approvals ran over e-mail, with no audit trail. For commercial contracts that was a real legal risk, not just an inconvenience.
Five layers where a machine handles routine better than a person
Not every automation is the same. These are the five types of problems we solve — each with one real-world example, not a marketing line.
Transactional — data that gets retyped
Extracting data from attachments, syncing CRM and ERP, creating tasks and items, generating quotes. Example: an "e-mail to order" agent that extracts line items from an order in an e-mail and creates it in the system instead of retyping it by hand.
Knowledge — answers hidden in documents
Assistants over your company documentation and know-how. Example: an AI tool that, at a shading-systems manufacturer, answers questions about parameters and prices in natural language, searching across PDF price lists, Excel and drawings — always with the source of the answer.
Reporting — numbers people are waiting on
Data from the ERP or a data warehouse in natural language, without waiting for someone to assemble it by hand. Example: an executive dashboard at an engine manufacturer, where the managing director finally had a "helicopter view" instead of data scattered across Helios, SharePoint, Outlook and WhatsApp.
Communication — questions that keep coming back
Chatbots and inquiry handling on the web, by e-mail or via WhatsApp, even 24/7. Example: drafted replies to recurring e-mails and a chatbot that filters incoming mail so only what matters reaches people.
Monitoring — deadlines and deviations that slip through
Watching for deadlines, deviations and events you'd otherwise catch too late. Example: a data layer over the company's processes that maps what's happening and flags a deviation on its own — but leaves the decision to a person.
Four phases that protect you from an expensive mistake
We never start with "let's deploy AI." We start by measuring what the process costs you today. Each phase has a single job — to make sure the next step rests on something proven, not on hope.
1. Analysis — first we measure what it costs today
A detailed map of the process: where exactly the routine arises, what the inputs look like (ERP exports, price-sheet structure, the layout of stamps on drawings), where duplicates and old versions are created. Plus a baseline of time, cost and quality. Without that number there's no point calculating the return — and we do want to calculate it.
2. Pilot — we prove it in the real world, not on paper
A quick prototype in live operation, on real data and real documents. At the machine shop this is preceded by an entry audit of 5–10 actual drawings, so we know whether different customers use different stamp layouts — because reliability and price hinge on that. The pilot answers a single question: does it really work?
3. Implementation — connecting to your systems and roles
Deployment and integration into what the company actually uses: existing systems, data, roles and decision points. The solution isn't built next to the company but into it — including who approves what and where a person has the final say.
4. Support — operation, measurement and tuning
Automation isn't handed over and forgotten. We run it, evaluate it and optimize it. For the data platform over K2 we therefore included two years of hosting in the price and placed the source code with the supplier with a buyout option — the solution is a long-term, managed layer of the company, not a one-off toy.
Knowing where to deploy a machine and where to leave a person is an expertise in itself
The difference between a working and a broken solution often isn't the models or the tools. It's deliberate decisions about where to trust the machine and where, on purpose, not to. This is work people pay for.
We deliberately don't read what the machine reads unreliably
For the machine-shop process-planning agent, we decided not to read dimensions from complex drawings — OCR is unreliable there. Instead we read only the corner stamp and the bill of materials, where recognition is reliable. A less ambitious scope, but a solution you can trust.
What only a person can see, we leave to a person
Only a process engineer can reliably read the sheet thickness or the number of bends from a drawing. That's why there's a dialog with a PDF preview where they fill that value in. The data is collected into a CSV and an import creates the structure in the ERP. The machine handles the routine, the judgment stays with the person.
Realism is part of the contract, not a promise
A good solution accounts for reality. For the data platform over K2, deadlines therefore shift contractually for client-side delays (ERP data) as well as for vacations and holidays. No fantasy dates that nobody would meet anyway.
The agent recommends, the person decides
For us, AI isn't a black box that decides on its own. It's a tool that prepares the work and hands it to a person wherever judgment or accountability is needed. That's not a limitation — it's the reason it can be trusted.
The agent creates the structure, the engineer fine-tunes it
The process-planning agent reads the stamp and the bill of materials, finds similar existing items, creates the component structure, and even carries over the routing and the time standard from the original item. The process engineer then only checks and fills in what truly requires human judgment.
The system records it, but the person signs
In digital contract approval, the system logs who clicked "Approved" and when — and won't allow approval until the user has opened the document. It even measures how long after opening they approved, as proof of genuine reading. The actual electronic signature, however, stays with the person.
It maps and alerts, but doesn't decide
The data and AI layer over the processes detects a deviation and flags it. What happens with the deviation is always a person's decision. This is the difference between a trustworthy tool and a system nobody in the company believes.
We connect to what you have. We address security from the start. And we always measure.
Three things that separate a serious project from a demo: we build on your existing systems, security is part of the design, and every solution has a baseline and a defined benefit.
We build on your systems, we don't replace them
We genuinely connect to ERPs (K2, Helios, Business Central), SharePoint, Microsoft 365, accounting systems, PDM/CAD, e-mail and WhatsApp. For orchestration we primarily use n8n, plus Make, Zapier, Power Automate or Copilot Studio. We don't force the company to change the tools it's used to.
Security is in the design, not bolted on at the end
Data stays with the company, transfer and storage are encrypted, and the solution respects GDPR and Czech law. For sensitive data we offer on-prem or local models. It includes an "AI traffic light" — clear rules on what may and may not go into AI. In regulated industries this is a requirement, not a bonus.
No solution without a baseline and a defined benefit
We measure process and response time, cost per transaction, output quality, error rate and rework, and team capacity. A typical payback is 3–12 months. Without a number at the start, you can't honestly say whether it makes sense — and we want it to.
A machine-shop company: how we built an agent that creates ERP items instead of the process engineer
Starting point: hours of routine every day
The company manufactures parts for large foreign customers. An order comes in, and in the Helios ERP only the top-level project item is created, with the data uploaded (PDF, DWG, DXF). The process engineer then manually downloads a PDF for each part, creates the component items in the ERP, builds the item structure, saves a PDF for each item, and fills in the routing and time standard. Weekly that means 15–25 assemblies, or 70–120 items — all very similar, and all created and retyped by a person.
Entry audit of real drawings
Before even quoting, we went through 5–10 actual PDF drawings to verify whether different customers use different corner-stamp layouts. Reliability and price depend directly on that. So we build the pilot on a single main customer, where the stamp is uniform and recognition is the most reliable.
A deliberate decision: what to read and what not to
We decided not to read dimensions from complex drawings — OCR is unreliable there and would introduce errors. We read only the corner stamp and the bill of materials (name, drawing number, steel grade, weight), where recognition is reliable. That decision is an expertise in itself: it keeps the solution within bounds where it can be trusted.
The agent creates the structure and carries over the standards
The agent loads the PDF of the top-level item, reads the stamp and the bill of materials, uses the bill of materials to find similar existing items in the ERP, and creates the component structure — including carrying over the routing and the time standard from the original item. The similarity search runs over fields on the master record plus metadata from the form. Helios is connected via API per the Wiki documentation.
Human-in-the-loop where the person decides
Whatever isn't machine-readable — such as sheet thickness or the number of bends — the process engineer fills in via a dialog form with a PDF preview: they see the drawing, pick a category from a pop-up and enter a numeric value. The added metadata is collected into a CSV, and an import into the ERP automatically creates the item structure. The machine handles the routine, the judgment stays with the person.
Splitting into phases and the result
We split the project into two phases: first the manufactured items, then in the second phase the purchased and standardized parts, with the option to extend it to pricing as well. The result: from hours of routine retyping across 70–120 items a week to an agent that creates the structure and carries over the standards — and the process engineer now only checks and fills in what truly requires human judgment. A competing bid for the same use case was, on top of that, more expensive.
Got a process that's eating your people's time?
Tell us what keeps getting done over and over at your company. We'll design a solution and calculate how much it pays back.