Datacor's Rental Analytics Build Shows the Unglamorous Work Behind Generative BI

Datacor has embedded Amazon Quick Sight dashboards and a natural language search bar directly into TrackAbout, its asset-tracking product for industrial gas and welding distributors, according to a post published on the AWS Machine Learning blog with contributions from Datacor's TrackAbout engineering and product teams. The stated goal was to let distributors analyze rental billing data themselves instead of filing tickets for custom SQL Server Reporting Services reports that took days or weeks to arrive. The more instructive part of the write-up is not the generative BI layer but the cross-cloud ingestion, row-count validation and tenant-isolation plumbing that had to exist first.

The problem was access, not modeling

AWS and Datacor frame the business case in concrete operational terms. TrackAbout customers collectively manage 27.5 million assets and more than 725,000 bills per month, the post says, and rental billing on cylinders and bulk tanks represents a significant share of revenue for gas and welding distributors. But the data lived in TrackAbout's operational systems, and getting anything out of it meant going through Datacor's support team for a custom report or a raw export.

The cost, as described, was not just latency. Static reports answered one question and forced a new request for any follow-up. A distributor could not ask what happens if acetylene rates rise five percent and get an answer inside the same meeting, so rate decisions that govern revenue recovery were made on partial information. Pre-built standard reports were not a fix either, because fleet size, product mix, geography and billing structure vary widely across distributors.

This is a familiar pattern in vertical SaaS: the vendor accumulates operationally rich data on behalf of hundreds of tenants, then becomes a bottleneck on every analytical question those tenants want to ask. The generative BI pitch is that natural language collapses the reporting queue. Whether it does depends almost entirely on what sits underneath.

The architecture: Azure in, Iceberg on S3, SPICE out

Datacor's operational data resides in Azure SQL databases, so the pipeline is genuinely cross-cloud. According to the post, an Azure Data Factory pipeline extracts source tables as Apache Parquet files and lands them in Amazon S3, supporting both full and incremental loads with change tracking so only modified rows move on incremental runs.

Arrival of new data in S3 triggers an orchestration layer built on AWS Lambda, AWS Glue and Amazon DynamoDB, which dispatches per-table jobs and enforces ordered, single-threaded execution. Glue jobs merge incremental updates into Apache Iceberg tables on S3, and an AWS Step Functions workflow validates row counts before building the BI-ready tables. Only after a successful run does Datacor refresh the Quick Sight SPICE datasets that back the dashboards.

That validation step gets called out in the lessons-learned section as essential to user trust: dashboard numbers have to match what users already see in their operational system. It is a mundane point that teams shipping AI-fronted analytics routinely underweight. A natural language interface amplifies the consequences of a bad join or a silently dropped partition, because it removes the analyst who would have noticed.

Sundar Kuppuswamy, Datacor's Chief AI Officer, is quoted saying the interesting part was not the AI but the ingestion, validation and auditable tenant-isolation work underneath it, and that the company is deliberately conservative about where it applies the technology because a confident wrong answer about revenue data is worse than no answer.

Multi-tenancy handled through row-level security

Because TrackAbout is multi-tenant SaaS, every dashboard and every natural language query is scoped using Quick Sight row-level security. Each SPICE dataset has an associated RLS dataset mapping user identities to tenant identifiers, applied at query time. The post says this avoids duplicating datasets or dashboards per tenant, requires no dashboard changes when new customers are onboarded, and applies to natural language queries as well as embedded visuals.

Datacor aligned the RLS model to an existing tenant identifier already present in the pipeline, the client database name, and documented it as a formal data access policy to make the system auditable. Dashboards are rendered inside the TrackAbout web UI using the Quick Sight Embedding SDK, with the application server calling the Quick Sight API to generate a short-lived signed embedding URL scoped to the requesting user.

Onboarding is automated: on first access, TrackAbout creates the Quick Sight identity from the user's existing role, adds the tenant identifier to the RLS configuration and assigns the dashboard set for that subscription tier. Datacor estimates manual provisioning would have taken 15 to 30 minutes per customer.

Making the assistant speak the industry's language

The natural language layer is Amazon Q in Quick Sight, configured through generative BI topics that map business terminology to dataset fields. Datacor's product team worked with TrackAbout subject matter experts to confirm the assistant understood vocabulary such as turnaround time, lost cylinders, demurrage and fill cycle, defined friendly field names and synonyms for dataset columns, set up calculated measures like average rental duration and revenue recovery rate, and tested topic coverage against a library of real customer questions.

One stated lesson is worth flagging: designing topic coverage around the questions users actually ask produced higher answer accuracy than mapping the full schema. That runs against the instinct to expose everything and let the model figure it out, and it implies meaningful ongoing curation cost as new questions emerge.

No accuracy figures are given. The post does not disclose how often the assistant returns a wrong or unanswerable result, what guardrails catch bad answers, or how disagreements between dashboard totals and operational systems are surfaced to users. For a feature pointed at revenue data, those are the numbers a buyer would want.

Rollout and results, with caveats

Datacor phased the work. The first phase began in July 2025 on the pipeline itself, running in parallel with the existing SSRS environment so outputs could be validated before legacy reports were retired. A pilot with six or seven customers followed in September 2025, and general release to TrackAbout customers using rental functionality came in November 2025.

Since release, the feature has been enabled for more than 50 customer organizations with more than 60 business users actively using the dashboards, according to the post. Those are small absolute numbers against a base of tens of millions of tracked assets, and roughly one active user per organization suggests adoption is still early. Datacor notes the rental module is used by only a subset of customers.

The claimed outcomes are qualitative rather than quantified: answers in minutes instead of days, asset-aging views that expose containers generating no rental revenue, billing discrepancies surfaced outside of annual audits, and IT freed from building one-off reports. The post attributes these to early adopter feedback. No dollar figures for recovered revenue, no before-and-after ticket counts, and no cost of the AWS footprint are provided.

Datacor has since reused the architecture for three additional dashboard suites covering Customer Overview, Inventory Insights and Process Inconsistencies, piloted in May 2026 with general availability planned for September 2026. The company says this required no new infrastructure, which is the strongest available evidence that the foundation was built correctly. Future plans listed include predictive fleet planning from historical barcode and RFID scan data, coverage of bulk tanks and specialized equipment, financial analytics topics such as margin analysis, and ERP integration.

As with any vendor-authored case study, this is a success narrative published on the cloud provider's own blog. It is still a reasonably detailed reference architecture, and the honest emphasis on validation and access control over model capability is the part most teams should copy.

What to watch

• Whether active usage grows past roughly one business user per customer organization, which would indicate the natural language interface is reaching beyond a single power user per account.
• Any published accuracy or error-handling data for the generative BI assistant, particularly how wrong answers about revenue figures are detected and corrected.
• How much ongoing effort topic curation requires as Datacor extends natural language coverage into margin analysis and contract performance, where definitions are more contested than asset counts.
• Whether the September 2026 general availability date for the three new dashboard suites holds, and whether the same pipeline handles the broader customer base without re-engineering.
• Whether the predictive fleet planning work ships as a forecasting feature with stated error bounds, or remains a roadmap item.