Back to work

SERVICENOW PARTNER EXPERIENCE

One partner request crossed five systems. I redesigned the operating model around the work rather than around the product boundaries underneath it.

DR-4471Deal registrationUnder Review
Channel partner
Ardsley Technology Group
Account
Brightmoor Health
Assignment group
Partner Operations
Role
Lead Product Designer
Platform
ServiceNow
Scope
Requests, permissions, approvals
Status
Production, recreated

TL;DR

The platform was organised around products. Partner work crossed them. The redesign gave one request durable identity, explicit custody and a lifecycle that could survive those boundaries.

Five systems held parts of one request. Three authorities each saw a different part. One record had to survive every handoff between them.

DR-4471Ardsley Technology Group for Brightmoor HealthUnder ReviewAssigned to Priya RaghunathanPartner Operations

Case study, Partner Operations

One request. Five records.

How a single partner request existed across five systems.

A deal request entered the partner lifecycle once. It was recreated in every system that touched it, with its own identifier, its own subset of the facts, and in two places its own answer.

01Sign-in and profile
Record ID
USER-88214
Channel partner
Ardsley Technology Group
Contact
Dana Whitfield
Partner tier
RegisteredStale, promoted two tiers ago
State
Never knew
02Deal registration
Record ID
DR-4471
Channel partner
Ardsley Technology Group
Account
Brightmoor Health
Registered opportunity
OPP-11208
Contact
Dana Whitfield
State
Under Review
Assigned to
Priya Raghunathan
Certifications
Never knew
03Implementation
Record ID
PRJ-2207
Channel partner
Ardsley Technology Group
Registered opportunity
OPP-11208
Account
Brightmoor Health SystemDoes not match the registration
State
Never knew
Assigned to
Never knew
04Enablement
Record ID
ENR-0413
Channel partner
Ardsley Technology Group
Contact
Dana Whitfield
Certifications
Two current
Account
Never knew
05Co-marketing
Record ID
CMP-1190
Channel partner
Ardsley Technology Group
Account
Brightmoor Health
State
Never knew
ThreadedThe same fact re-established at each boundaryBrokenThe two systems disagreeOpenThat system never held it

Decision

Organise around the stage a partner is in, not the vendor's product taxonomy.

Cost

Anything belonging to no stage has no obvious home, and each one needed an argued placement.

Two surfaces

One request across two surfaces

Partners work in the Partner Portal. Internal teams work in the Partner Workspace, which partners cannot enter at all. Change the seat.

Standing at the partner's screen, in Partner Portal. Registers the deal, then waits.

nowPartner PortalDana WhitfieldArdsley Technology Group

Deal registration

DR-4471Brightmoor Health

Under Review
  1. Draft
  2. Submitted
  3. Under Review
  4. Pending Approval
  5. Approved

Registration details

4 fields are held by the internal team
Account
Brightmoor Health
Channel partner
Ardsley Technology Group
Partner tier
Specialist
Registered opportunity
Withheldinternal reviewer
Margin band
Withheld
Review note
Withheld
Prior returns on this account
Withheldescalation owner
Approving, returning and escalating stay with the internal team.

Where it stands

Stage
Under Review
With
Partner Operations
Reviewer
Priya Raghunathan

Named on purpose. A partner who can see whose desk a request is on does not open a ticket to ask.

Updates

1 posted
  1. 08:44SubmittedRegistration submitted from the Partner Portal.

Withheld is not missing

A field keeps its place and names its holder.

Escalation is not progress

Custody can change while lifecycle state stays where it was.

Cost

Internal ownership becomes partially visible to external partners.

One object

Canonical request

Not one database, and not a better portal. The work was deciding field by field which system stops owning a copy and starts reading the request. Take any of the five to see what it gave up and what it kept.

DR-4471Deal registrationCanonical
Request
DR-4471
One identifier, replacing fiveStored once
Channel partner
Ardsley Technology Group
Every stage needed itStored once
Account
Brightmoor Health
Two systems disagreed on itStored once
State
Under Review
Nobody outside registration could answer itStored once
Assignment group
Partner Operations
Custody, separated from stateStored once
Assigned to
Priya Raghunathan
The person, separated from the queueStored once

15reads across five systems against 6 fields stored once. Every one of those reads used to be a copy somebody kept current by hand.

Projections

Each system kept what was genuinely its own. What every one of them gave up was its private version of who the partner is, which account it is for, and where the request had got to.

Decision

Make the request canonical; keep genuinely local data with its owning systems.

Cost

Five systems now depend on its schema, so later changes require cross-team agreement.

Custody

Custody vs. lifecycle

Two tracks, one record, and they move independently. Escalate it and only the lower track steps. Approve it and only the upper one does.

DR-4471
Lifecycle
DraftSubmittedUnder ReviewPending ApprovalApproved

Held through 2 changes of hands below.

History
  1. 08:44SubmittedSubmittedPartner OperationsUnassigned
  2. 09:16Review startedUnder ReviewPartner OperationsPriya Raghunathan
  3. 10:27EscalatedUnder ReviewPartner EscalationsTom Bergstrom
  4. 11:05Returned to reviewUnder ReviewPartner OperationsPriya Raghunathan
11:05Returned to reviewException cleared and handed back to the original reviewer.Work notes, internal only

Consequence

Every status readout has to distinguish lifecycle from custody.

Platform

Built on ServiceNow, not beside it.

This is the same workspace, marked for where each part came from. Green came with the platform. Teal is what this work put on top.

DR-4471

Deal registration for Brightmoor Health, registered by Ardsley Technology Group

More actions
State
Under Review
Account
Brightmoor Health
Channel partner
Ardsley Technology Group
Partner tier
Specialist
Assignment group
Partner Operations
Assigned to
Priya Raghunathan
Registered opportunity
OPP-11208
Margin band
Tier 2, standard
Review note
Overlaps an open registration
Prior returns on this account
Withheldescalation owner
  1. Record page, tabs, formOne request became the canonical object
  2. Assignment groups, roles, permissionsA withheld field still names who holds it
  3. State field and approval engineCustody moves independently of lifecycle
  4. Partner Portal and Partner WorkspaceThe information model follows stage, not product
Automation does not remove the authority problem.

An agent can execute the handoff. It still needs an authoritative record, explicit permissions, current custody and a lifecycle state that says whether work actually advanced.

Tradeoff

Staying inside the platform's grammar meant losing arguments about interactions it could not express, and each of those had to be either abandoned or paid for in configuration nobody would maintain.

Outcome

Before

Five local records.

Ownership inferred from whoever last touched each one.

After

One request.

Five projections. Authority and custody stated on the record.

  • 30% less manual processing
  • 1,000+ internal users
  • across approval and escalation surfaces

Not measured

Time to a partner's first useful action, and abandonment at a handoff. Those are the two I would add now.

More work

Continue with another case study.

Lumens AI

An agent does the retrieval. A lawyer does the judgment. The product is the handoff.

Concept build, self-directed

AI REVIEW SYSTEM