01 / T-Mobile · IoT Connectivity · Scroll edition

Lead-to-contract shown as a cross-functional control system.

The power move is to show that the user journey is not just a user path. It is an ownership system spanning sales, pricing, legal, design, and platform constraints — and the scroll below walks all seven beats of it, from Einstein-ranked lead to live account hub.

Salesforce · SteelthreadAI lead scoringService designScroll-driven2024 → 2026
01Intake spine
Catalog paths
5Actor lanes
ACDesign-ready acceptance criteria
01 / JourneyUser journey / service map

Five actors, six stages, one shared state.

Every cell is a real handoff. The tinted cells are where the old process lost the deal thread — the redesign made each one an explicit, recoverable state.

Actor
Signal
Qualification
Pricing
Legal review
Contract
Seller
Receives ranked lead and needs confidence.
Captures intake details.
Waits on custom pricing clarity.
Frames customer-specific constraints.
Communicates final path.
Customer
States business need.
Provides locations, devices, quantities.
Evaluates cost and timing.
May not understand exceptions.
Signs or reopens negotiation.
System
Scores lead.
Routes catalog vs non-catalog.
Generates quote logic.
Tracks clauses and risk.
Produces contract package.
Legal
Reviews pricing's work — bottleneck when it arrives unstructured.
Approves clauses against precedent, or flags for renegotiation.
Design
Expose confidence.
Reduce input ambiguity.
Make exceptions legible.
Surface rationale.
Close loop with status.

I design the system lane as deliberately as the seller lane — the system is an actor with its own failure modes, and pretending otherwise is how dual-list pickers happen.

02 / SpineFive checkpoints

Lead signal

Lead quality and seller confidence establish urgency.

Connectivity intake

Locations, devices, SIM/eSIM needs, service type, and equipment constraints.

Catalog fork

Catalog items proceed cleanly; non-catalog needs exception handling.

Pricing + legal

Custom terms, vendor dependencies, and government/enterprise constraints surface.

Contract ready

The output becomes traceable, reviewable, and handoff-safe.

03 / PrimerThe AI upstream
Salesforce Einstein
Salesforce's machine-learning layer. Here it does predictive lead scoring — ranking inbound enterprise IoT leads by fit and conversion likelihood, so sellers spend their week on the deals most likely to close.
Pardot
Salesforce's B2B marketing-automation product. It grades engagement — which whitepapers a prospect read, which webinars they attended — and feeds those signals into the same ranked queue.
Lead → contract → hub 01 / 07
Einstein score × Pardot grade. The queue is ranked before a human touches it.
01 · Lead prospecting with AI

The deal starts before the seller does.

Einstein ranks every inbound lead by predicted conversion; Pardot grades engagement history. My design problem was trust: sellers ignore a black-box score. The queue exposes why a lead ranks — top factors, engagement trail, recency — so the ranking earns the right to order someone's morning.

Inputs: Einstein score · Pardot grade · MQL threshold

02 · Intake

Nine sections, one spine.

The intake replaced a Salesforce dual-list-picker maze with nine explicit sections — vertical, network, hardware, security, bandwidth, international, resourcing, compliance, timeline. Each section is independently saveable and recoverable; a seller can stop mid-deal and another can resume with full context.

9 sections · resumable · visible authorship per edit

03 · Quote

The catalog fork is the architecture.

Everything in the intake routes one of two ways: catalog items flow straight to quote logic; non-catalog needs become structured exceptions instead of email threads. Making the fork explicit is what lets the clean path stay fast.

2 paths · exceptions typed, owned, and tracked

04 · Custom pricing

Special pricing without special chaos.

Connected-vehicle and SASE bundles, volume discounts, multi-year terms — the pricing surface composes them as visible deal components, each with its own approval chain. The seller sees what's standard, what's exceptional, and who owns the exception.

Components: base · hardware · CV bundle · SASE · discount

05 · Legal

The risk sits where customer specificity meets legal review.

Legal sits with contracting — its job is reviewing the pricing team's work. A linear flow under-describes the real problem: dependencies, exception routes, ownership boundaries. The fix wasn't moving legal earlier; it was handing legal structured pricing output — typed components with approval chains — instead of email threads, so review starts from state, not archaeology.

Legal reviews pricing output at contracting · clause precedent library

06 · Contract

The contract is an audit trail that signs.

Every clause traces back to the intake section and pricing component that produced it. The package is traceable, reviewable, and handoff-safe — when negotiation reopens, the team edits state, not documents.

Clause ↔ section traceability · reopen without rework

07 · Account hub implementation

Signature is the midpoint, not the end.

The signed contract instantiates the account hub: orders, SIM activation, fleet status, billing. Post-sale telemetry feeds the next renewal's lead score — the journey is a loop, and the design closes it.

Modules: orders · activation · fleet · billing · renewal signal

D3 · Journey dependency

The risk sits where customer specificity meets pricing and legal review.

I use the network view because a linear flow under-describes the real problem: dependencies, exception routes, and ownership boundaries.

Why this page exists

Principal evidence is constraint evidence.

A senior designer can clean up an intake. A principal designer shows how intake, pricing, governance, and contract readiness become one shared operating model.

04 / OutcomesMeasured, not vibes
Intake time−71%vs dual-list-picker baseline
Handoff rework−58%measured across seller → pricing → legal
AE CSAT4.6quarterly seller survey · n = 40+
Sections shipped9 / 96 follow-on frameworks queued
05 / AcceptanceDesign-ready ACs

The acceptance criteria the design must pass.

Written with engineering before pixels. If a screen can't satisfy these, the screen is wrong — not the criteria.

  • AC-01Every intake state is resumable by a different seller with zero verbal handoff.
  • AC-02Every exception has an owner and a visible status the customer-facing seller can read.
  • AC-03Every price component shows its approval chain before submission, not after rejection.
  • AC-04Every contract clause traces to the intake section and pricing component that produced it.
  • AC-05Reopening a deal edits state, not documents — no re-keying on renegotiation.
06 / ReflectionDefend / redo
What I'd defend

Treating the system as the fifth actor.

Modeling routing, scoring, and clause-tracking as a lane with its own failure modes is why the exception paths got designed instead of discovered in production.

What I'd do differently

Structure the pricing → legal handoff from day one.

Legal reviewed pricing's work from email threads and PDFs for three quarters before we shipped typed components. The journey map flagged that handoff as the bottleneck in week two. I should have trusted the map.