Technology, IT & Software

A software company sits on a lot of data: usage events from the product, contracts and invoices from billing, opportunities in the CRM, tickets in support. Each system answers its own question. As soon as someone wants to know which features lead to renewals, the data has to come together.

We build a shared data foundation and consistent metrics for that. If you offer AI features in your own product, we also help with evaluation, operations and the EU AI Act classification.

Three systems, three IDs for the same customer

The hardest part is usually not the technology but the matching. An account in the product, a customer record in the CRM and a contracting party in billing often carry different identifiers, and somebody has to link them before a question like “do our biggest customers use the new feature?” can be answered. Support tickets come on top, and with usage-based pricing the metered usage per customer account. If you want margin per customer, you also need cloud costs and operating data.

Product analytics tools answer usage questions quickly, but they see neither invoices nor tickets. So we load the sources into a data warehouse and join them there. That has a second effect: analytics stop running on the production database, which relieves the product and makes reports faster. The setup is described under Data Warehouse and Data Modeling.

A word on events. Too many events, or badly named ones, make every analysis painful. A tracking plan with naming rules, written before the events go into the product, saves a lot of work later.

Why MRR looks different in every department

SaaS metrics look simple and are not. For MRR and ARR, most of the work is in the rules: how do annual contracts, discounts, trials and usage-based components count, and when does a contract’s revenue start and end? For net revenue retention and churn, revenue churn and logo churn are different things, and downgrades and expansion shift the picture unless you report them separately.

Typically finance, sales and product each calculate from their own tables and arrive at different numbers. So we put the definitions into one central metric model that everyone reads from.

The same applies to the softer measures. Which event shows that a new account has reached its first value, and how quickly does that happen? Which features do accounts that renew use, and which do the ones that cancel use? A lot of tickets can signal risk or engaged usage. Which of the two it is only shows when you compare with usage and contract data.

Dashboards for customers inside your product

When customers see dashboards in your product, the numbers should match the internal ones, which means they should come from the same metric model. That takes performance that holds up for large tenants and a permission model that grows with the product. Tenant isolation matters most: a permissions bug that shows one customer another customer’s data is especially costly in the customer relationship.

AI features: from prototype to production

Assistants, semantic search, summaries or agents are quickly built as a prototype. Without test cases and monitoring, nobody knows how often the feature answers wrongly. We work in this order: collect real requests with expected answers, re-run the tests on every change to model, prompt or data source, and monitor quality, cost and response time in production. That is the job of MLOps. Provider model changes should be testable before they go live.

An AI inside the product may only see data that the requesting person may see, especially with multiple tenants. If an agent performs actions on behalf of users, you need approvals and logs.

What providers of software and AI need to watch legally

Anyone who develops an AI system and offers it under their own name is generally a provider under the EU AI Act, even with a bought-in model. Under the AI Omnibus (Regulation (EU) 2026/1744, in force since July 27, 2026), high-risk obligations under Annex III apply from December 2, 2027 and for Annex I from August 2, 2028. The transparency duties under Article 50, for example for chatbots, have applied since August 2026. On AI literacy, Article 4 has applied since February 2, 2025, a specific level is no longer prescribed, and supervision by the authorities begins on August 2, 2026.

For providers of cloud and SaaS services, the EU Data Act adds to this. It has applied since September 12, 2025 and requires, among other things, that customers can switch providers. Switching charges are abolished from January 12, 2027. The Cyber Resilience Act provides reporting duties for manufacturers of products with digital elements, which have applied since September 11, 2026. Whether and how pure online services are affected depends on the case.

Product usage data is often personal data, whether it comes from tracking inside the product or from passing content to AI providers. How this applies to your product is a question for data protection and legal counsel.