AI in processes
AI can help. The question is where exactly: a language model reads, sorts, summarises and drafts — reliably wherever people today keep reading the same kind of text and making the same kind of decision. In support, in lead generation, in product data maintenance, in enquiry and campaign management, in order processing and in accounting. It cannot guarantee that it is right, and it should not decide where a decision has consequences for people. Sharpness Solutions GmbH in Oldenburg has been building shops, websites, custom software and the interfaces between them since 1999. AI is one building block among others here: connected to your data, with approval steps, logged, and on request on our own servers in Germany. This page shows which processes it works for today, what to watch out for, and what a start looks like that can be measured.
The areas of use below have one thing in common: there is a volume of recurring tasks in which text is read, sorted or written, and there is data in the company that the AI can be tied to — product master data, ticket history, price list, manual. Where both are missing, the effort rarely pays off. Where both are in place, a well-connected model saves minutes per task, and those add up.
Incoming tickets are pre-sorted by topic, product and urgency and assigned to the right team. For standard questions the AI drafts a reply from your knowledge base and past tickets, with a reference to the source. The employee checks it, changes it and sends it. Recurring topics become visible before they turn into a wave.
Research on companies, industries and contacts from public sources, summarised in a profile. Draft letters that address the company instead of a list. Scoring of incoming leads against fixed criteria that you set — size, region, system landscape. What the AI does not replace: the conversation.
Product texts from attributes, data sheets and manufacturer texts, in your tone of voice and tied to the source values. Spotting missing attributes, suggesting categories, generating alt texts and image descriptions, translations for further languages. Ten thousand products are then no longer a three-month project but a three-week one with spot checks.
Emails and form submissions are read, classified and assigned to the right department: quote, complaint, delivery status, job application. Missing details are recognised and drafted as a follow-up question. Anyone who used to spend an hour every morning sorting the inbox finds the cases already sorted, with a draft.
Target groups from existing customer and purchase data, text variants for ads, newsletters and landing pages, results explained in plain language instead of tables. The AI suggests which variant should run and why; the decision on budget and messaging stays with you. A direct fit with our Google Ads and SEO services.
Orders arrive as PDFs, as email text, as a photo of an order form or by fax. The AI reads out line items, quantities, delivery address and requested date and passes them in structured form to the ERP or shop. Unclear items go to a person with a flag. This is process digitalisation with a new tool for the last gap: the unstructured document.
Incoming invoices and delivery notes are captured, line items matched to the purchase order, deviations in quantity or price reported, pre-coding suggested. The posting itself is done by your system, the approval by a person. What used to be retyping becomes checking.
Supplier price lists come in every format — Excel, PDF, catalogue page. The AI reads them in, matches products against your master data, detects changes in price, minimum quantity or lead time and prepares the import. Delivery commitments and delays from emails end up on the case instead of in the inbox.
From the enquiry, price list and your text blocks a draft quote is produced with line items, description and delivery terms. The AI checks for completeness — whether the delivery address, the delivery date or the payment term is missing — and flags deviations from the standard. Costing rules stay your rules, stored in the system, not guessed.
Manuals, contracts, project documentation, old emails and wiki: a search that answers questions in full sentences and names the source, page and paragraph. Only across your documents, with your access rights — anyone not allowed to read a document gets no answer drawn from it either. Onboarding new colleagues gets shorter, searching through folders rarer.
Figures from shop, ERP, CRM and Matomo become a report in plain language: what has changed, where something stands out, what needs checking. In the inbox at eight on Monday, instead of built by hand on Friday. The system calculates the figures, the AI explains them — not the other way round.
An assistant that advises from your product data: which spare part fits this device, which variant meets this requirement. Tied to the product master data so that it does not invent properties, and labelled as AI, as the AI Act requires. For B2B shops with products that need explaining, often the shortest route to fewer follow-up questions.
Duplicates in the customer master, products with missing mandatory fields, contradictory details between shop and ERP, addresses in three spellings. The AI finds and suggests, you decide. Often the most sensible first step, because every later use of AI is only as good as the data it is tied to.
Language models are good at three things: they understand text, including messy text, in many languages and formats. They bring it into structure — category, fields, summary, scoring against criteria. And they draft text that fits a brief: a reply, a description, a letter, a report. All three abilities work on tasks that occur in large numbers in companies every day, and in all three the result is a suggestion that a person can check in seconds. That is why the areas of use above work: not because the AI is smarter than the employee, but because it takes over the first eighty per cent of each task, which used to be routine.
What a language model cannot do: guarantee facts. It phrases things fluently even when it is wrong, and it does not know what it does not know. It calculates unreliably when it has to calculate without tools. And it does not know your company — your products, your prices, your rules, your customers — unless someone connects it to them. Three rules follow, which we apply in every project: the AI is tied to your own data and cites it, instead of answering from memory. Whatever calculates is calculated by the system, and the AI is given the result. And every output with external impact — an email to the customer, a quote, a product text in the shop — goes through an approval, at least until the error rate has been measured in the pilot and you decide where it may run without approval.
The difference between a tool that helps in daily work and one that nobody uses after three weeks rarely lies in the model. It lies in the connection: does the AI have the product master data, the ticket history, the price list? Does the suggestion appear where the employee already works — in the ticket system, the shop back end, the ERP — or in yet another window? Is it logged what it suggested and what the person changed, so that both can be improved? These are questions of software development and interfaces, not of AI. That is why the topic sits with us where process digitalisation and custom software sit.
A use of AI that delivers something has three parts: the data, the model and the place where the result lands. The data comes from the systems you have — Shopware or Magento, TYPO3 or WordPress, an ERP such as Sage, Microsoft Dynamics, SAP Business One or an industry-specific system, a CRM, the ticket system, your mail server. We know these interfaces from more than 250 projects since 1999 and build them so that the AI reads what it needs, and only that. We choose the model by task and data protection requirements: a large model from a provider via an interface, an open model on our servers, or, for simple classification, a small one that answers in milliseconds and costs nothing.
The result has to land where the work is done. For Shopware that means an extension in the administration area that shows the product text suggestion next to the product; for TYPO3 a back-end module; for an ERP a field or a case with the status “suggested”. For workflows between systems we use an automation platform such as n8n on our servers or build the workflow as a service of its own, with a queue, retries on errors and a log in which every step can be traced. Approvals are a step of their own in the workflow, not a note in an email. And if the model does not respond one day, the process carries on without AI, as before — just more slowly.
Anyone already using AI, say through a plugin or a subscription service, often faces a different problem: it runs, but nobody knows which data goes there, what it costs per month and whether the results are getting better. We review such solutions, measure cost and error rate and tell you whether they should stay, be connected properly or be replaced by something of your own that belongs to you. In the end the code sits in a Git repository that belongs to you, and the domain is always in your name. That applies to AI building blocks as to everything else we build.
There are processes in which the AI may pre-sort and pre-draft, but the decision stays with a person — not out of caution, but because mistakes there cannot be undone or because the law requires it. This includes all decisions about people: job applications, appraisals, dismissals, creditworthiness. The AI Act classes AI systems in the HR area as high-risk, and the GDPR, in Article 22, prohibits automated decisions with legal effect without human involvement. An AI may therefore sort applications by formal criteria that you have set; it may not decide who is invited.
This includes prices and terms, unless they are formed according to stored rules: a model that prices a quote “reasonably” is guessing. A system that applies your costing rules and lets the AI only write the description is calculating. It includes legal questions — contract clauses, notice periods, reminders with legal effect — and anything that contains commitments to customers, such as delivery dates or warranties. For these cases we build the four-eyes step in firmly: the AI supplies the draft and the reasoning, the person approves, and both are logged.
A limit of a different kind is expectation. AI does not make a bad process good, it makes it badly faster. If enquiries end up in five inboxes and nobody is responsible, a model that reads the enquiries does nothing for you at first. That is why every project with us starts with the process, not the tool: who does what today, where does it get stuck, which information is missing at which point. Often the first step is an interface or a form with mandatory fields, and the AI comes second. That is less spectacular, but it is the reason why process digitalisation has worked for us for years.
The first question with any use of AI: which data leaves the company, and where does it go? A support ticket contains names, addresses and sometimes more; an order contains customer data; a contract contains trade secrets. If something like that goes to a provider in the USA, you need a data processing agreement under GDPR Article 28, a legal basis for the transfer and the assurance that the data is not used for training. Large providers offer this in their business tariffs, with data centres in the EU; the standard offerings for private users do not. We check this per provider and tariff and document it for your record of processing activities. What does not need a provider gets none: much can be done with pseudonymised data, where names and customer numbers are replaced by placeholders before the model and put back afterwards.
The other option is to bring the model in-house. Open models run on our own servers in the Hetzner data centre in Falkenstein, Germany, on our Proxmox cluster with Docker, monitoring and backups. The data then does not leave your environment, there is no dependence on a provider’s tariff and price list, and the costs are predictable. For classification, extraction from documents, summaries and search across your own documents, these models are sufficient today; for demanding texts in customer-facing language, the large providers’ models are often still better. Which combination fits is decided in the pilot, with your data and measured, not from a data sheet.
The AI Act, the EU’s AI regulation, has been in force since August 2024 and applies in stages. Since February 2025 certain practices have been banned, and companies must ensure that staff who use AI have sufficient AI literacy. AI systems that interact with people must be recognisable as such — so an advisory assistant in the shop introduces itself as AI. High-risk applications, for example in HR, are subject to special obligations. The areas of use on this page lie very largely outside the high-risk area; where a project comes close to it, we say so beforehand. The legal assessment lies with you and your data protection officer; we supply the technical basis: which data flows where, what is logged and how the human stays in the loop.
A start does not begin with an AI strategy but with a process. We pick it together using three criteria: it occurs often, it noticeably costs time today, and the data the AI has to be tied to is available or can be obtained with reasonable effort. Often this is the inbox, product data maintenance or the reading of orders and invoices. For that one process we define what is measured: minutes per task, share of suggestions accepted without change, turnaround time, errors that reach the customer. Without these figures it is impossible to say afterwards whether it was worth it.
The pilot runs with real data and real employees, on a limited part — one product group, one mailbox, one supplier list. Four to six weeks are usually enough to know the error rate and to see whether colleagues use the tool or work around it. Both are results. During this time we adjust the model, the connection and the settings until the figures are right or it is clear that they will not be. Then you decide: roll out, adjust or drop. What is rolled out goes into operation like any other software with us: with monitoring, logging, updates of models and dependencies and, on request, a service level agreement.
For operation, the same applies as for shops and websites: maintenance with an SLA in the tiers BASIC, STANDARD and ADVANCED with 24, 8 or 4 hours’ response time, each booked for one year; the work by time and materials or within an agreed scope of hours. Without an agreement we deal with requests within 48 hours during our business hours of Mon–Thu 9:00–16:00, Fri 9:00–13:00 (CET). Sharpness has existed since 1999, with IT liability insurance and a team in Oldenburg that builds shops, websites, custom software and interfaces. AI is not a business of its own for us, but one more tool in the processes we have been digitalising for years. That, we believe, is the right attitude towards it.
Process
Tell us where time is lost in your workflows — inbox, product data maintenance, invoices, support, lead generation. You get an initial assessment with no obligation: where AI helps you today, what comes first and what a pilot would look like. Phone +49 441 21 21 63 0, Mon–Thu 9:00–16:00, Fri 9:00–13:00 (CET). We work remotely across Germany, with meetings in Oldenburg and the north-west by arrangement.
You describe your processes and where time is lost: inbox, product data maintenance, invoices, support. We tell you where AI helps today, where an interface or a form comes first and what we do not recommend — with no obligation, by phone or on site.
Together we choose the process to start with: frequent, time-consuming, with data available. We define what is measured — minutes per task, share of suggestions accepted, error rate — and which data may flow where.
Which systems supply the data, which fields contain personal data, what is pseudonymised, which model comes into question: a provider with an EU data centre and a data processing agreement or an open model on our servers in Germany. Documented for your record of processing activities.
Four to six weeks on a limited part: one product group, one mailbox, one supplier list. The suggestions appear where the work is done, with an approval step and a log. We adjust until the figures are right or it is clear that they will not be.
You see the measured figures and decide: roll out, adjust or drop. On rollout we connect the further areas, define where suggestions may run without approval and train the team, as the AI Act requires.
Monitoring, logging, updates of models and dependencies, cost control per task and a fixed contact. On request with a service level agreement — on our own servers in Germany or in your environment.
Projects on this system
A selection — not the full client list.
Where many similar tasks involve reading or writing text and the necessary data is in the company. In practice that is usually three places: the inbox with enquiries, orders and invoices; product data maintenance with product texts, attributes and translations; and support with recurring questions. There, a connected model saves minutes per task, and the error rate is easy to measure because a person sees the suggestion anyway. Less suitable are rare, complex tasks and anything that involves decisions about people or commitments to customers. Which process comes first for you, we clarify in the initial call — with no obligation.
It replaces the routine parts, not the job. A model pre-sorts, fills in and drafts; checking, deciding and speaking to the customer stay with the person. In the projects we see, the work shifts from retyping and searching to checking and clarifying — and the volume a team can handle rises. What matters is that colleagues help shape the tool: anyone who has used it for four weeks in the pilot says very precisely what is missing. The AI Act in any case requires that staff who use AI are trained for it. With us that is part of the rollout.
That depends on the tariff and the contract, not on the product name. The standard offerings for private users are unsuitable for customer data: no data processing agreement, use for training depending on the setting. The business and API offerings of the large providers include data processing agreements under GDPR Article 28, processing in EU data centres and exclusion from training. Personal data may then go there if there is a legal basis and it is listed in the record of processing activities. Much can also be pseudonymised, so that the model never sees names and customer numbers. For confidential content — contracts, costings, development data — we recommend a model on your own servers. The legal assessment lies with you; we document the data flows for it.
Yes. Open models run on our servers in the Hetzner data centre in Falkenstein, Germany, or in your own environment. For classification, reading documents, summaries and search across your own records they are sufficient today; for demanding texts in customer-facing language, the large providers’ models are often still better. A combination is often sensible: the own model handles everything that contains customer data, a provider’s model writes the product text from pseudonymised input. What fits is decided in the pilot with your data. Own models need computing power, which we provide; in return the costs are predictable and independent of a provider’s tariff changes.
The EU AI regulation has applied since August 2024 and classes systems by risk. For users in the areas described on this page, three points matter most: since February 2025, staff who use AI must have sufficient AI literacy — in other words, be trained. AI that interacts with people, such as an advisory assistant in the shop, must be recognisable as AI. And applications in the high-risk area, which includes HR, are subject to special obligations that we advise against taking on lightly. Support, product data maintenance, invoice capture or reports do not fall into that area. The legal classification of your specific project lies with you and your data protection officer; we supply the technical description for it.
Through connection, limits and checking. Connection: the model gets the facts from your systems — product master data, price list, ticket history, manual — and has to refer to them instead of answering from memory. Limits: for a product text it may only name properties that are in the record; for a search in the manual it has to give the source. Whatever calculates is calculated by the system, not the model. Checking: every output with external impact goes through an approval, and in the pilot we measure how often a suggestion is accepted unchanged and how often it was wrong. An error cannot be ruled out entirely — with people neither. But it can be made visible and rare.
Because a plugin is usually an island: it writes a product text from what is in the product, but knows neither your data sheet nor your tone of voice nor the question the customer is actually asking. And because often nobody knows which data flows there and what it costs per month. We review existing solutions, measure cost and error rate and tell you whether they should stay, be connected or be replaced by something of your own. Often the answer is: keep it, but tie it to data sheets and rules. Sometimes it is: replace it with an extension that belongs to you and does what your process needs.
We give prices after the initial call, once process and data situation are clear. As a rough guide: a pilot for one process takes four to six weeks and runs on a limited part; afterwards you know the error rate and the time saved and decide on figures. The running costs depend on the model: providers charge per processed text, own models need reserved computing power. We make both transparent per task, so that you know what a handled enquiry or a generated product text costs. We bill the work by time and materials or within an agreed scope of hours; in operation the terms of our maintenance with an SLA apply.
With both, and usually it is about how they work together. We have been building interfaces between shops, ERP systems, CRM and industry software for years; the AI is one building block in that workflow. An order from a PDF is read out, matched against the product master data in the ERP and created there as a case; an invoice is captured and matched to the purchase order; a product text is produced from the data in the ERP and lands in the shop. The prerequisite is access to the system — interface, database or export. Which systems we know and how we proceed is covered on our page on interfaces. Where there is no interface, we can usually find a way.
As with all our software: maintenance with a service level agreement in the tiers BASIC, STANDARD and ADVANCED with 24, 8 or 4 hours’ response time, each booked for one year. We bill the work by time and materials or within an agreed scope of hours. Without an agreement we deal with requests within 48 hours during our business hours of Mon–Thu 9:00–16:00, Fri 9:00–13:00 (CET). The scope includes updates of models and dependencies, monitoring, cost control per task and readjusting the settings when your data or processes change. The code sits in a Git repository that belongs to you.
Enquiry
A few details are enough: which area, which systems, what kind of data. We come back with questions and an initial assessment — with no obligation. Please do not send customer data or access credentials through this form.