SERVICENOW PARTNER EXPERIENCE
Partner Operations
One partner request crossed five systems. I redesigned the operating model around the work rather than around the product boundaries underneath it.
I brought the teams that owned those five systems onto one canonical request, and left genuinely local data with the system that owned it. In production it cut manual processing 30% for 1,000+ internal users.
DR-4471
Deal registration for Brightmoor Health
- Channel partner
- Ardsley Technology Group
- Assignment group
- Partner Operations
- Assigned to
- Heather Kowalczyk
- Draft
- Submitted
- Under Review
- Pending Approval
- Approved
The turning point
Five systems started reading one request instead of holding five copies.
I was the lead product designer on the partner workspace, accountable for its workflow model, roles and permissions.
A partner’s request ran through five products with separate logins, each asking for the same details again, and none able to say where the work stood. Mapping the three largest partner segments showed most of that fragmentation was structural, not essential: the handoffs existed because the products did.
I brought the five owning teams onto one canonical request and left genuinely local data with the system that owned it, field by field. The teams did not want to lose their own surfaces; the handoff drop-off data moved them. Five systems now depend on one schema, so later changes need cross-team agreement.
- Sign-in and profileSign in
- Deal registrationSign in
- ImplementationSign in
- EnablementSign in
- Co-marketingSign in
One request, five products
A partner's request ran through five products, each with its own login.
Company details
Implementation, step 3 of 5
Asked again at every step
Each product asked the partner for the same details again.
- RequestDR-4471
- AccountBrightmoor Health
- State?
Nobody could say
None of the five products could say where the work stood.
Retire portal?
Teams held their own surfaces
The five owning teams did not want to lose their own surfaces.
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.
Where the five records disagree
- Record ID
- USER-88214
- Channel partner
- Ardsley Technology Group
- Contact
- Gina Ferraro
- 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
- Gina Ferraro
- State
- Under Review
- Assigned to
- Heather Kowalczyk
- 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
- Gina Ferraro
- 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.
Partner relationship platforms move a registered deal through visible stages that the partner and the company both track.
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.
Access control standards attach permitted actions to roles, and portal platforms decide what outside users can reach by assigning them roles.
Standing at the partner's screen, in Partner Portal. Registers the deal, then waits.
Deal registration
DR-4471Brightmoor Health
- Draft
- Submitted
- Under Review
- Pending Approval
- Approved
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.
ServiceNow / Partner Operations
One request across every handoff.
Deal registration
DR-4471
Under Review- Partner
- Ardsley Technology Group
- Account
- Brightmoor Health
Related record
Implementation
Delivery plan and staffing
Shared facts. Separate delivery work.
Shared facts stay on DR-4471. Delivery work stays on PRJ-2207.
Assignment
DR-4471
- Team
- Partner Operations
- Reviewer
- Heather Kowalczyk
Activity
09:02Submitted
Ardsley Technology Group
09:16Review started
Heather Kowalczyk
Unchanged since 09:16
Reviewer changes. Status stays.
The reviewer changes. The request remains under review.
Partner view
DR-4471
Under Review- Account
- Brightmoor Health
- Current team
- Partner Escalations
- Reviewer
- Tom Bergstrom
Commercial details
Margin band
Restricted to internal reviewers
Ownership visible. Terms restricted.
Partners see who holds the request without seeing restricted terms.
My role
I designed one partner workspace and the record model behind it.
My responsibility
I decided which system owns each field of a partner request, which seat can act on it, and what a partner sees when a field is withheld.
I worked with the five product teams whose separate portals the workspace replaced.
Request DR-4471
- Account
- Brightmoor Health
- Margin band
- Withheldinternal reviewer
How I worked
Mapped workflows across the three largest partner segments. The common workflows fell into a small set of repeating patterns, so most of the fragmentation was structural rather than essential.
Organized the workspace by workflow stage. It follows the deal or implementation a partner is moving forward, not the order in which ServiceNow shipped its products.
Designed the role, approval and escalation model. A withheld field names the seat that holds it. The related approval automation cut manual processing time by 30% for more than 1,000 internal users.
Outside my remit
- Product teams system owners
- Data that was genuinely local stayed with the system that owned it, and later schema changes need their agreement.
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
- Heather Kowalczyk 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.
2 Sign-in and profile6 Deal registration3 Implementation1 Enablement3 Co-marketing15
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.
Partner relationship platforms keep a deal as one record: the partner submits it, internal teams update its status, and the data lives in one system of record.
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 OperationsHeather Kowalczyk
- 10:27EscalatedUnder ReviewPartner EscalationsTom Bergstrom
- 11:05Returned to reviewUnder ReviewPartner OperationsHeather Kowalczyk
Consequence
Every status readout has to distinguish lifecycle from custody.
Handoffs the status never showed
Six reconstructed requests. 14 of 19 handoffs left the status where it was.
DR-4483, Ardsley Technology Group for Wexcombe Credit Union
Where it came from
Reconstructed for this site from the systems the request had to cross. Every partner, account and identifier shown is demo data.
From three copies to one request
Three systems holding one deal, then a request that anchors the shared facts.
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.
- Record page, tabs, formOne request became the canonical object
- Assignment groups, roles, permissionsA withheld field still names who holds it
- State field and approval engine
- Partner Portal and Partner WorkspaceThe information model follows stage, not product
Principle
Authority survives automation.
An agent can execute the handoff. It still needs an authoritative record, explicit permissions, current custody, and a lifecycle state that shows whether work advanced.
Tradeoff
Flexibility has a maintenance cost.
Some interactions had to be abandoned or supported through custom configuration the team could not sustain.
Outcome
Five local records became one request.
Ownership was inferred from whoever last touched each one. Now authority and custody are stated on the record.
- Sign-in and profileUSER-88214State: Never knewReads 2 of 6
- Deal registrationDR-4471State: Under ReviewReads 6 of 6
- ImplementationPRJ-2207State: Never knewReads 3 of 6
- EnablementENR-0413State: Never knewReads 1 of 6
- Co-marketingCMP-1190State: Never knewReads 3 of 6
One request, five projections.
Five local records became one request. Each system reads the shared facts and keeps what is genuinely its own.
- Assignment group
- Partner Operations
- Assigned to
- UnassignedHeather Kowalczyk
- Submitted
- Under Review
- Pending Approval
- Approved
30% less manual processing.
The approval automation cut manual processing time by 30% for more than 1,000 internal users.
The two I would add now.
Time to a partner's first useful action, and abandonment at a handoff.
Next measures
- Time to a partner's first useful actionNot yet measured
- Abandonment at a handoffNot yet measured
Compare notes
Working on a product that’s still taking shape?
More work