Guide / AI & Automation
Automate the Boring Part, Keep the Judgment
A practical way to choose automation boundaries for catalogue work: stable transformations, inspectable inputs, visible exceptions and deliberate human review.
Renaming a column across a supplier file is repetitive. Deciding whether two similarly named products are the same product is a different kind of work. Both can happen inside the same spreadsheet, which makes it tempting to call the whole activity “data cleanup” and automate it as one operation.
That label hides the important boundary. One task may have an explicit, stable rule. The other may depend on incomplete evidence and commercial context. A script can apply the first rule consistently while making the second decision dangerously invisible.
Catalogue and marketplace work gives me a practical way to think about business automation: automate transformations whose meaning can be stated, preserve the original evidence and make exceptions easier for a person to resolve. The goal is useful throughput with understandable outcomes, not the largest possible unattended workflow.
Choose a task before choosing a tool
Start with an actual recurring operation. Perhaps a supplier exports prices using a decimal comma while the destination expects a decimal point. Perhaps a channel needs a fixed set of column names. Perhaps a repeated import contains unchanged records that can be identified before anyone reviews them.
Each candidate should have a defined input, expected output and rule owner. “Clean our catalogue” is too broad. “Convert the documented supplier price field into the canonical decimal representation, rejecting ambiguous values” is specific enough to inspect.
A small Python program may be sufficient. A workflow tool may be useful when the main work is coordinating existing services. A spreadsheet can remain appropriate for a limited, visible transformation. Tool choice follows the boundary and operating needs; it should not decide them in advance.
Automation is strongest where rules are boring and exceptions are visible.
If the rule cannot yet be explained to another person, implementing it may simply encode a misunderstanding faster.
Evaluate value and risk separately
A useful decision model considers frequency, manual effort, rule stability, error cost and exception rate. These factors interact, but multiplying arbitrary scores would create a precision the evidence does not support.
Frequency and effort suggest the potential benefit. Stable rules suggest that a transformation can be repeated reliably. Error cost and exception rate shape the review and recovery requirements. A task with substantial manual effort may still be a poor candidate for unattended execution if a wrong result is difficult to detect or reverse.
Consider three hypothetical operations:
| Operation | Likely automation boundary |
|---|---|
| Rename documented fields | Apply automatically after schema validation |
| Identify unusually large price changes | Flag for review using an explicit threshold |
| Merge uncertain product identities | Gather evidence and request a decision |
These are design choices for the examples, not universal policies. A mature identity system could support automatic merges under stricter conditions. An undocumented supplier change could make even column renaming unsafe until the contract is clarified.
The distinction between assist and execute is valuable. A workflow can save time by preparing a decision without taking responsibility for the final action.
Preserve the input that explains the output
A transformed file should remain traceable to its source and the rules used to process it. Otherwise, a surprising result becomes a guessing exercise: was the original value wrong, did the parser misunderstand it, or did the mapping change?
For a catalogue batch, useful provenance might include the source filename, a content hash, the mapping version and counts of accepted and rejected records. Those details can be recorded without copying confidential content into every log line.
Keep the raw input separate from the generated output. Editing the only copy of the supplier file destroys the reference needed to explain a later discrepancy. Reproducibility starts with knowing which input was actually processed.
This matters even for a script run manually. A person clicking “Run” does not make the transformation self-explanatory. The workflow should produce a concise report that connects the action to its outcome.
Validate meaning after parsing
Python’s CSV module provides readers, writers and dialect configuration for tabular exchange. It does not know whether a supplier identifier is valid for your catalogue or whether a price is commercially plausible. Those checks belong to the application’s rules.
A file can parse successfully while containing missing identifiers, repeated products or an unexpected currency. Treating successful parsing as successful validation allows those problems to travel farther into the workflow.
Normalization should also be deliberate. Trimming accidental whitespace may be safe for one field and destructive for another. Converting identifiers to numbers can remove leading zeroes. Replacing every comma with a dot can corrupt descriptive text while trying to repair decimal notation.
The CSV boundary article develops this separation in more detail. Here the important point is operational: a transformation should state what it assumes, check those assumptions and stop or quarantine records when they do not hold.
Design the exception report as a product
An exception report is often treated as a leftover file produced when the main process fails. In a useful automation, it is the interface through which a person handles the cases that require judgment.
A report should identify the record, show the relevant original value, explain the failed rule and indicate the available next action. “Invalid row” is too vague. “Missing supplier identifier; no product was updated” connects the problem to its effect.
Grouping exceptions can help without concealing individual records. If a whole column disappeared, asking someone to resolve hundreds of row-level errors is the wrong interaction. The batch should explain that its schema no longer matches the expected contract.
An exception that nobody can interpret is unfinished automation.
The human step should become easier as the routine work disappears. If automation leaves only an inscrutable pile of errors, it has moved effort rather than reduced it.
The report also needs an owner and a review rhythm. A queue that grows silently is an accumulating operational obligation, even when the scheduled job keeps reporting success.
Make a second run safe
Repeated imports are normal. A scheduled task may be retried after a connection failure; a person may rerun a batch because they are unsure whether the first attempt finished. The system should distinguish an unchanged record from a new operation.
For a file transformation, that may mean producing the same canonical output from the same input and rule version. For an external update, it may require recording the operation and reconciling the destination before repeating a consequential action.
A dry run can show proposed changes without applying them. Review should focus on meaningful differences: additions, removals, price changes and rejected records. A large output file alone makes those differences difficult to assess.
Keep a recovery path proportional to the task. If the automation overwrites data, know which prior state is needed to reverse it. If an external action cannot be undone cleanly, use a stronger approval boundary before that action occurs.
Expand only after the rule becomes clearer
A useful first automation can be narrow. It might normalize one supplier format, prepare a reviewable export and leave publication manual. That already removes repetitive work while exposing the cases that need better understanding.
Observe what remains. Repeated exceptions may reveal a missing rule, a poor source contract or a category of work that should stay human. Do not automatically convert every frequent exception into an unconditional branch. Frequency alone does not establish that the decision is safe.
The same principle applies to scraping and scheduled data collection. Use permitted access methods, respect the source’s terms and operating limits, and avoid building a workflow around information you are not entitled to collect. A documented export or API often provides a clearer contract when available.
Keep judgment where the evidence is ambiguous and the consequence matters.
That boundary can move as the system gains better data and clearer rules. The durable value of automation is that routine transformations become dependable, leaving people with decisions they can actually understand and own.