Roughly 1,900 travel products that had been managed in spreadsheets moved onto a system. While automating product information collection, change updates, and search advertising integration, we verified data consistency and the collector's processing limit before looking at screens.
Registering a product for the first time is easier than keeping a registered product correct. When the sales conditions change, the information under management has to change too, and what reaches the sales pages and the ads has to be refreshed along with it.
At company M, a travel product management business, roughly 1,900 products were being managed by people in spreadsheets. Reflecting product changes and connecting them to advertising remained two separate tasks.
With the number of products growing, what was needed was not just one new input screen. It was a system that manages the flow of data from the moment information arrives from outside until it is stored and reflected in sales and advertising.
Turning a file into a web screen is not the same as automating the work
Moving an existing table onto a web screen as it is can make it easier to access. But if someone still has to check and enter the data every time a product changes, the core work remains where it was.
In the company M project, product change management and search advertising integration were set as the targets for automation, and the system was built around them. The function that collects external product information sat at the center.
To understand the scope of automation, you have to look at where change begins rather than at the screen. Where product information changes, and by what path that change reaches the end user.
Seen this way, the collection function is not a minor add-on. It is the starting point that supplies the information used by storage, display, and ad integration downstream.
We checked the stored values, not the message that collection had succeeded
Even when a data fetch has finished, whether that value was stored as the information of the intended product has to be confirmed separately. A good-looking admin screen cannot make wrong data look right.
In QA we compared the collection results against the database values product by product. Alongside whether the function ran, we checked whether the collected information matched at the storage stage.
The questions in data consistency verification are concrete. Do the incoming value and the stored value describe the same object, and was it stored in a state the downstream functions can use.
This is also why screen checks and data verification were kept separate in this project. When the information is used for sales, you have to understand which data is actually being passed on, not only whether something displays incorrectly.
The more you process automatically, the more it matters to know the limit
Automating work that people used to do lets repetitive tasks run faster. But faster processing alone does not define the operating range.
At company M we put load on the collector to confirm its processing limit. On top of comparing collection results with stored data, we looked at what reaches its limit first as the workload grows.
Consistency verification and load testing ask different questions. The former asks whether the result is correct; the latter asks up to what conditions the work can be handled. Neither result substitutes for the other.
The operating standard for an automated system needs the answers to both. Knowing the range that can be processed accurately and the constraints that appear when throughput grows is what makes the next change possible to judge.
We made sales and advertising follow the same product change
The system that was built provides the flow that receives product changes and reflects them on the sales pages and in search advertising. It connects work that people used to do separately for each channel.
This is distinct from writing ad copy or improving ad performance. The center of this case is the integration that carries product information changes to the channels.
Having an integration does not mean every external channel is always updated instantly. What matters, then, is understanding the path that carries the change and the basis of the information being used. You have to be able to explain which data is handed on to the next system.
The value of product management automation does not show up in the number of entries alone. It also lies in keeping the several places that describe the same product from being left in different states.
We carried the same scope on into operations after the build
The environment was migrated to the cloud, and after the transition conditions were settled we took over operations. The collector's processing limit and the data consistency criteria remained as results that later operations can refer to.
The change that took place in this project does not end with the single sentence that spreadsheets are no longer used. What matters is the move from a structure where people follow product changes to one where the system collects and reflects them.
Verification sat on top of that. So that automation would not simply deliver wrong information faster, we compared results between collection and storage and confirmed the processing range.
Work automation is not only about executing the actions people used to perform. It is about building, together with the system, the criteria for confirming that the work was processed correctly.