A supplier sent a new price list. The column names are different, some products changed their SKUs, and the price went up on some items. At the same time several identical questions about delivery times are waiting in the messenger, and products that arrived last week are still waiting for descriptions in the catalog. There is nothing complicated in this work. The difficulty is that it repeats every day and eats the time you would rather spend on purchasing, advertising or at least on lunch.
Neural networks really do help with this routine. But if you hand them the whole store, sooner or later the catalog will contain something you never had in stock. That is why I take automation apart by process: what exactly can be given to AI, where a person has to check, and where it is sensible to start.
Which store processes repeat every day
If you lay out the work of a small store as operations, most of it turns out to be work with data. A product arrives from the supplier as a row in a table. It has to be brought to the catalog format, characteristics filled in, a description written, a section chosen. Then prices and stock change, and all of that has to be updated. In parallel, customers ask questions and leave requests that have to be sorted and passed on.
Each such operation on its own takes little time. Together they add up to a working day. This is where neural networks are strong: they quickly process the same kind of text and tables. The weak side is clear too: the model does not know what you have in the warehouse, and it will confidently fill a gap with a plausible guess.
From this comes a simple rule that the whole article rests on. AI prepares, a person confirms, publishing is a separate step. The more expensive a mistake is for the customer, the closer the check should stand to it.
The flow of data in a store usually looks like this:
- The supplier's table, or your own table in Google Sheets.
- Processing: the neural network brings the data to one form, writes the texts and sorts the products into sections.
- A check: a person looks through the changes, compares them with the source and marks what is disputed.
- The catalog: confirmed data is loaded into the store.
- The customer sees the product card, the price and the stock.
Below I go through each link.
Product data: from the supplier's table to the catalog
The most common source of chaos is different formats. One supplier writes the color in its own column, another hides it in the name, a third merges the characteristics into one line with commas. Matching this by hand is dull and slow, and the mistakes later show up in the catalog filters.
A neural network is good at moving data from one format to another. You can give it the supplier's table and a description of the structure you need, and it will spread the values across columns, bring the units of measure to one form and mark the rows where data is missing. The main condition: the task must explicitly forbid filling empty fields with guesses. Better that it leave the cell empty and put a note than write “100% cotton” for a product whose composition you do not know.
It is convenient to make the result of this processing a table for import. Tilda, for example, describes import and export of products in CSV and YML in its help: before upload, the file's columns can be matched to the catalog fields, and columns that Tilda does not use will be ignored. In CSV files a semicolon is used as the separator, and the maximum file size for import is 50 MB.
If you are building a store from scratch, the order is this: first agree the data structure, then connect neural networks. When I develop an online store, I start from which fields the card will have and which of them are needed for filters. The processing is then set up to that scheme.
Product descriptions and characteristics
Descriptions are what people most often give to neural networks first, and that is reasonable. The model quickly writes connected text from the characteristics, can keep one tone and does not get tired on the hundredth card.
The risks are predictable too. If there are few characteristics, the neural network starts inventing: properties appear that the product does not have, and promises you are not ready to keep. If the task template is too rigid, the descriptions come out identical, and in the catalog that is visible at first glance.
So the neural network should receive a table of facts about the product, and return a text that contains nothing beyond those facts. Checking should be selective but regular, and especially careful for everything that concerns composition, sizes, compatibility and conditions of use.
Catalog updates: prices, stock, new items
Updating prices and stock looks like the simplest task for automation. Formally it is: take the new values and put them into the right rows. In practice this is exactly where a mistake costs the most, because the customer sees it at once.
Here a neural network is useful as a checker. It can compare the new price list with the current catalog and collect a list of changes: which products changed price, which disappeared from the price list, which appeared for the first time. Such a list is convenient to look through before upload. If a product's price suddenly grew several times over, a column has probably shifted, and it is better to notice that in the table than in a customer's complaint.
The upload of updates itself can go through import. Tilda's help describes updating catalog data through CSV: export the current file, make the changes, for example in Google Sheets, and import it back with a mark that products should only be updated, without creating new ones.
There is a more direct path too. Tilda has an MCP server through which an AI agent can work with the project: according to the help, add products to the Catalog, create posts in Feeds and pages. Connection is available on the Personal and Business plans, and each agent gets its own key with full or limited access. This is convenient, but the responsibility is higher: the agent changes data in the store itself, without an intermediate table. I wrote in detail about how to limit that access in the article on Tilda MCP, so I do not repeat it here.
If the store runs on Tilda, such scenarios are set up as part of an online store on Tilda: from the catalog structure to who confirms mass changes and how.
Replies to customers and handling requests
Repeating customer questions are another clear zone for AI. Delivery times, payment methods, whether a size is in stock, return conditions: the answers are already in your rules, and a neural network can quickly pick the right one.
What matters here is where the model takes the answer from. If it has a knowledge base — delivery, payment and return rules, current stock data — the answers will rest on facts. If there is no base, the model will answer “the way it usually is”, and for you it may be not usual at all. Everything that looks like a promise needs special care: a deadline, a discount, a guarantee.
With requests the scheme is similar. A neural network can read the request text, decide which product it is about and spread the data across fields before sending it to a CRM or a Google Sheets table. You also have to decide what to do when the model is not sure: a request with an unclear product should go to a person, and it is better not to send it to a random category.
What should not be handed to AI without a check
So I do not have to keep this in my head, I put the processes into one table. It is a guide: in your store the boundaries may run differently.
| Process | What AI does | What a person checks | Risk of a mistake |
|---|---|---|---|
| Moving data from the supplier's table | Spreads values across columns, brings them to one form | Selectively compares with the source, looks at empty fields | Invented characteristics |
| Product descriptions | Writes text from the characteristics | Composition, sizes, compatibility, promises | Properties the product does not have |
| Sorting into sections | Suggests a section from the name and characteristics | Disputed and new products | A product in the wrong section and filter |
| Price updates | Collects a list of changes | Sharp jumps and missing items | A wrong price on the storefront |
| Stock updates | Compares stock with the catalog | Products that went to zero | An order for something that is not there |
| Replies to customers | Picks an answer from the knowledge base | Answers about deadlines, discounts, guarantees | A promise the store will not keep |
| Sorting requests | Spreads data across CRM fields | Requests with low confidence | A lost or wrongly parsed request |
| Publishing changes | Prepares the changes | Confirms publication | The mistake is immediately visible to customers |
The last row is the most important. I would leave publishing with a person almost always, even if everything else is automated. The MCP specification, the protocol through which AI agents connect to external services, says this plainly: for safety, the chain should always keep a person who can reject a tool call. Applications are advised to ask for confirmation before operations and to keep a log of calls.
A change log is useful even without any protocol. When you can see what changed, when and on whose command, a mistake can be found and rolled back quickly. Without a log you are left guessing why the old prices suddenly disappeared from half the catalog.
Where to start automation: the order of steps
Starting with neural networks is usually too early. First the data needs to be in order, otherwise AI will simply multiply the existing mess faster.
The order I consider reasonable:
- Collect the product data in one place — in one table or in the catalog.Three files and a messenger thread do not count as that place.
- Agree the structure: which fields are required, what the sections are called, in which units sizes and weight are written.
- Choose one process where a mistake costs the least, for example draft descriptions for new products.
- Write the task for the neural network and test it on a small sample.
- Appoint who confirms the result and the publication.
- Only after that move to the processes where a mistake is more visible: prices, stock, replies to customers.
A separate question is what this costs. On the services page, process automation, including connecting AI tools, is listed as a separate cost factor. That is an honest part of the estimate: scripts, setting up scenarios and check steps take work. If a scenario goes beyond a standard import, it is reasonable to treat it as a custom task and estimate it separately.
A checklist of whether the store is ready for automation
Before you connect neural networks, go through the list:
- Product data sits in one place, and it is clear which version is current.
- Catalog section names are clear and do not overlap in meaning.
- Products have the characteristics needed for filters and descriptions.
- The table structure is fixed: required fields, units of measure, SKU format.
- There are delivery, payment and return rules that replies to customers can rest on.
- It is defined what to do with data the neural network is not sure about.
- A person is appointed who confirms publication of changes.
- Changes can be looked at before publication and rolled back after.
If most of the points are already done, automation will go calmly. If not, start with them: this is useful for the store even without any neural networks.
If you want to understand which processes in your store are worth automating first, take the quiz on the site. I will look at the task and suggest an order of work.