AI Tools in Daily Operations: What We Use for What
Over the last two years we have tried roughly forty AI tools. Six are left.
That is a completely normal ratio. The mistake is in the keeping, not in the trying. Every tool that stays in operation costs money, attention, and an account that at some point belongs to somebody who is no longer around. So I am sorting this by task, not by vendor. And I deliberately name no version numbers, because those go stale faster than this article.
How we decide whether a tool stays
Before every test, we ask the same question: which task should it take off our hands, and how will I notice that it does?
After that, a four-week rule applies. After four weeks we look at three things:
- Use. Did anybody use it without me reminding them?
- Saving. Has time been freed up somewhere that was previously occupied? A rough estimate is enough.
- Replacement. Could a tool we already have do the same job?
If either of the first two answers is a no, it goes. On the third question it almost always goes, because two tools for the same task is the most expensive state of all. You maintain two, trust neither, and find nothing again.
Writing: the clearest win, with one condition
Text work is the area where AI delivers most reliably for us. Just not in the way it is usually sold.
What works is reworking. Turning a page of bullet points into a product description, a long email into a short one, a German text into an English one, one description into five variants for a test.
What does not work is inventing. A language model asked to write about a product it does not know produces fluent, interchangeable text with invented details. So our rule is: no text without raw material. If you cannot manage five bullet points about the product, you will not get a good description either.
Concretely at nano: product copy for new variants comes out of a table of facts, not out of a wish. The result still goes past a person, because brand voice is not something a model hits by itself. Even so, the time per product has dropped from around 40 minutes to a good 10.
Where we are careful: with text containing numbers. A model writes percentages and deadlines with the same conviction whether they are right or not. Anything containing numbers gets read against the source.
Analysis: good at sorting, bad at maths
This is where the biggest misunderstanding sits. Many people expect AI to be a calculator. It is not one.
What works well is sorting and summarising unstructured material. Grouping two hundred support emails by topic. Pulling the three most common criticisms out of reviews. Putting free-text survey answers into categories. This is work nobody did before, because it took too long.
What works badly is arithmetic over large sets of numbers. A model asked to add up revenue from five hundred rows gets it wrong, and it does so inconspicuously.
Our solution is a division of labour: the database or a Python script does the maths, the AI does the interpretation. At MUSTAX that means the numbers come from a query and the model only writes the commentary around them. Reporting has dropped from 2 days to 2 hours, and the numbers are correct because they never passed through a language model.
If you want to build similar processes, the starting point is in Automating e-commerce processes.
Code: the area with the biggest jump
I have been writing software since 2016. In programming, more has changed in the last two years than in the eight before that.
What actually saves us time:
- First drafts. A script that reads in a CSV file, checks it and reshapes it is there in minutes instead of an hour.
- Somebody else's code. Summarising two hundred pages of API documentation and finding the one call I need.
- Tests. The most boring part, and the one where AI does the least damage.
- Debugging. Getting an error message explained before I spend half an hour searching.
What does not work: architecture. How a system should be structured, which parts depend on each other and what will hurt in three years, gets answered by a model with the average of the internet. The average is rarely the right answer for one specific operation.
And a hard rule: no generated code goes live unread. It is not bad code. But otherwise you run a system nobody in the building understands. You notice that only when it stops at three in the morning.
Research: useful, never as a source
Research is the area where I am most cautious.
AI is useful for getting into a topic. Ten terms explained, a rough map, a list of questions I should be asking. That saves an hour of poking around.
It is useless as a source for facts that have to be correct. Prices, deadlines, legal situations, technical limits of individual services. There you get plausible sentences, a considerable share of which are outdated or invented. A model that names sources is not automatically better, because citations can be invented just like the rest.
Our rule: anything that feeds into a decision gets checked at the original source. Anything that only improves my understanding does not have to be.
Images: good for internal use, delicate for external
We use image generation, just differently from what you might expect.
For internal purposes it is excellent. Drafts, moodboards, placeholders in a layout, a quick sketch for a conversation. There it is about speed, not about the final result.
For product images we do not use it. A product image has to show the product the customer receives. Anything else is a reason for a return and, depending on the depiction, a legal matter. Cutouts, retouching and background swaps we do with AI tools, that is editing. An invented product photo is something else.
Where it has clearly paid off: backgrounds for ad creatives, where the product is really photographed and the surroundings are generated. With that we have considerably increased the number of creatives per campaign at mate, without booking a shoot every time.
What stays a toy
The list that has saved me the most money is the list of things we got rid of again.
| Type of tool | What was promised | Why it went |
|---|---|---|
| AI meeting summariser | never write minutes again | nobody read the summary, decisions were in the task anyway |
| Autonomous social media poster | content runs by itself | the posts sounded like nobody, reach fell |
| AI assistant in the inbox | sorts your mail | did the same as our own pre-sorting, twice over |
| Language model as a database | ask your numbers in a chat | answers were sometimes wrong and always confident |
| AI presentation builder | a deck in two minutes | the rework took longer than building it yourself |
The pattern is always the same. Tools that want to replace an entire profession disappoint. Tools that take over one specific, boring step stay.
The second entry in the table, the inbox assistant, is the most instructive. It was not bad. It was simply the second solution to a problem we had already solved. How we solved it is described in Pre-sorting support emails with AI.
How to get rid of a tool again
Hardly anybody can do this, and it is the more important skill.
For us it runs in four steps:
1. Find the dependencies. Search your automation tool for the name and for the API key. There is almost always more attached than you think.
2. Switch off, do not delete. Deactivate first and wait two weeks. If nobody speaks up, it really was unused.
3. Get the data out. Export while the account still exists. After cancellation the window is often short.
4. Revoke access. Invalidate keys, close the account, cancel the subscription, remove the entry from your register of processors.
Step 4 is the one most often forgotten. A cancelled subscription with a still valid API key pointing at your shop is an open door that nobody is responsible for any more.
We run this pass twice a year, together with a look at the costs. Last time, four subscriptions went. What tools and operations cost in total is worked through in What automation really costs.
The limits
- No tool replaces a clarified process. If three people solve the same case differently, AI will make that inconsistency faster.
- The market moves faster than your learning curve. That is one reason to use few tools deeply instead of many shallowly.
- Every tool is one more recipient of your data. That is part of the decision, not a side issue.
- The most dangerous mistakes are the polite ones. A model rarely says "I do not know". It says something plausible. Where that would be expensive, a check belongs behind it.
- Time savings vanish if you do not collect them. Ten minutes here and there only add up to something when a whole block of work disappears.
Conclusion
Sort by task, not by vendor. For text, AI pays off in reworking, not in inventing. For analysis, in sorting, not in calculating. For code, in first drafts and debugging, not in architecture. For research, at the start, never as a source. For images, internally, and externally with care.
And stop at six tools, not forty. The advantage comes from depth, not from the collection. If you want to know how these tools work together inside a running process instead of separately in a browser tab, the best place to start is your first n8n workflow. And if you are wondering whether your case needs an agent at all, read What is an AI agent first.
Want to know which tools will actually do something for your operation? Write to us at Flowhouse. We will also tell you which ones you can switch off again.