Most companies today know that artificial intelligence could, or should, be put to use SOMEHOW. But how do you find the specific spot where it genuinely helps? How do you use AI so that tasks which today take people hours are cut down to a fraction of the time? That's exactly the kind of solution we designed for Lékárna.cz.
The task was listing new products in the e-shop. At first glance a routine internal chore; on closer inspection, a process with a lot of painstaking, repetitive work, but also a lot of room for automation. Using AI, we sped up the listing of new products by more than 40%.
Slow down, analyse, understand
With AI automation it's tempting to jump straight to the solution. Grab a model, write a prompt, plug in an API, and something gets generated. But the result is often a tool that looks interesting yet doesn't help much in day-to-day operation. At Futured, we want to understand the work the automation is meant to improve first.
Some of the questions we want, and need, answers to:
- Who performs the task?
- How often?
- What takes them the most time?
- What's simple?
- Where is the human factor indispensable?
- Where is the sensitive data?
- Where can a mistake absolutely never happen?
The ideal first step is a combination of an initial brief, an in-person meeting, and a workshop that shouldn't involve only managers. We need to talk to the people who actually do the work. It's equally important to have an IT person or team at the table who can tell us what the technical options and constraints are and where the solution can hook in. It's also good to bring in a UX perspective. Automation isn't just what happens in the background. It's just as important that people can easily use it, correct it, and check it.
What it looked like at Lékárna.cz
At Lékárna.cz we were tackling a process that started with varied input data for listing new products. This data had a certain structure, but it wasn't uniform enough to be reliably processed by a simple deterministic approach. In practice we ran into different formats, varying levels of detail, different naming of information, and sometimes additional content that had to be taken into account.
Before automation, this work was done by hand. A person took the source materials and step by step prepared the product content for the e-shop: product name, short description, advantages, benefits, parameters, and other information a product page needs to contain. For some product types, writing a nice piece of text wasn't enough. The texts often follow rules, because this is healthcare. In short: meticulous work with source materials, rules, and checking the result.
A prototype first, not a big system
When we find a suitable process, we don't try to build the final system right away. First we want to quickly verify three things:
- Can we get a good enough output from the available data?
- Is the output usable for the people who'll be working with it?
- Does the solution really save time, or does it just shift the work elsewhere?
That's why it makes sense to start with a prototype. We take a few real inputs and a few expected outputs. On top of those we build a first version that doesn't have to be perfect. It has to be good enough for people to try out and give concrete feedback on. With AI this step is extremely important, because if the final solution is going to be good, it simply can't be designed from behind a desk. It has to be tested on real data. And above all, with the people who'll confirm (or not) that it matches their work.
The prototype
At Lékárna.cz we took several typical products and examples of what a finished output should look like. Based on that, the first version of the tool was created. It wasn't just a prompt in a chat, but a simple working tool in which the user could enter source materials, run the processing, and then check the result.
The goal wasn't for the AI to do everything perfectly right away, but to find out where it helps, where it makes mistakes, and what the workflow around it should look like. The first version gave us feedback we could build on:
- We found out which parts can be automated well.
- We saw where rules needed to be added.
- And the spots where a human must still be able to step in came into sharper focus.
Thanks to that, the prototype didn't become a dead end but the foundation for further iterations. This, by the way, is an experience we now see in most AI projects.
The prompt itself is usually only a small part of the solution. The real value is often created by the system around it: the connection to internal data, databases, company rules, validation mechanisms, or other services. It's precisely this combination that turns an AI experiment into a tool you can safely use in everyday operation.
Automation has to respect people's work
In projects like this, the goal isn't to remove the human from the process, but to remove the routine. The person should stay where judgement, checking, and responsibility are needed. AI should help with what's tedious, repetitive, and data-heavy.
That's why it's important for the user to have control over the process, to see what's being processed. They must be able to add information. They must be able to edit the result. And above all, they must understand what's happening. Good AI automation isn't a black box, but a working tool that fits into the everyday routine of the people who use it.
How the final solution works
The final tool for Lékárna.cz works as a web application. The user drops in the source materials for new products, selects the context needed for generation, and can add further information to be taken into account during processing. The system helps prepare the individual parts of the product page, from the name and short description to advantages, benefits, parameters, and the other texts a listing requires.
The solution also includes working with rules for specific product types. Some texts have to respect constraints that determine what can be claimed about a product. The system therefore helps work with the permitted phrasings and factors them in when creating the final content. In practice, though, it wasn't just about the AI writing nice texts. For some product categories, the content has to meet strict rules. Health claims on dietary supplements are one example. If a product contains, say, vitamin C, you can't just write any claim you like about it, however plausible it might sound. You may only use phrasings that have been officially approved for the given substance, and an incorrect claim can mean not just poor-quality content but also a reputational problem or a hefty fine.
We didn't solve this with a prompt alone. Part of the solution was an integration with a database of approved health claims. The system first identified the active substances contained in the product, then looked up the corresponding approved claims for them, and provided those to the agent as binding rules when generating the text. Thanks to this, the AI didn't rely solely on the model's own knowledge, but on verified data that was part of the whole process.
And the checks don't even end there. The user always has the option to review the result, and the system attaches links to the approved claims it used. That makes it easy to verify what a particular phrasing is based on.
With solutions like this, it's not about blind trust in the AI, but about creating a process that is transparent, traceable, and safe.
Alongside the texts, the process also handles supporting parts, for example preparing product images or translating the content into the Slovak version. What matters, though, is that the user doesn't get just an isolated AI output. They get a ready-made basis for an actual product listing.
Categories and attributes
Another part of the solution helps with processing categories and attributes. For a large e-shop it isn't always easy to correctly determine how a new product should be classified and which information matters for it. Categories and attributes have their own logic, and for a person this means more decision-making, checking, and manual work.
The system therefore helps by recommending suitable categories and attributes based on the available information about the product and the structure the e-shop works with. Here the AI doesn't take over responsibility for the final decision, but prepares a proposal the user can review and adjust. That saves time while keeping control over the content intact.
Quality control isn't a detail, it's the foundation
With classic software we're used to writing tests: when we change something, we want to know we haven't broken functions that used to work. With AI automation it's similar, just more complex. The output isn't always unambiguous, and models can change over time. Their behaviour, quality, and the way they respond to instructions all shift, so you need a way to verify quality on an ongoing basis.
In practice this means collecting reference examples, inputs for which we know what a good output should look like. In English, the word "goldens" is often used for such reference outputs. In Czech we might say zlaté vzorky (golden samples) or reference outputs. These then serve as a control set.
When we change the prompt, model, rules, or part of the system, we can check whether the result got better, got worse, or stayed at an acceptable quality. It's just as important, though, to verify where individual claims come from. It's not enough that the text looks right. In regulatorily sensitive areas we need to be able to document which rule or source a particular phrasing was created from. That's why it's a good idea for the AI to not only generate the output, but also provide references to the rules or data it draws on.
How we did it at Lékárna.cz
Over the course of the project, we collected real examples of inputs and expected outputs. Gradually these became reference cases we could use to verify whether the system was working correctly. It wasn't just a technical check that the application runs without error. What mattered was verifying the quality of the results:
- Does the text contain the correct information?
- Does the text respect the rules for the given product type?
- Are the proposed categories and attributes usable?
- Does the text match the intended style?
This control set was important above all during further changes, because a genuinely functional AI solution evolves: models, prompts, rules, and output requirements all change.
Without reference cases, every change would carry the risk of quietly making something worse. Thanks to ongoing checks, we had a better picture of how the system behaves, and we could develop it with greater confidence.
Feedback from real-world use
The control set alone isn't enough, though. With AI automation it's important to also track what's happening in real-world operation:
- Catch early where the solution is failing, i.e. where people frequently correct the outputs.
- Find out which parts are useful to them and which, conversely, add work.
Only live use reveals the things you can't fully anticipate at the start. That's exactly why it makes sense to capture feedback directly in the process. For example:
- comparing the generated listing with how a person ultimately edited it,
- collecting manual ratings from the people working with the tool,
- tracking common types of corrections,
- and evaluating whether certain errors keep recurring.
Data like this helps you understand how well the solution really works, not just how good it looked in the prototype.
The feedback
At Lékárna.cz, we therefore didn't work only with the first reference examples. We also tracked live feedback from usage. We collected the generated listings and their actually corrected versions. On top of that, we added manual ratings from the people working with the outputs.
That let us see not only whether the system created something, but also how much work was still left for the human.
That matters, because a solution like this is never entirely finished on the day it goes live. At the start we try to capture the main rules, typical cases, and risks well, but only practice shows where the system can improve.
When usage data is captured well, it can produce concrete recommendations:
- what to adjust in the process,
- where to change the rules,
- which parts of the output are weak,
- and where the automation delivers the greatest benefit.
A living solution has to be able to improve
It's best to treat AI automation as a living system, not as a one-off delivered tool that you hand over and the work is done. Models change, inputs change, requirements change, and people gradually learn to work with the tool differently. If we want the solution to work in the long run, it has to have a way to improve.
Over time there can be a lot of feedback: manual comments, text corrections, output ratings, recurring errors, or differences between the generated and final versions. All of that would be hard to go through by hand on a regular basis. The good news is that even this feedback can be processed partly automatically. If the data is stored and described correctly, the system can help find patterns and suggest where it makes sense to adjust the process.
Iterations matter more than the first version
With AI projects, people often talk about models, prompts, and technologies. In practice, though, the most important thing is often the ability to iterate. The first version shows the direction. → People try it out. → They find bugs and say what's confusing, and they surface cases we didn't see at the start. Based on that, we adjust the rules, the interface, the data processing, and the generation itself.
This cycle repeats several times and continues after deployment too. That's precisely the difference between a demo and a usable tool:
A demo shows that something is possible; a product has to work even when a worse input, incomplete materials, an unusual product, or an unexpected case comes along. Without iterations, quality control, and live feedback, it would remain just a nice demo.
What we took away from it
The project was a good illustration of what meaningful AI automation should look like. It doesn't start with technology, but with a process. It doesn't solve everything at once, but starts with a specific bottleneck. It doesn't promise that AI will replace the human, but helps them do the work faster, more consistently, and with less routine.
Involving the right people also matters. We need the perspective of:
- the users who will work with the tool,
- the technical side, so the solution fits into the existing environment,
- UX, so the automation isn't more complicated than the original work.
When these perspectives come together and are complemented by ongoing checks and feedback from real-world use, you get a solution that has a chance of working in the long term.
The result
The listing process became more than 40% more efficient. That's an important result for us, because it shows practical impact. AI automation makes the most sense where a real problem, good knowledge of the process, fast verification on real data, ongoing quality control, and feedback from operation all come together.
Just as important, though, is that the project didn't end at the prototype stage. The first version was created as a standalone tool on which we jointly verified what works, what needs adjusting, and what the whole process should look like. Once the solution proved itself in everyday operation, the individual parts were gradually integrated directly into the internal systems.
That, in our view, is one of the biggest differences between a demo and a successful AI project. A demo shows that something works. But the real value emerges the moment the solution connects with the company's existing processes, data, and systems and becomes a natural part of everyday work.
These are exactly the kinds of projects we love to build. Not deploying artificial intelligence for effect, but designing concrete tools that save people time and help companies do their work better.
–––––
Do you like how we think about technology?
Want to chat about what we could come up with together? Drop a line to Lukáš, who founded Futured:
Lukáš Strnadel – lukas.strnadel@futured.app – +420 605 312 459
.webp)
%20(2).webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.avif)
