Go to designs

CS 01 · PartnerIQ — Co-sell (Collaborative sales) intelligence

A sales intelligence platform that replaced spreadsheets, CRM rabbit holes, and cold dinners with a system that told software sales teams exactly who to reach out to, and why.

My Role

Sole designer. Owned everything from problem framing to dev handoff. Strategy, flows, wireframes, prototypes, and iterative testing with real users, daily. The founders knew the sales world inside out, I turned that knowledge into something people could actually use.

The Problem

Who's working the same accounts? Nobody could say.

At the start of every year, software sales reps and AWS reps each get their account lists. Then comes the hard part: figuring out who on the other side is working the same accounts. There's no directory. No shared system. Reps dig through Salesforce and HubSpot, lean on whoever they met at the last dinner, and hope the timing works out.

No way to find the right contact

A rep managing 50 to hundreds of accounts had no reliable way to identify which AWS rep covered the same territory, which accounts overlapped, or who had actually performed in that segment.

Account mapping done by hand

Every co-sell conversation started the same way. Export a CSV, email it across, match rows manually. By the time the overlap was found, the moment had usually passed.

No way to evaluate a new partner

When an AWS rep encountered an unfamiliar software company, there was no single place to understand their customers, their track record, or whether the partnership was worth pursuing. Trust was built slowly, informally, or not at all.

Before

Before PartnerIQ

The raw co-sell relationship

Accounts assigned

Mostly beginning of the year.

Find relevant AWS contacts

Manually, no partner directory. In CRMs like Salesforce and HubSpot.

Sharing spreadsheets

Unstructured format.

Manual matching

Error-prone process.

Back and forth

Weeks of availabilities and chaos.

Co-sell motion begins

On email, Slack, etc. Unstructured record.

With

With PartnerIQ

Co-sell motion on day one

Accounts assigned

Year begins.

Define ICP

One-time setup.

System scores

ICP fit, PTB.

Rep acts

Scan, invite to collab room.

Co-sell motion begins

Day one, not after weeks.

“

User interviews made one thing clear: Sales reps are smart about relationships and impatient about everything else. Every screen had to be immediately obvious.

Who uses it

PartnerIQ was built for the ISV AE. The AWS AE benefits from the system, but the primary unlock — visibility, intelligence, structure — was always on the ISV side.

Persona 1

ISV Account Executive

Who they are

Owns the co-sell relationship from the ISV side. Starts the year with an account list and spends the rest of it figuring out which AWS reps to partner with and which accounts to prioritise. CRM-trained, time-poor, skeptical of new tools unless they save real time.

Goals

Know who to reach out to on the AWS side. Understand account overlap fast. Get warnings before deals go cold.

Pain points

No visibility into AWS rep activity. Account mapping requires manual effort. Deals stall and they find out too late.

Persona 2

AWS Account Executive

Who they are

Works their own account list, looking for ISV partners who can help move deals. Encounters dozens of ISVs, needs a fast, structured way to evaluate whether one is worth investing a relationship in. Benefits from PartnerIQ's shared surfaces, but the product was not built primarily around their workflow.

Goals

Identify ISV partners with account overlap. Understand the ISV's customer base and credibility. Coordinate without being onboarded to someone else's internal tool.

Pain points

No single place to evaluate an ISV. Account mapping requires the ISV to send a spreadsheet. Collaboration happens over email with no shared record.

The Solution

Every pattern had to survive five seconds of real-world use.

Reps have zero patience. Every pattern had to survive five seconds of real-world use before it earned a place in the product. This loop ran almost daily for the length of the project.

Prototype

Multiple versions in parallel
Low-fi to test flow, hi-fi to test feel
Literally built to be thrown away

Put it in front of reps

Almost daily cadence
Real AEs, real ISVs
No demos. Hand them the prototypes

The patience test

Obvious or it's broken
Easy or they quit

Reiterate the next day

Keep what survived
Kill what didn't
Back to prototype

A repetitive journey — next rep, the next day, back to the prototype

The AI Layer

Every signal anchors to one ICP.

Every signal in PartnerIQ anchors to ICP (Ideal Customer Profile). The AI layer threads through the product. ICP Fit %, PTB scores, warnings, contact summaries, and the natural language chat agent all sit on top of the same intelligence backbone anchored to the ICP the rep defines on day one.

Set ICP

Set once on first use

✦ AI Generated signals

ICP Fit %

How well the account matches

PTB Score

Propensity to buy

