Indicators

I sat with reps while they worked, listened to calls, and watched the prep routine happen in real time. Three things came out of it that I would not have got from interviews.

The gap was synthesis, not recall. Nobody was forgetting to check a source. They were being asked to read six of them and produce a coherent story about a client in the ten minutes before a call.

Intent decays fast. Somebody who clicks "book a meeting" is warm right then, lukewarm the next day, and cold by the end of the week. A weekly digest is a way of finding out about warm leads after they cool.

And the signals are not worth the same. A webinar attendance is mildly interesting, a whitepaper download more so, a meeting request is urgent — and an undifferentiated feed flattens all three into the same row.

A standalone Indicators platform was the obvious build. Pull everything into one place, design it properly, ship something modern.

Embedding into the CRM was worse in every way that shows up in a design review. Salesforce's UI constraints, Azure AD, real performance problems at data volume.

I took the second one, on adoption risk alone. A separate tool is another tab, another login, another context switch — and in enterprise sales that reliably becomes the thing people mean to use. Inside the CRM, Indicators is part of a routine that already exists rather than an addition to it.

It cost noticeably more engineering than the standalone version would have. It is also the reason the thing got used.

Seven sources feed it: events, webinars, site visits, email clicks, document downloads, LiveSend engagement, meeting requests. Everything lands timestamped and tagged.

From there it gets sorted along two questions a rep actually asks — what should I talk about, and when should I call — and then scored. Recency inside seven days triples the weight. Action type matters more than volume: a meeting request counts five times a click, a download three. Repeat signals double.

What surfaces is a feed of the warmest leads with a phrase attached, and the whole scoring apparatus sitting underneath it for anyone who wants to know why somebody ranked where they did.

Seven sources on one screen is a lot of screen. My first versions showed everything, and the high-priority signals disappeared into the density — which is the opposite of the product's job.

What fixed it was cutting the default view down to ten contacts and nothing else. The signal timeline is one click in, chronological and color-coded by type. Any individual signal is one more click: for a webinar, the topic, the date, how long they stayed, what follow-up material they took.

Prioritizing and preparing are different tasks and reps do them at different times of day. Once the interface stopped trying to serve both at once, the density problem went away on its own.

- Nobody commented on how it looked. What they cared about was whether the right signal could be found in under ten seconds. Hierarchy and ranking did the work; the visual design's job was to stay out of the way. - It was a coordination layer more than an interface. Indicators sat between marketing tech, data engineering, CRM and sales ops, and most of the hard design decisions were really about which team owned which definition.

I'd get marketing into the room much earlier. They owned the content that generated half these signals, and we aligned on which ones mattered later than we should have — which meant the weighting was tuned twice instead of once.