Open Salesforce without extensive customization and you mostly see objects.
Accounts. Contacts. Opportunities. Activities.
The information is there. The customer is not.
Salesforce can tell you what a customer purchased, when the contract renews, and who belongs to the account. It cannot tell you whether one administrator is doing all the work, whether everyone else is struggling to adopt the product, or whether the feature they requested last quarter has actually helped them.
Those answers live somewhere else.
Product usage shows what people do after the contract is signed. Support conversations show where they get stuck. Email, meetings, and notes preserve the history of the relationship. Each system knows one part of the customer. None of them contains the customer by itself.
For a long time, the data team's job was to move some of those pieces into one place.
Pull the accounts and contacts. Connect the related records. Verify the extract. Calculate a few reliable statistics. Load everything into the warehouse. Then wait for someone to tell us which dashboard they needed.
That work created the foundation. It also consumed most of the time available.
Agentic coding environments give the data team a new place to work. From one workspace, an agent can help inspect the sources, explore the data, connect structured records with written context, build an interface, and keep following the questions as they become more specific.
The old control room was the warehouse. It was where the data came together.
The new control room is where the work comes together.
The old data team made customer data available. The new data team can make customer intelligence available on demand.
When the Function Got Pulled Into Plumbing
For a long time, data engineering looked like plumbing on a building that never stopped changing.
Every new business request meant another line to run. One from the application database. Another from the CRM. Another from a newly important API. All of it eventually tied back to the same utility room: the warehouse.
The work was heavy. Pipelines had to be designed, coded, adjusted, and maintained by hand. When a source changed or a requirement shifted, the line had to be reopened and reworked without breaking everything downstream.
Building and maintaining the system already took enormous effort, so naturally the role narrowed around the pipe.
That shaped what the team could deliver.
When the business asked about customer usage, the practical answer was often a set of reusable measures: logins, active users, accounts by segment, support-ticket volume, and quarter-over-quarter change. Those measures were useful because we could define them, validate them, and make them available repeatedly.
Deeper questions were harder.
Who is doing the work inside the account? Is adoption broad or dependent on one administrator? Which users begin a workflow but never complete it? Did the customer adopt the feature they asked us to build? Do their support conversations explain why usage stopped?
Each question crossed another source, another interface, or another kind of evidence. Answering it meant more extraction, more transformation, more coordination, and usually another reporting cycle.
When every change is manual, teams optimize for what they can keep running. The function narrows around the pipe because the pipe consumes the capacity of the team.
The hidden cost was not only maintenance.
It was how much curiosity the operating model could afford.
The QBR We Had Time to Produce
A quarterly business review makes this tradeoff visible.
A good QBR is supposed to explain the customer relationship. In practice, preparing one is a small data-engineering project.
Someone retrieves the contract and account details. Someone pulls the usage numbers. Someone counts support tickets. Someone searches notes for the last important conversation. The results move into Excel, then into charts, and finally into PowerPoint beside the product roadmap.
By the time the data has been located, reconciled, and arranged, the meeting has arrived.
So the deck contains the information there was time to assemble.
To make the contrast concrete, imagine BeaconFlow, a fictional enterprise operations platform used by regulated organizations to coordinate work across teams and systems. Its customer, Northstar Health, is a regional healthcare network with 68 licensed operations users.
Northstar bought the platform to reduce delays in clinician onboarding. Getting a new clinician ready to see patients requires credentialing, compliance approval, system access, and coordination with the clinic—work that frequently stalls between departments.
The QBR takes place seven months before renewal. Northstar's operations leader wants to know whether the platform is actually shortening that process and what the organization should improve next. BeaconFlow's customer-success manager has the contract, usage, support, and relationship history—but only a few days to turn them into a useful conversation.
Here is the QBR the team had time to produce. It is polished, accurate, and recognizable:
The slide tells us that Northstar Health has a $420,000 annual enterprise contract, 68 licensed operations users, 31 monthly active users, 14 support tickets, and usage that increased eight percent.
All of that is worth knowing.
None of it tells customer success what conversation to have.
Usage is up, but are clinicians getting ready to see patients sooner? Are 31 people meaningfully moving onboarding cases forward, or are they opening the product and leaving? Did the new features reduce delays? Are support tickets routine, or are they evidence of the same operating constraint?
The limitation is not the presentation software.
The limitation is that aggregation consumed the preparation window. The work stopped at the metrics because the metrics took all the time we had.
That was the QBR we had time to produce.
Agents change where the work can end.
A New Control Room
The biggest change is not that agents help data teams write code faster.
It is that they give us a place to operate across the whole customer picture.
I began doing this locally. The goal was not a large production application. I had customer data, product activity, and the ability to explore the relationships between them from an agentic coding workspace.
That changed the questions I could ask.
Instead of stopping at total usage, I could examine usage by account and user. Instead of reporting that a feature had launched, I could see who tried it, who completed the workflow, and where activity stopped. Instead of treating every login as adoption, I could distinguish between browsing and creating something useful.
The agent could inspect unfamiliar tables, connect users to accounts, write and revise the analysis, and keep working as one answer raised the next question.
That last part matters.
Traditional reporting expects us to know the question before we build the report. Customer relationships rarely behave that cleanly. We might begin with overall usage, discover that creation is concentrated in one administrator, notice that other users repeatedly log in without finishing a workflow, and then ask whether support conversations explain the pattern.
The question evolves as the evidence appears.
An agentic workspace can evolve with it.
It can also reach beyond structured data. The commercial relationship may live in the CRM. Product behavior lives in an application database. Support context lives in tickets. Recent conversations may live in Microsoft 365: email, calendar, meeting notes, and documents.
Modern agent connectors make those systems available to the same workflow. The agent can help bridge the quantitative evidence—contracts, users, events, feature adoption—with the qualitative evidence—questions, requests, concerns, and commitments.
The customer exists in those connections.
That is the new control room: not a warehouse that requires every useful fact to be modeled in advance, and not one magic application that replaces every source. It is a shared operating environment where the data team can move across sources, code, analysis, and interfaces while the context is still intact.
The QBR Becomes Software
Once those pieces can be orchestrated, the QBR changes shape.
It no longer has to be a document rebuilt from exports every quarter. It can become a live customer intelligence application that assembles the current relationship whenever the conversation begins.
Here is the same synthetic customer, quarter, and underlying evidence, now presented as an on-demand QBR for BeaconFlow's customer-success team:
The old slide reports account activity. The new view connects that activity to a customer outcome, explains what is limiting broader adoption, and proposes a measurable plan for the next quarter.
The headline is no longer simply that usage increased eight percent.
It is that clinician onboarding is getting faster, but scaling the result depends on permissions and a second administrator.
Workflow templates and two early-access automations now handle 420 onboarding steps each month. Over the same period, median time from a complete file to clinic-ready status fell from twelve days to nine. That does not prove automation caused the entire improvement, but it gives the team a result worth examining together.
The connected evidence also reveals the constraint. Six of the quarter's fourteen support tickets concern roles or publishing access, and only one administrator can move a new workflow into production. Meeting history identifies two adjacent opportunities—payer enrollment and system-access provisioning—for the next quarter.
That turns a usage metric into a customer conversation. Product behavior shows the value already being created. Operations data connects it to onboarding time. Support conversations explain what is getting in the way. Relationship history reveals where Northstar wants to go next.
Together, those sources support a shared plan: complete the permissions foundation, add a second publishing administrator, launch two workflows, and work toward a seven-day median onboarding time.
The same view makes the sequence visible. The recommendation becomes specific without becoming an internal sales script.
The same basic account metrics are still there. They now lead somewhere.
Customer success can now distinguish between product activity, a customer outcome, a likely constraint, and the foundation needed to improve the result. The next conversation can begin with evidence, invite the customer's perspective, and end with a measurable plan for the next quarter.
That is not the same QBR prepared faster.
It is the QBR we never had time to produce.
The difference is not interactivity for its own sake. The application remains connected to the evidence. In a production version, a customer-success leader could move from the insight into the users, features, support themes, and account history underneath it. When the customer asks a follow-up question, the workflow would not end at the edge of a slide.
The system can follow the question.
This also changes the cadence. Customer intelligence does not have to wait for the quarterly meeting. Open the account before a call, after a support escalation, during renewal planning, or when a new adoption pattern appears. The QBR becomes available whenever the relationship needs attention.
From Data Supplier to Workflow Builder
This is where the role of the data team expands.
The old job often ended with supplying the inputs. Here is the account table. Here are the usage totals. Tell us which dashboard you need.
The new job can reach the outcome. What should customer success understand? Which evidence supports it? What should the application make explorable? What conversation should become possible that was not possible before?
The pipes still matter.
They are just no longer the whole job.
The function starts to resemble a general contractor. It still understands the trades: data access, transformation, modeling, interfaces, deployment, security, and operations. But its value comes from deciding how those pieces should come together around the work.
Sometimes the answer deserves a durable pipeline and governed model. Sometimes it begins as a local application that lets the team discover what matters before permanent infrastructure is poured. The data team can prototype the complete experience, test it with the people doing the job, and then decide which parts deserve to become reliable shared capability.
My local customer analysis was not yet a deployed QBR product. It showed what the product should become.
That distinction matters. Agentic development makes prototypes cheap enough to reveal the workflow before the organization commits to the architecture. The useful questions, definitions, connections, and interactions can be discovered first. The durable system can follow once the value is clear.
The agent contributes range. It can explore the data, work across APIs and files, interpret written context, build the interface, test the logic, and revise the experience.
The human remains responsible for meaning.
Only someone who understands the business can decide whether dependence on one administrator is a serious risk or a reasonable operating model. Only the people responsible for the relationship can decide whether an unused feature signals poor discovery, poor usability, or simply poor fit. The agent can assemble evidence and propose explanations. The team decides which explanation the evidence actually supports.
The control room does not eliminate judgment.
It gives judgment more of the customer to work with.
Run the QBR
For years, data teams concentrated on moving information into one room.
That work made cross-system reporting possible. It gave organizations shared definitions, durable history, and reliable measures. It remains essential.
But the role can now extend beyond the room.
An agentic control room can connect the commercial relationship with product behavior, support experience, and the written history surrounding the account. It can move from aggregation into exploration, from exploration into insight, and from insight into a working application.
That is more than a productivity improvement.
The traditional QBR gave customer success a snapshot of the metrics someone had time to collect. The on-demand QBR gives them a living customer view: current evidence, derived insight, and the ability to follow the next question wherever it leads.
The old data engineer kept the line running.
The new one runs the site.
Keep the customer connected to the evidence.
Open the customer.
Run the QBR.