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.
- 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.
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.
- Record ID
- USER-88214
- Channel partner
- Ardsley Technology Group
- Contact
- Dana Whitfield
- Partner tier
- RegisteredStale, promoted two tiers ago
- State
- Never knew
- 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
- 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
- Record ID
- ENR-0413
- Channel partner
- Ardsley Technology Group
- Contact
- Dana Whitfield
- Certifications
- Two current
- Account
- Never knew
- Record ID
- CMP-1190
- Channel partner
- Ardsley Technology Group
- Account
- Brightmoor Health
- State
- Never knew
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.
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.
- 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.
Held through 2 changes of hands below.
- 08:44SubmittedSubmittedPartner OperationsUnassigned
- 09:16Review startedUnder ReviewPartner OperationsPriya Raghunathan
- 10:27EscalatedUnder ReviewPartner EscalationsTom Bergstrom
- 11:05Returned to reviewUnder ReviewPartner OperationsPriya Raghunathan
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
- Record page, tabs, formOne request became the canonical object
- Assignment groups, roles, permissionsA withheld field still names who holds it
- State field and approval engineCustody moves independently of lifecycle
- 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
