Designing where every deal is a negotiation
- Problem
- Sellers of high-ticket coaching and education products run sales teams on spreadsheets, duplicate products and manual invoices. The platform had checkout pages — but no answer to how a negotiated deal actually happens.
- Solution
- One designer owned the product line end-to-end from 2023: recurring seller research, deal and offer flows, multi-role commission design validated with working coded prototypes, payout and analytics surfaces.
- Result
- Shipped and in production. The segment now runs its negotiated deals, commissions and payouts on this line instead of on spreadsheets — and it kept growing after I handed it over in late 2025.
Role & team
Sole product designer, start to handover
- Early 2023 until I handed the line over in October 2025 — its only designer throughout.
- With product management, engineering, and the growth team who brought the business case.
- Wrote the handover document, ran the walkthroughs, then mentored my successor.
Duration & scope
2.5 years, four surface families
- MVP in production May 2023, after openly reviewed, versioned proposals.
- Deal and offer flows, multi-role commissions, payouts, analytics.
- Evidence base of 29 dated artifacts; eight interview transcripts in 2025 alone.
Key metrics
~11× annual deal volume, launch year → 2025
- Processed volume ~12× over the same window.
- Monthly deals ~×20 by mid-2026, indexed to the first full month after launch.
- Absolutes withheld — these are internal figures, shown as ratios only.
- The line's business outcomes, not causal claims for the design — the contribution is the deal, commission and payout mechanics themselves.
At ablefy, a creator-commerce platform, one segment of sellers sells differently from everyone else: high-ticket coaches and academies whose sales teams close each customer in a personal call. Nothing about that fits a standard checkout — every deal has negotiated products, negotiated installments, and a setter and a closer who each expect a cut.
Before this product line, sellers ran that on duct tape. One maintained over 1,200 duplicate products just to route commissions to the right person. Sales members hand-wrote invoices for hours every month. I joined as the line's only designer in early 2023 and stayed its only designer until handing it over in late 2025.
A deal has to behave like a sales call and like an invoice at the same time, inside a platform that already existed:
- A deal is not a checkout — the flow had to mirror how a sales call actually runs: pitch, negotiate terms, build an individual pricing plan, then send.
- Money must stay correct — commissions, VAT-compliant invoicing per installment, and payouts have no tolerance for design shortcuts.
- Ship inside a live platform — every surface reused the platform's components and order machinery, not a parallel system.
The workaround economy
The research kept surfacing the same picture: sellers weren't missing a feature, they were running a parallel operation to compensate for its absence.
- Duplicate products as commission routing — one product copied per team member, in one case 1,200+ copies. “We make a copy of the main product like ten times for ten people. This makes no sense.”
- Manual invoices — setters spent hours per month writing invoices for closers instead of selling.
- Spreadsheet commission math — sellers hired staff whose job was reconciling who earned what.
- Legal friction — closers accepted terms and cancellation policies in the payer's name during calls, a dispute risk sellers worked around with signed paper contracts.
- B2B buyers needed per-installment invoices; one invoice up front meant pre-financing the whole order's VAT.
An evidence base, refreshed every cycle
The roadmap was never a wishlist. Each design cycle started from data I collected and analyzed myself, and the artifacts kept their dates — usage analyses, target-seller lists, request syntheses, interview rounds.
One example of how the evidence steered the work: a usage-data analysis identified which existing sellers had team-shaped selling patterns but no team setup — the activation targets each cycle designed for.
- 01
Usage data
Platform data analyses of who sells team-style, refreshed twice a year — the activation target list.
- 02
Seller requests
Request syntheses per cycle, deduplicated into problem statements rather than feature tickets.
- 03
Interviews
Recurring seller and team-member interviews — eight transcripts across 2025 alone, most of them run by me, some running two hours.
- 04
Market sizing
A TAM/SAM/SOM model for the segment: high-ticket telesales teams selling virtual products in the DACH market.
What users taught me
The requests said “we need CRM features.” The interviews and the usage data said something more specific — three observations, each of which became a mechanic:
“We make a copy of the main product like ten times for ten people.”
Duplicate products weren't clutter — they were commission routing, built by hand. That reframed the requirement: not CRM features, but per-person commission mechanics on a single product.
When a payment fails, the payer calls their sales member — not support.
A member fielding that call needs the order's truth, not a CRM record of it. So deal states mirror order states — cancelled, closed, pending, charged back — and a deal can never disagree with its own order.
Closers were accepting terms in the payer's name during calls.
One legal observation in an interview split the model in two: a binding deal a closer finalizes in the call, or a non-binding offer the payer accepts themselves — terms, cancellation policy and all. Nothing is agreed in someone else's name.
Dated proposals, argued in the open
The deal flow was not decided in one pass, and the design file keeps the record: a dated proposal page for each round. V1 is dated January 18, 2023. V2 carries the title “Open Review” and February 7. V3 is March 2. Then one page holds two competing directions side by side — a fuller build called “Version Mar15”, and a leaner one called “Shirley's Simplification”. A page titled “Reduced scope”, dated March 15, follows them in the file, and the MVP was in production that May — four months from first proposal to shipped product, with the whole trail still in the file.
Jan 18, 2023
V1
Feb 7
V2 — “Open Review”
Mar 2
V3
One page, two directions
The decision point
“Version Mar15”
the fuller build
“Shirley’s Simplification”
the leaner one
Mar 15 → May 2023
“Reduced scope”, then production
Four months from the first proposal to the shipped MVP.
Deal mechanics, designed decision by decision
The core surfaces grew through openly reviewed, versioned Figma proposals into a deal flow that mirrors the call: pick products, build the individual pricing plan, capture the payer, send. Negotiated installments, future first-payment dates and add-ons ride on the platform's standard order machinery rather than beside it.
View full size
View full size
View full sizeEvery column is a decision
Zoomed in on the shipped surfaces, the money columns stop looking like a table and start looking like the argument that produced them. Five of them:
Role · commission amount · bonus · total incentive
Commission is a rate per role, per person, per product — the setter and the closer on the same deal each carry their own. This was the hardest thing on the line to get right, and the reason two working prototypes existed before any engineering did.
Transfer amount and transfer net, side by side
The base the percentage was applied to sits on the row, not in a help article. A seller reconciling a payout should never have to reverse-engineer which number the commission came off.
Transfer status, including the failure
Money surfaces have to show their failures. Every transfer carries its own status, so a failed one is visible on the row that caused it instead of turning up as a quiet gap in somebody's commission at the end of the month.
Automatic payout, as its own column
Earned and paid are different states. Each member on a deal has their own payout eligibility, so “what did I earn” and “when does it reach me” stay two separate, separately answerable questions.
Deal status, next to price and plan
The states on the chip are order states, one for one. A deal that disagreed with its own order would put a salesperson in front of a customer with the wrong facts.
Close-ups from the live product (test environment, synthetic personas) · the mechanics behind them are the ones argued out in the project's design record
Prototype in code, test, then build
The hardest design question was multi-role commission setting — flexible enough for setter/closer/affiliate splits, simple enough to configure without a manual. Mockups couldn't answer it: the failure modes only show up when someone actually configures a team.
So in May 2025 I built two working coded prototypes — the first the company had — and ran an internal test with four colleagues configuring real scenarios. The test summary picked the direction.
Build one, and watch the money follow
The reconstruction below is playable. It is the flow with the platform plumbing stripped out — four decisions, one running total: pick the products, change the payment plan, move a commission rate, choose how it goes out. The summary on the right re-derives as you go, the way a closer would see it mid-call.
Every deal is negotiated, so the products are picked per deal rather than taken from a fixed package.
Reconstruction, simplified for the story — synthetic products and people · the arithmetic is the real one (VAT 19%, commission on net) · the shipped product has moved on since I handed it over
The bottleneck the surveys found
I treated measurability as design scope: added the missing metrics to the line's adoption dashboards and ran recurring in-product team surveys from 2023 on. The last was a bilingual feature survey designed around awareness branching — sellers who didn't know the analytics existed were routed into them before being asked to judge them. Awareness, not capability, had become the bottleneck, a finding later research kept confirming.
Why it worked
Two and a half years is long enough to see which decisions carried weight. Four did — and one thing the line never solved:
- Reuse over reinvention. Deals ride on the platform's existing order, invoicing and payment machinery rather than a parallel system. Correct money was inherited rather than rebuilt.
- Behaviour beat requests. Every cycle opened by asking who already sold team-style without a team setup, and designed for them.
- One research detail reshaped the whole flow: the binding / non-binding split.
- The expensive question was answered in working software, not in a review. Multi-role commission setting was the one design a mockup couldn't settle, so the direction was decided by four colleagues configuring real teams — months before the real build started.
- And the one it never solved: capability shipped ahead of awareness. By the end the constraint was how many sellers knew what the line could do.
The handover as a design artifact
In late 2025 the line scaled beyond one designer and I handed it over. I treated the handover itself as a deliverable: a structured handover document, sessions walking my successor through every project's background and state, and onboarding her directly onto a live kickoff so the transition happened inside real work, not beside it.
The research archive went with it — as a queryable AI knowledge base built from 29 dated artifacts (usage analyses, interview transcripts, problem statements, test summaries), so the next designer could interrogate two and a half years of evidence instead of reading a folder.
The line kept growing after I left it.
View full size