Skip to work
← Select work
HellohireProduct designer

Turning the sales deck into a product feature

The people who decide whether to renew a hiring platform are rarely the people using it. I reverse-engineered the CEO's end-of-trial sales pitch into an automated weekly ROI report. When an outage stopped it sending, customers wrote in asking where it had gone.

The Hellohire usage report, listing interviews scheduled, candidate attendance, outcomes, and interview timing over a year, shown on a laptop.
Role
Daniel – Product, content, and UX design
Timeline
2022–2023
Platform
Email + web app

The problem

Hellohire is a virtual interview platform for high-volume hiring. The HR leaders and finance approvers who sign the contract almost never log in, so the platform's impact was invisible to exactly the audience deciding whether to keep paying for it.

Our CEO ran sales himself and rebuilt an ROI deck by hand for every end-of-trial meeting. Meanwhile, an HR leader at a large restaurant franchise group kept asking for data she could present to her own leadership. Two audiences, one missing artifact.

The sales deck was the spec

Rather than design reporting from a blank canvas, I sat with the CEO and extracted every number the sales team put in front of decision-makers. Then I asked engineering a narrower question: which of these can we compute from platform data without asking the customer anything?

Most of them, it turned out. The exceptions were time-savings figures that depend on knowing a customer's previous process. I cut those rather than fake them with an assumed baseline, so the report's scope was set by what we could say honestly and automatically.

First version: two sections

The first version of the weekly Hellohire summary email, reporting recruitment and screening as separate sections.
Recruitment and screening reported as parallel halves read like two disconnected reports.

Final version: one story

The final version of the weekly Hellohire summary email, framing all metrics as one story.
The deck’s numbers as a product: one story instead of two disconnected halves.

One report, one story

The first version reported the two ways accounts used Hellohire, recruitment and screening, as parallel halves, and read like two disconnected reports. The company was refocusing on screening, so I reframed the whole email around that story, with recruitment data in a supporting role.

For an account with no activity, a weekly report is just a receipt for something they aren't using. That variant drops the empty metrics and invites a call with their account manager instead, turning the report's worst case into a sales touchpoint.

The zero-activity variant

The no-activity variant of the weekly email: no metrics, a note that there were no interviews last week, and a button to schedule a call with the account manager.
No usage, no metrics: an empty report becomes a conversation with the account manager.

The outage that validated it

In week three our email system failed and nothing sent. Several accounts contacted support asking where the report had gone: unprompted proof that just a few weeks in it was already being relied on. Their inquiries also came with a request: generate the report on demand with a date range. That became the in-app report which shipped shortly after.

The in-app report

The in-app usage report with a date-range picker, summary metrics, and a downloadable per-interview detail table.
Version two, scoped by the support emails: generated on demand, over any date range.