Warnings

Ghosting, stalls, overdue

Contacts table · Contact drawer · AI summary

The Design System

One system. No wireframes.

Every screen sits on top of one design system, built from scratch as Labra's first designer. That's why this case study has no wireframes. Once the system was created, using ready components for iterations was faster than wireframing from scratch.

Happy path of the ISV rep

The walkthrough, end to end.

ICP defined

Top segments, territories, etc.

Land on dashboard

Top segments, territories, etc.

Scan the table

Fit %, overall activity shape.

Open contact drawer

AI summary and all important info.

Check warnings

Ghosting, stalls, overdue.

Invite to collab room

Safe, common, out of the Labra platform.

Actions logged

Chat, files, mapping.

01Setting up the ICP — Ideal Customer Profile

Before anything else, the rep tells the product who they're hunting for.

app.labra.io/icp

ICP comes first, not later

No "skip for now." Nothing in the product personalises until the rep has defined this.

Multiple criteria, not a single filter

Revenue, industry, employee size, segment, cloud stack, region, marketplace presence.

Multi-select inside each field

A rep can hold multiple industries or regions in one ICP. Real territories aren't single-tag.

Drives every AI score that follows

ICP Fit % shows up on every contact, list view, and AI summary after this point.

02Landing on the dashboard

The first screen a rep sees every morning. The job is fast scanning.

app.labra.io/dashboard

ICP Fit % on every row

The rep's own definition, applied to every contact, visible without clicking.

"Ask Labra AI" in the dashboard

Not behind a menu. The rep can ask questions about their pipeline in plain language.

Activity as a bubble pattern

Not a timestamp. Two tracks per row — contact's activity vs. rep's. Bubble size is engagement intensity.

Top performers and segments at the top

Who's winning, where, in what segment. Context before the rep starts scanning their own list.

Opportunities split three ways

In progress (deals running), closed won (revenue acquired), closed lost (deals dropped). Pipeline state in one row.

03Opening a contact

The rep clicks a row. The drawer slides in.

app.labra.io/contacts

AI summary above the tabs

First thing the rep reads. Prose, not bullets. "Re-summarise" sits next to it because summaries go stale.

Team hierarchy shows reporting lines

The rep sees who reports to whom before deciding who to engage.

Mapped accounts inside the contact

ISV AEs work in Labra day-to-day, not in the Collab Room. The accounts they share with this contact — opportunities, status, ICP fit, PTB score — sit one click below the summary.

"Ask Labra AI Agent" handles depth

The chatbot exists, but it's a click away. The default view is a briefing, not a chat.

04Checking warnings

If a deal is going cold, the rep needs to know before the next standup.

app.labra.io/contacts

Warnings is a tab

Same level as Accounts and Activity. Permanent destination. Buried warnings get checked too late.

↑

We pulled it up

Originally we thought of it as the last layer, below the accounts table. Watching real reps use the early version, we saw they were spending more time on warnings than expected. So we pulled it up.

Each warning names the signal and the action

"Ghosting" → "Consider re-engaging." "Deal overdue" → "Consider closing this opportunity." Tells the rep what's wrong and what to do.

05Inviting to a Collab Room

The rep wants to bring the AWS counterpart into a shared space. They send an invite.

collab.labra.io

Email-only login

For an AWS rep evaluating an unfamiliar ISV, friction kills trust.

Co-branded ISV + AWS, "Powered by Labra"

The header signals shared ownership between the partner and AWS. Labra is the infrastructure, not the brand in the foreground. The AWS rep enters a neutral space, not an ISV tool.

Privacy statement front and center

"This Collab Room is private and can only be accessed by the invited email address." Trust is stated, not implied.

06The ISV's profile

Once inside, the AWS rep needs to know who they're dealing with.

collab.labra.io/overview

Trust signals

Customer logos, testimonials, certifications. The first thing the AWS rep sees is who already trusts this ISV.

Co-sell revenue and opportunity counts visible

$420M in co-sell revenue. AWS-originated and ACME-originated opportunities. The track record is the credential.

Alliance team and sales team named

Real people, real roles. The AWS rep knows who to talk to and what they own.

Collateral and solutions in one place

Decks, briefs, playbooks. No "let me send that over" follow-up.

07Mapping accounts with the other side

Once both sides are in the Room, the first concrete step is comparing books.

Account mapping — other accounts with comments

Both sides upload, both sides see everything

No one-sided visibility. No "send me yours first."

