Skip to content

Case study · Sep 21, 2026

Teams compare performance without rebuilding reports by hand

A multi-brand retail group's marketing, sales, customer and operational data sat in disconnected systems, so teams depended on manual exports and fragmented reports. Kastling designed and built a decision-intelligence platform that brought those sources into one access-controlled data foundation, automated the refreshes and gave each team a practical way to analyze and act on the information.

ClientA multi-brand retail group
IndustryRetail
ServicesAI Integration & Automation, AI & Cloud Infrastructure, Custom Solutions
PlatformsAzure, Google Cloud, PostgreSQL (Supabase), Next.js, Google Ads, Meta Ads, Snapchat Ads, Google Sheets, Power BI
records consolidated in one shared data warehouse100K+

The challenge

For the group's marketing and performance-marketing teams, answering a business question usually started with assembling the data. Advertising results, customer activity, sales figures, brand reports and internal operational inputs lived in different systems. Moving information between teams meant exporting spreadsheets, sharing files and sometimes re-entering the same figures by hand.

The teams reported a daily manual refresh that took 2 to 8 hours. Reporting waited on people to collect and prepare the latest inputs before another team could use them. Each new source or reporting requirement added another recurring chore.

Power BI dashboards gave the teams visualizations, but not enough context to act. Stakeholders wanted to compare current and previous periods, understand customer behavior, see the differences between brands and channels, and connect spend to results. Separate reports made those questions hard to answer consistently.

Connecting the systems was only part of the problem. Sources used different formats, definitions and refresh schedules. Teams needed different views of the same information, restricted by responsibility and division. Adding a source could change calculations, historical comparisons, permissions and the reports people already relied on.

No automation layer governed that movement of data. Better visualizations alone would have left the manual transfers, inconsistent inputs and coordination burden in place. The business needed a dependable foundation for collecting, checking, securing and serving information, and an application that made it useful in daily work.

What we built

Kastling owned discovery, architecture, hands-on implementation, deployment and technical direction, with two engineers supporting delivery. The team worked directly with the marketing and performance-marketing stakeholders and coordinated with the internal teams responsible for each source system.

Discovery showed that collecting the data was only part of the job. Reports that looked identical could calculate the same measure differently. Comparing the platform's figures with the existing Power BI reports exposed differences in aggregation logic, so the work included reconciling metric definitions and checking that every transformation preserved the underlying numbers.

The platform connected the Google, Meta and Snapchat advertising feeds, customer and sales sources, internal inputs, Google Sheets and services across Azure and Google Cloud. Automated pipelines collected and prepared the information in PostgreSQL, which served as both the storage layer and the shared data warehouse (one database that every authorized application reads from). Refresh behavior matched each source: near real-time feeds, scheduled jobs and controlled human input each had a place.

Behind the interface, the platform kept the original source records, standardized incoming data and prepared consistent datasets for analysis. Row and column fingerprints (short signatures that change when the underlying data changes) detected what had moved, so incremental refreshes updated only the changed records and preserved the rest. Large workloads ran as smaller recoverable jobs: a failed unit was reported and retried while completed work stayed intact. Validation, duplicate checks and monitoring made exceptions visible.

Users could compare periods, filter by the business dimensions that mattered to them, examine budgets and spend, enter operational data through validated forms and export focused views. Heavy filtering and pagination ran on the server, the interface handled the lighter interactions, and caching kept frequently requested views responsive.

People kept control of operational inputs and business decisions. Authorized staff entered data through constrained forms, administrators managed access, and managers interpreted the results and decided what action to take. Role and division restrictions determined what each user could see. This was an analytical and operational platform, not an autonomous spending or approval system.

The architecture left room for more sources and business domains. Forecasting, fraud detection and further AI capabilities sat on the roadmap, with the trusted data foundation built first. Individual reporting automations reached different stages of completion, and none is presented here as a universally deployed feature.

The results

The platform changed how the participating teams worked with data. They used shared analytical views, compared current and previous results, filtered the information for a specific question and entered new operational data through consistent forms. Automated collection and refresh reduced the dependence on assembling source files before reporting could begin.

One documented implementation consolidated 100K+ records in the shared data warehouse. That figure describes a retained implementation within the broader platform, not its total lifetime volume or the full extent of the group's data estate.

Data access was responsive. Several warm, cached endpoints measured below 17 milliseconds at the 95th percentile in local tests, meaning 95 percent of the measured requests completed within that time. This is a scoped backend benchmark, not a complete dashboard load time or a production figure for every user.

Reliability improved through independently recoverable jobs, duplicate prevention and unchanged-input skipping. When one processing unit failed, the completed work was preserved, reducing the need to repeat an entire refresh.

The work ran from January to April 2026. The available record establishes the earlier 2 to 8 hour manual refresh, but not a comparable post-launch timing study or the date of the first usable release, so no percentage reduction or staff-hours saving is claimed.

The foundation supported continued expansion across sources, teams and analytical needs. Further automation and AI capabilities could build on the same access controls, consistent definitions and recovery mechanisms.

PerformanceThis period beside last
Store budget entered through the formValidatedExport this view

Article · 7 min read

AI workflow automation: what it costs to run and what it savesThe cost of AI workflow automation splits into five areas: discovery or a paid audit, implementation, infrastructure and model usage, integration licenses, and support and change. Model usage is usually the smallest recurring line and scales with volume and document length, while support, exception handling and adoption are the lines buyers underestimate. Savings come from hours returned at loaded cost, fewer errors and faster cycle times, but only count as cash when they change hiring, overtime or outside spend.Read

Article · 9 min read

How to calculate the ROI of AI automationCalculate the ROI of AI automation by measuring the current process first, then valuing hours saved at loaded cost, errors avoided and faster cycle times, and setting that against the full cost to build, run and support the system. Express the result as a payback period under conservative assumptions, and count saved hours as money only when they change hiring, overtime or contractor spend.Read

Article · 8 min read

Data security and governance for AI in the enterpriseAI data security and governance means knowing which data each AI workflow touches, approving the sources it may use, checking what your AI provider does with prompts and outputs, and making the AI respect the same permissions as the person using it. It also covers defenses against prompt injection, logging with sensible retention, human approval for consequential actions and a clear usage policy for staff. Frameworks such as the NIST AI RMF and ISO/IEC 42001 give that work a structure.Read

Have a similar problem?

Tell us where the work slows down. We will help you see where to start.

Request a discovery call