Transparency · Manage Deal Registration

From rejection to resolution

Partners got denials without explanations, and fixing anything meant starting a new registration. I designed Needs Attention, a new state between approve and deny that turns a problem into a task.

• Needs Attention first: every deal waiting on the partner is surfaced at the top of the overview.

• Partner-facing statuses: submitted, under review, decided, or closed, in plain language.

• Response deadlines: partners see exactly what ServiceNow needs and by when.

• Edit in place: fix the issue, or accept a proposed deal-type change, without re-entering the registration.

• Comments tied to the deal, plus a named account executive and partner manager.

AFTER: Needs Attention leads the overview. Statuses say what to do, and expiration dates turn red as they get close

AFTER: Instead of a denial, ServiceNow proposes a fix. Here the partner can accept a change from Resale to Influence in one click.

Clarity · The registration form

A smarter form won't fix a broken experience

Every part of registration should be easy to understand, from filling out the form to knowing why a deal qualifies. An early AI-generated prototype updated the form's look but kept its problems: buried approval-critical fields, rules partners couldn't follow, and eligibility found only after submitting. I pushed to fix the structure instead.

• Deal types grouped by how partners sell: Sell through or Sell with.

• Each type written as the partner's role, not program terms.

• Approval-critical information first.

• Ineligible types disabled by territory.

• Six steps cut to three.

BEFORE: Five deal types in program language, chosen first, with an error shown before the partner had done anything.

AFTER: Products and sub-products come first, then "Select your role in this deal." Types the partner can't register are disabled.

First, make the form make sense. Then make it smart.

Consistency · Agentic AI

Translating business rules into plain language

The approval rules came from the business, and AI Engineering turned them into prototypes. Each handoff added its own language: policy terms from the business, technical terms from engineering. Partners speak neither. A score could be accurate and still not tell a partner what was wrong or what to do.

I came in to translate. For each rule, I designed what a partner actually needs to know: what's wrong, why it matters, and what to do next. The same rule reads the same way everywhere, in the form, the score, and the deal page.

The rule: "ruleId": "country"
What the partner sees: End customer country is not in your approved territory. Request territory approval to sell in this country.

AI works within the existing review process instead of replacing it. It recommends a business objective, shows an approval confidence score before submitting, and sends low-confidence deals to a person for review.

AI-assist account search. Duplicates show up at the first step, not at denial.

From there, AI recommends a business objective, shows an approval confidence score before submitting, and sends low-confidence deals to a person for review.

This is where most preventable denials start. Existing opportunities and other partners' registrations were the top reasons deals got denied.

The AI-recommended business objective, and the approval confidence score at High and Low.

I built my own prototypes in plain language within a day and tested them with eight core stakeholders, so business and engineering could see the rules the way partners would. Those sessions also surfaced missing territory rules, so I added guidance and a way to request approval. A Low score now leads to a next step.

AI recommends; people decide. The score guides partners rather than blocking them.