The last post ended on a diagnosis. A customer 360 has to serve four people who want four different things to open, from data spread across six to eight systems that disagree with each other, and the join has no owner. One shared dashboard serves none of them. This post is about the shape that does work, and why it needs both: the integration underneath and the app on top, two sides of the same coin.
The work is landing on RevOps
Start with why this is getting more urgent for the people who would build it. Gartner has published a Strategic Planning Assumption that, by 2028, agentic AI will carry out most RevOps tasks across four areas: workflow management, data stewardship, revenue analytics and revtech administration.1 It’s a forecast, so read it as one.
Work backwards from it anyway. If those four areas run on agents in two years, somebody has to build them, connect them to the stack and answer for what they do. That somebody is RevOps. Read the forecast as a promotion: the function that today rebuilds a spreadsheet every Monday is the function that will be asked to put working software in front of the whole revenue team. The pressure RevOps leaders describe is delivery pressure, and it’s about to grow.
Building stopped being the hard part
A RevOps analyst with an AI assistant can build a working account view in an afternoon. That part is solved. What they can’t do is put it anywhere, or hand it to anyone else.
Gartner’s Market Guide for enterprise vibe coding platforms names this directly. It describes the gap between a working prototype and something in production as the defining constraint in the market, and says to treat it as a constant and plan around it.2 That matches what RevOps teams see. The hard part is getting the prototype to the CSM who wasn’t in the room.
Half a 360 never ships
There are two ways to attempt a 360, and each fails on its own.
The data layer alone. You assemble a clean model of the account from every system that holds a piece of it. It’s careful, correct work. Nothing sits on top of it that a CSM can open on a Tuesday, so it turns into a data project with a warehouse at the end, and the renewal desk keeps its spreadsheet.
The app layer alone. Your team builds something real the same afternoon. It reaches one system, because that’s the one credential the builder had. It runs on a laptop, because there’s nowhere else to put it and no login for anyone else. It’s a laptop demo, and it stays one.
Each half is missing exactly what the other has. The data layer has the joins and no front door. The app layer has the front door and nothing behind it. They’re two sides of the same coin, and a 360 needs both.
Two sides, two speeds
You need both, and it helps to see that they move at different speeds.
| What changes | The heavy half: the data | The light half: the app |
|---|---|---|
| What it is | The systems connected, the data moved and joined, kept current | A queue, a page, a brief or a prompt for one audience |
| When it changes | When the stack changes, about once a year | When the question changes, about once a quarter |
| What it costs | Real work, and you want to pay for it once | An afternoon in an AI assistant |
| What happens when it is wrong | Fix it once and every app above it is fixed | Change it in an afternoon, without touching the data |
The heavy half is the expensive thing, and you pay for it once. It changes when you add a billing system or retire a support tool. The light half is quick to change, and it should be: when the renewal desk changes how it triages, or the CRO wants a different Thursday page, you update that one app in an afternoon and the other three teams never notice. Four audiences, four apps, one set of joins underneath. A CSM doesn’t want the CRO’s page, and the CRO won’t open the CSM’s.
The failure mode follows directly. When both halves are one project, every change to a view becomes a change to the data work, so the views stop changing, and the four audiences end up sharing one screen none of them asked for.
One foundation, or two of everything
Two clocks means two kinds of tool, and that’s where the doubling should stop.
If the halves are bought separately, the app layer needs its own way into the same eight systems the data layer already reaches. Now there are two credential stores, two access models, and no single record of what touched customer data. That’s the complaint RevOps leaders raise unprompted, usually right after the security team has asked them which tool holds the CRM token.
On one foundation, the two halves share one set of credentials, one access model and one record of every run. The heavy half reaches the systems. The apps above it reach the heavy half, under the same access rules, and every run lands in the same log.
The objection worth answering first
Anyone who owns governance will spot an apparent contradiction. Gartner calls the prototype-to-production gap the defining constraint, and most people in governance have already watched a vibe-coded app get switched off. Now this post is suggesting the renewal desk run on vibe-coded apps.
The bridge is one sentence. What gets retired is a vibe-coded app that carries its own data, its own credentials and no owner’s name. A per-audience app on a shared foundation carries none of those. Its data comes from the heavy half, its credentials are held by the platform, it has a named owner, and it’s built to change when the question changes. Updating it is routine.
What RevOps teams actually build first
It helps to be straight about the order teams build in, because the 360 comes later than you’d expect. Across Tray’s engagements in the thirty days to 26 August 2026, the pattern looked like this:3
- Per-team reports and dashboards were about half of all first and second builds: a pipeline board, a usage view, a renewal forecast.
- Customer and account 360s sat in the second tier, alongside apps that replace a paid point tool and prototypes that got promoted into production.
- Internal portals and scheduled jobs came less often: an intake console, a nightly digest.
- Agents and assistants were the thing teams wanted most and had fewest of in production. They tend to be a second or third build, once the data underneath them is in place.
The competition for that first dashboard is usually a spreadsheet and somebody’s laptop. A dashboard wins when it replaces a weekly ritual or a single point of failure, and loses when it copies a BI dashboard someone already maintains.
The 360 earns its place anyway, because one set of joins serves four teams, which is the best return available on a single piece of data work. If you’re choosing where to start, pick the app with a renewal date attached. Contractual deadlines get things shipped; good ideas wait.
How Tray does it
Tray runs both sides on one foundation. Tray iPaaS does the heavy integration lifting: it connects the systems, moves and joins the data, and keeps it current, so the apps on top stay light. Tray Helix deploys those per-audience apps. A RevOps analyst describes the renewal queue or the CSM page in Claude Code, Codex or Cursor, and one command puts it on a managed runtime with SSO in front, credentials held by the platform and kept out of the code, a named owner and a log of every run. The CSM who wasn’t in the room opens it tomorrow, with scoped access, and every run is on record. Next quarter, when the question changes, you update that app and redeploy it with the same command, on the same foundation.
Footnotes
-
Gartner, “AI Agents Will Redefine How RevOps Drives Go-to-Market Success,” G00826255, Rietberg, O’Sullivan and Lopez, 9 July 2025. A Strategic Planning Assumption. GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved. Gartner does not endorse any vendor, product or service depicted in its research publications and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose. Back
-
Gartner, “Market Guide for Enterprise Vibe Coding Platforms,” G00844703, Swan, Bhat and Blosen, 28 April 2026. Back
-
Tray engagement observations, 30 days to 26 August 2026. Frequency is Tray’s own count across those engagements, not a survey, and is directional. Customer names are withheld. Back