Skills/Sales
Headless dashboard for AEs
A data model, a dashboard spec and a write-back plan so AEs know who to target without living in the CRM.
Built from the system ofYoni TserruyaCo-founder and CEO, Lusha · GTM 50Download headless-ae-dashboard.zip
Needs: A CRM as system of record, two or more other account or engagement sources, a call transcript source and a RevOps owner. Or run it without installing: connect the GTM Vault MCP and ask Claude to run headless-ae-dashboard.
Built from the system Yoni Tserruya, co-founder and CEO at Lusha, described on GTM Vault GTM 50 (https://pro.gtmvault.co/episodes/gtm-50). Published free by GTM Vault. Yoni gave no result numbers for this system on the episode; your results will differ.
When to use this
Use this when AEs spend their day moving between the CRM and several other tools to work out who to contact next, and when CRM data entry is a manual task reps resent or skip. It fits a sales team that already has a CRM as its system of record and two or more other sources of account and engagement data. The CRM stays in place. What changes is where the AE works and how context gets into the record.
The system on the record
Yoni says Lusha has "the typical stack, you know, like everyone else", but is "starting to be real headless", aggregating data from multiple sources into its own dashboards that are "custom made" for its process (GTM 50, 20:20). The system runs in five parts:
- The starting point. A few months before the recording, Lusha's AEs still opened Salesforce for everything they did (GTM 50, 20:20).
- The aggregated view. Lusha built a custom view for the AEs from data from Salesforce, data from Lusha, data from its outreach, data from back office "and data from multiple sources", delivered as a custom made dashboard (GTM 50, 21:24).
- What the view answers. The dashboard is built so the AEs "know exactly who to target and who to reach out" to, which Yoni says makes their life much simpler and much easier (GTM 50, 21:24). What the AE needs is clear visibility of their opportunities and leads and where to reach out, and that "becomes mainly the dashboard" (GTM 50, 22:27).
- Automatic write-back. Most of the context is inserted into the platform automatically. Engagement is captured on its own, whether email or phone, and when an AE runs a Zoom call with a transcript, the transcript is summarized and inserted into the CRM automatically (GTM 50, 21:24 and 22:27). The goal is to remove everything they can from the AEs' manual work (GTM 50, 22:27).
- The data underneath. Lusha runs its own data through lead scoring, lead enrichment, lead prioritization, outbound and risk assessments of existing customers, using signals such as website visits and reveals (GTM 50, 20:20).
Ownership sits with RevOps. Lusha has no role titled GTM engineer. RevOps owns the middle of the funnel: pipeline generation, sales rep visibility, lead qualification and everything that supports the sales organization and the lead flow (GTM 50, 19:18). Yoni's reason for the move is operational: he expects go to market to become headless at more companies "because it just creates a much simpler operation" (GTM 50, 21:24).
The result
Yoni gave no result numbers for this system. The outcome he describes is behavioral: a few months ago the AEs opened Salesforce for everything (GTM 50, 20:20), and in the months since they almost do not open Salesforce anymore (GTM 50, 21:24). He did not give adoption rates, time saved, pipeline or win rate figures for the dashboard.
Run it on your company
- Ask once, in one message, for: the CRM in use; every other source an AE checks during a working day (data provider, sequencer or outreach tool, call recorder, billing or back office system, product or website signals); the AE team size and segment; the two or three decisions an AE makes most often (for example, who to call next, which open opportunity needs a touch); who owns RevOps; and which engagement types are logged by hand today.
- Map the AE's day. List each decision the AE makes and the screens they open to make it. Output: a table with columns Decision, Sources opened today, Fields used, Time or clicks per decision, plus a line naming the decision the dashboard must answer first. Following Yoni, that decision is who to target and who to reach out to.
- Define the data model for the view. For each source, name the object, the fields the view needs and the join key back to the CRM account, contact or opportunity. Output: a table with columns Source, Object, Fields, Join key, Refresh cadence. Keep the CRM as the record the other sources join to, as Lusha does with Salesforce.
- Specify the dashboard. Define the panels: a prioritized target and reach out list, open opportunities with their last engagement, and any account risk or score fields the data layer provides. Output: a panel spec with columns Panel, Question it answers, Sort rule, Fields shown, Action the AE takes. Every panel must answer a question from step 2, or it is cut.
- Design the write-back. For each engagement type (email, phone, video call), specify how it reaches the CRM without the AE typing it: the capture point, the summary step for call transcripts, and the CRM field or activity it lands in. Output: a table with columns Engagement type, Capture source, Transform, CRM destination, Manual step left (target: none).
- Assign ownership. Name the RevOps owner for the view, the data model and the write-back jobs, and the process for adding a field when AEs ask for one. Output: a short RACI with columns Component, Owner, Reviewer, Change request path.
- Pilot and measure. Run the view with a subset of AEs before rollout. Output: a scorecard reviewed weekly with CRM logins per AE, share of engagement logged automatically versus by hand, time from engagement to CRM record, and AE feedback on whether the view answers who to contact next. Yoni's own signal was that AEs almost stopped opening Salesforce; track CRM logins as the equivalent.
Tools on the record
- Salesforce: system of record the AEs have largely stopped opening, feeding a custom dashboard.
Yoni also names Zoom as the call source whose transcripts are summarized into the CRM (GTM 50, 22:27). The dashboard pulls Lusha's own data, outreach data and back office data (GTM 50, 21:24); he did not name the tools behind the outreach or back office sources. Any tool doing the same job works; the method is the point. Full stack by layer: https://pro.gtmvault.co/stack/operator/yoni-tserruya
Where it breaks
- Bad data in the feed. Yoni's warning about agents applies to any automated layer: when a human worked the data, they knew when it was wrong and flagged it, and when an automated process relies on bad data the damage is bigger and takes longer to find (GTM 50, 7:00). A dashboard that tells AEs who to target spreads errors from any source it joins.
- Manual entry left in place. The system depends on context being inserted automatically so the AE does not have to (GTM 50, 22:27). If reps still log calls or emails by hand, the CRM goes stale and the view loses trust.
- A view that does not answer the AE's question. Yoni measures the dashboard by how effectively it provides the AEs all the data they need to know where to reach out (GTM 50, 22:27). A dashboard that copies CRM screens without prioritizing who to contact gives AEs no reason to leave the CRM.
- Loose targeting underneath. Yoni says teams that succeed at outbound pick the most laser focused target audience rather than large lists without relevancy (GTM 50, 13:24). A prioritized view built on a broad list surfaces the wrong accounts faster.
- No clear owner. At Lusha, RevOps owns pipeline generation, rep visibility and lead qualification (GTM 50, 19:18). Without one team owning the view and its data jobs, fields drift and the dashboard decays.
- Treating it as finished. Yoni describes Lusha's stack as "really evolving now" (GTM 50, 20:20) and its AI work as an iterative process that is never ending (GTM 50, 15:18 and 16:20). Plan for the view to change as the AE process changes.