A D2C brand we work with sells across more than 15 marketplaces: Amazon, Flipkart, Myntra, Blinkit, Zepto, Instamart, Nykaa, BigBasket, FirstCry, Tira, Clinikally, Smytten, Kindlife, Momstore, JioMart, and a few more.
Every month, someone on their team logged into each of those platforms, exported the data, and consolidated it by hand into an 18-tab Google Sheet. That workbook is what leadership actually looks at to understand how the business is doing. Filling it took two full working days a month, not something squeezed in around everything else, the whole job for those two days.
Smacient built a pipeline to automate the entire thing. This is what that actually involved, and why it is a useful case study for anyone weighing whether a workflow of theirs is a candidate for the same treatment.
Table of Contents
Why This Looked Simple and Wasn’t
Described in one sentence, “pull data from a bunch of platforms into a spreadsheet” sounds like a weekend job. Enough of these projects go sideways to know that sentence is doing a lot of hiding.
No two platforms export data the same way. Different columns, different file formats, different definitions of something as basic as “revenue.” There is no shared schema to code against. The choice is between building something that understands each platform’s specific shape of data, or building something fragile.
Filenames drift, and nothing tells you when. One platform’s monthly export went from “orders report.csv” one month to “July_Order report.csv” the next, same data, different name. A pipeline that matches files by name will run cleanly for a few months and then silently break, or worse, silently process the wrong file. Smacient solved this by matching incoming files on their column signature (the actual shape of the data inside the file) instead of the filename, with a layered fallback and one hard rule underneath it: if the system cannot confidently identify what a file is, it stops and flags it for a human. It does not guess.
One platform does not send a usable export at all. Amazon’s data had to be rebuilt in memory from raw shipment and order reports on every single run, because no single file exists that contains what the report needs.
Some months, a platform sends a screenshot instead of a file, a dashboard image, not an export. That needs a manual, transcribed fallback path, since a JPEG can’t be parsed the way a CSV can.
The pipeline writes into a live, historical sheet, not a fresh blank report. This is the part most people underestimate: it is not generating a new document every month, it is writing into the client’s existing Google Sheet, on top of months of real historical data. That changes the entire risk profile. A missing or broken source file cannot be allowed to overwrite a real number with a zero, ever. So every write runs as a dry run first, validated against what is already on the sheet, and if a source is missing, the pipeline leaves those specific cells untouched rather than guessing at what should go there.
None of these problems is exotic on its own. Put them together, and the result is exactly the kind of workflow that looks automatable in a scoping call and then quietly breaks a simple script by month two, usually right after it has already fed a wrong number into a decision.
What Smacient Actually Built
The architecture is straightforward to describe, even though getting each piece right was not: raw marketplace exports land in Google Drive, a Python pipeline running on Google Cloud Run reads and reconciles them, and the output writes directly into the client’s existing 18-tab Google Sheet. The client’s own team triggers a run with a button, a menu item in Google Apps Script, so nobody on their side needs to touch code or infrastructure.
Every part of this also runs inside the client’s own Google Cloud Platform project. No data ever leaves their infrastructure. For a brand handling sensitive sales and platform data, that is often the difference between a tool a team is allowed to adopt and one that never clears procurement.
Proving It Before Trusting It
Building the pipeline was the first half of the work. Trusting it was the second, and arguably the part that matters more.
The automated pipeline ran in parallel with the team’s existing manual process for two months before it touched anything live. The same source files, from the same months, were fed through both processes independently, then compared cell by cell.
The automated version came out clean every time.
The manual version, the same process this team had been running for years, had 6 confirmed errors across that comparison period: revenue read off the wrong column on one platform, cancellations counted as returns on another, a summary formula that silently excluded a row of data from its total, and pricing data that was out of date by the time it fed into a calculation.
Nobody had caught any of it, and that has nothing to do with how careful the team was. A spreadsheet does not tell you when it is wrong, it just sits there, confidently displaying whatever number ended up in the cell. Software that validates its own inputs against known-good sources surfaces that kind of error automatically. A human doing the same task by hand, twelve times a year, for years, has no equivalent check.
The Real Return, and Why Hours Saved Wasn’t the Headline
Two days a month recovered is a real but modest number, and Smacient was upfront with the client about that from the start: if a project like this is evaluated purely on hours saved, the business case is thin.
The actual value sits elsewhere.
First, trustworthy numbers: six confirmed errors, each one a specific instance of the business making a decision off a number that was wrong, for months, with nobody the wiser.
Second, a process that is no longer held in one person’s head. Before this, the entire monthly reconciliation lived as tribal knowledge: which platform’s export needs which adjustment, which column actually means revenue, which quirks to watch for. Now it is documented and codified in a system that runs the same way every time, whether or not the one person who used to do it by hand is available that month.
Third, a foundation to build on. A one-off dashboard is a dead end. A validated, structured pipeline that already reconciles fifteen-plus data sources is the starting point for things like SKU-level profitability views, a straightforward addition once the underlying data is already clean and trustworthy, and a genuine project on its own if starting from scratch every time.
Most Automation Breaks Here. This One Didn’t
A lot of what gets called “marketing automation” today is a Zapier connection and an auto-posted report. That’s fine for what it is. It also falls apart the moment it touches a decision that matters, because it was built like a script and not like software: no validation, no guardrails, no way to know whether the input data was even trustworthy in the first place.
The brands getting real value out of AI and automation right now are the ones willing to engineer the hard 20 per cent, not the ones automating the easy 80: the schema drift, the edge cases, the “what happens when this breaks” question that never comes up until the month it does. That is the part that actually determines whether the number on the dashboard can be trusted.
Understanding how marketing operations actually break is one skill. Building something with the engineering discipline not to quietly lie about it is another. This project needed both, and that combination is what Smacient brings to work like this.
If You’re Carrying a Workflow Like This
Anyone who recognised any part of this- a monthly process that eats two days of someone’s time, a report that everyone trusts more than they should, a workflow that is “automatable” in theory but keeps getting deprioritised because doing it properly feels like a bigger job than it looks- that is exactly the kind of project Smacient takes on.
Talk to Smacient. The team will give an honest read on whether it’s worth automating, what it would actually take, and what the real return looks like once the hype is stripped out.
FAQs
Because every platform exports data differently, in different formats, with different column structures, and different definitions of basic terms like revenue. There’s no shared schema, so a pipeline either learns each platform’s specific data shape or breaks the moment something changes.
By running every write as a dry run first, validated against what’s already on the sheet, and by leaving cells untouched rather than guessing when a source file is missing, instead of ever overwriting a real number with a zero.
By running the automated pipeline in parallel with the existing manual process for a period of time, feeding both the same source files independently, and comparing results cell by cell before the automated version touches anything live.
Not usually the biggest part. Time saved is real but often modest. The larger value tends to be catching errors a manual process was making undetected, and turning tribal knowledge held by one person into a documented, repeatable system.
Not necessarily. It’s possible to run the entire pipeline inside a client’s own cloud infrastructure (their own Google Cloud Platform project, for example), so no data leaves their environment.
Look for the edge cases: inconsistent filenames, platforms with no clean export, occasional manual fallbacks like screenshots, and whether the automation would write into a live historical report rather than generate a fresh one each time. Those details determine whether it’s a weekend script or a real engineering project.
Related Blogs
- How to Build a Competitor Price Monitoring System Using Proxies and AI
- How to Use Claude for Automated Weekly Marketing Reports
- AI Marketing ROI: The Framework CMOs Are Using to Prove Value
- Build Your Daily SEO Dashboard in Claude Cowork
- 10 Claude Cowork Use Cases Every Marketer Should Try
- AI-Native Marketing Teams: How to Restructure
- First-Party Data Strategy: Why It Matters More Than Ever
- Top Claude Connectors to Automate Workflows and AI Tasks for Marketers