Common accounts highlighted

Overlap is called out, but the full territory stays in view.

PTB and ICP Fit on every row

Reps prioritise overlap by fit, not by alphabetical order.

Comments scoped to a single account

The conversation lives on the row it's about. No context loss across threads.

08Chatting inside the Room

The work and the conversation, in one place.

Chat lives where the work lives

No platform-switching.

All files in one tab

Decks, lists, reports surfaced in a single view.

Phase 2 designs Not shipped

The AI layer becomes an agent.

01Agent conversation

Asking the pipeline a question

The rep asks in plain language. The agent answers, and shows how it got there.

app.labra.io/agent

Labra AI agent answering 'Deals stuck too long' with a visible run trace and ranked deal cards

The work is visible

The trace shows what was scanned, which ICP was applied, and the threshold used. The rep can judge the answer before trusting it.

Chat in, structure out

The answer comes back as ranked deal cards with ICP Fit and PTB on every row. Reps scan, they don't read.

Anchored to the ICP

"Stuck" isn't the model's opinion. The rep's own threshold and ICP decide what the agent looks for.

02Human in the loop

The agent drafts, the rep sends

app.labra.io/agent

Three drafted re-engagement emails, each with approve, edit and skip controls

Approval is per email

Approve, edit, or skip each draft. No "send all."

Drafts show their sources

"Drafted from: demo notes · Jun 12 call." The rep sees what the message is based on before their name goes on it.

The contract is in the UI

"Nothing sends until you approve it." Trust is stated, not implied.

Skipped means discarded

Rejected drafts aren't saved or retried. The no is final, which makes the yes mean something.

03Human out of the loop

Autopilot, inside rules the rep wrote

app.labra.io/agent

Autopilot overnight run — actions handled inside the rep's rules, one held past a guardrail

The rep sets the fence

Stall threshold, ICP scope, daily cap, deal-size ceiling. The agent only moves inside them.

Everything is logged and undoable

Timestamps on every action, undo for 24 hours, all of it in the audit log.

Past the fence, it stops

The $86K deal crossed the $75K ceiling, so Autopilot drafted the email and held it for the rep.

The loop closes overnight

A reply came in at 5:47 AM while the rep slept. But only where the rep said it could.

04Trust calibration

Confident, and sometimes wrong

Reps overtrust confident AI. This screen is built to be argued with.

app.labra.io/agent

Stall-cause diagnosis with per-line Verify links, confidence tied to sample size, and a disagree control

Verify is one click away

Every evidence line links back to its source record.

Confidence = sample size

High means 24 similar deals. Low means 3. The model never sounds more certain than its data.

The bias is on the card

PTB repeats where past deals closed. Saying so on the suggestion itself turns a hidden flaw into an informed call.

Disagreement is training data

"Your call outranks the model." Corrections retrain PTB for the rep's territory.

Impact

ISV AEs went from coordinating co-sell through CRM, spreadsheets and dinner conversations to a system that surfaced partner intelligence before they knew to look for it.

✕Before

—Account mapping done manually over email, took days

—No visibility into AWS rep activity or engagement

—Deal health discovered reactively, after damage done

—AWS reps had no structured way to evaluate an ISV

—Co-sell coordination scattered across email and Slack

✓After

✓Both parties upload lists and see overlap immediately

✓Activity timeline shows engagement pattern at a glance

✓Warnings tab surfaces ghosting and stalls before they compound

✓Collab Room functions as a full ISV profile and trust surface

✓Single shared space with chat, files, and account mapping

Adoption and revenue data sit with Labra post-launch.

Applying AI to the co-sell motion was largely unexplored territory. The product launched at AWS re:Invent and the AI layer drew the strongest response from partners and reps on the floor.

Reflection

The AI layer was the most-praised part of PartnerIQ at re:Invent. It was also the part I'd build differently today. It worked. It scored, summarised, flagged, and answered questions in plain language. But shipping AI is not the same as shipping a complete AI product, and I see the distance between them now.

What I underweighted:

Bias in PTB scoring

PTB learns from where past deals closed, not where the real opportunity might be. A rep following PTB blindly reinforces past patterns instead of testing new ground. No override, no feedback loop in v1.

Concept — disagreement as training signal

What I'd carry forward

Treat AI like a system that's confident and sometimes wrong. Make verification one click away. Use disagreement as training signal. Audit the training data before deciding what to surface.

The response at re:Invent was real. The work I'd take on next is closing the gap.