Why the customer 360 never sticks

A renewal is coming up in 90 days and somebody has to say whether the account is healthy.

To answer that you need Salesforce for the contract and the stage it’s in, NetSuite for what they’ve been invoiced and what’s still unpaid, Zendesk for how many tickets they’ve filed, Snowflake for whatever the warehouse knows, Gainsight for the health score and the notes from the last QBR, and Pendo for whether anyone is logging in.

Six systems, one question. Most people answer it by opening six tabs and holding the whole picture in their head until the call starts.

Each of those systems is accurate. The contract terms in Salesforce are right. The invoices in NetSuite are right. The work is in putting them together, and that part is manual.

A different question needs a different set of systems

Those six only answer the renewal question. Every other question a team gets asked about the same account pulls from somewhere else.

To find out where there’s room to grow the account, you need product usage from Pendo and email engagement from Marketo. Support history and health scores barely come into it.

To find out who’s gone quiet, you need the call recordings in Gong and the ticket history in Zendesk. The invoices tell you nothing.

To give the CRO a summary before the leadership review, you need all eight.

There’s no standard set of systems for “how is this account doing,” because nobody asks that. Four people ask four narrower questions, and the systems change every time.

Each team needs the answer in a different format

The renewal desk wants a queue, 90 days out, sorted so the riskiest account is at the top. The CSM wants one account page they can open before a call. The CRO wants a single page with no clicking, in hand before the weekly review. The rep wants it inside the CRM record they’re already looking at.

Four formats, four cadences, and only one of them is a dashboard. Build one dashboard for all four and each team gets something close to what they need, which is usually enough reason to go back to the tabs.

What teams build instead, and where each one stops

1. The warehouse project. Model the account properly, then build a view on top of the model. The model usually turns out fine. The view is stale by the time it ships, and there’s nothing on top of it a CSM can open.
2. The spreadsheet. One person rebuilds it every week from exports. It’s accurate the day they build it. It lives on their laptop, and when they take a week off, so does the account view.
3. The point tool. You buy something that does this. It has its own login, keeps its own copy of your data, and connects to one of your systems. It answers one question for one team.

Each one passes one test and fails the other. The two tests are whether it reads more than one system, and whether anyone besides the person who built it can open it.

Building it was never the hard part

Somebody on your team can describe that renewal queue to Claude and have a working version of it by the end of the afternoon. That stopped being the constraint a while ago. What comes after it hasn’t moved. Gartner calls the gap between a prototype and production “the defining constraint in this market,” and says to treat it as “a planning constant, not a temporary limitation.”¹

The app on that laptop fails both tests. It connects to one system, and nobody else can open it.

Getting into that empty corner takes two pieces of work. The first is one account model, built once from every system that holds part of the picture and kept current when a field changes. The second is a view on top of that model for each team: the queue, the account page, the one-pager, the prompt in the CRM. The warehouse project does the first without the second. The laptop app does a version of the second without the first. Tray is where a RevOps team builds both, runs them, and manages who can open what.

What it’s worth when the join only happens once

Zuora used to spend about 23 hours assembling one executive brief by hand. On Tray, the same brief on the same account takes under five minutes. Across the team that’s 170+ hours back every week, which Zuora puts at two to four full-time people’s worth of capacity.²

The brief didn’t get any shorter. Nobody is assembling it by hand anymore.

See one built on a real stack. Paul Turner and Luke Smith take a customer 360 from eight connected systems to an app a CSM can open, live, in 30 minutes. Bring the account view you haven’t been able to ship. Save your seat for the RevOps Masterclass

Sources +

1. Gartner, Market Guide for Enterprise Vibe Coding Platforms, Swan, Bhat, Blosen, 28 April 2026, G00844703.
2. Tray.ai customer story, Zuora. tray.ai/customers/zuora. The 23 hours and the five minutes are Zuora’s own estimate.

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.