Purpose

This explains the full process for PRS Opportunity and Account name change requests. It outlines responsibilities across PRS, Business Operations, Revenue Operations, and HR. It clarifies how payroll is determined, what the submission windows are, when a discrepancy form is required, and what happens in edge cases.

Scope

• Applies to all posts submitted in the PRS Name and OPP Change Request Slack channel

• Applies under normal operating conditions

Roles and Responsibilities

PRS

• Submit the name change request in the PRS Name and OPP Change Request Slack channel

• Submit within the correct submission window

• Ensure all accurate notes, emails, and documentation are added in Salesforce before submitting the request

• Ensure Salesforce reflects the full interaction history so Business Operations can complete vetting

Business Operations

• Review the Slack post

• Create a ticket for tracking and processing

• Conduct opportunity review

• Conduct account review

• Perform vetting of the meaningful conversation between the PRS and the client

• Confirm there was a documented exchange that moved the client to purchase

• Complete the opportunity name change when validation supports it

• Request additional information if required

• Reject the request if it cannot be validated

Revenue Operations

• Maintain transaction dashboards

• Ensure transaction date and opportunity owner data are accurately reflected in reporting

HR

• Pull transaction reporting directly from Revenue Operations dashboards

• Process payroll based on transaction date and opportunity owner reflected at the time the payroll report is pulled

Validation and Vetting

Business Operations is vetting that:

• A meaningful conversation occurred between the PRS and the client

• The exchange demonstrates influence

• The PRS moved the client to purchase

• Salesforce documentation supports the attribution

If documentation is incomplete, vetting cannot be completed and additional information will be requested.

How Payroll Is Determined

Payroll inclusion is based on:

• The transaction date

• The opportunity owner reflected in reporting when HR pulls the payroll report

HR pulls transactions by transaction date range.

Example first half of month:

• Transactions dated 2/1 through 2/15

• HR pulls that reporting on the internal payroll processing date

• Payroll is paid at month end

If the name change is not completed before HR pulls the report:

• The transaction does not count toward that PRS tier calculation for that payroll cycle

• A discrepancy form must be submitted

• HR processes that commission separately as a discrepancy

The internal payroll processing schedule provided by HR is operational guidance for Business Operations and HR. It is not distributed to PRS and is not the submission rule.

Submission Windows

These windows determine payroll eligibility.

Window 1

• Transaction date between the 1st and the 15th

• Included in payroll paid at the end of the same month

• PRS must submit the request between the 1st and the 15th

• Business Operations must complete validation and the name change before HR pulls the payroll report

Example

• Transaction date 2/8

• Request submitted 2/10

• HR pulls 2/1 through 2/15 transactions on the internal payroll processing date

• If the name change is completed before that report pull, included in payroll paid 2/28

• If not completed before that report pull, a discrepancy form is required

Window 2

• Transaction date between the 16th and the last day of the month

• Included in payroll paid on the 15th of the following month

• PRS must submit the request between the 16th and the last day of the month

• Business Operations must complete validation and the name change before HR pulls the payroll report

Example

• Transaction date 2/20

• Request submitted 2/22

• HR pulls 2/16 through 2/28 transactions on the internal payroll processing date

• If the name change is completed before that report pull, included in payroll paid 3/15

• If not completed before that report pull, a discrepancy form is required

Discrepancy Scenario

A discrepancy form submission is required when:

• The transaction date falls within a payroll window

• The PRS had a meaningful conversation that moved the client to purchase

• The request was submitted within the correct submission window

• The name change was not completed before HR pulled the payroll report

In that case:

• The commission is not included in standard payroll

• A discrepancy form must be submitted to HR

• HR processes the commission separately as a discrepancy

Normal Processing

Under normal conditions:

• Requests are submitted within the correct window

• Salesforce documentation is complete

• Vetting is completed within the operational timeframe

• Name changes are executed continuously

• Payroll includes the transaction without requiring a discrepancy

Edge Case Scenarios

This process assumes normal volume.

Edge cases may impact processing timing, including:

• Large rollover periods where PRS support event sales (i.e Summit) submit name change requests

• Duplicate submissions for the same request

• High ticket volume requiring manual cleanup and verification

During edge cases:

• Ticket backlog may increase

• Vetting may require additional time

• Processing may extend closer to the internal payroll cutoff

These situations can temporarily impact timing due to volume and verification complexity.

Quick Reference

• Transaction date 1st through 15th → Paid end of same month

• Transaction date 16th through last day → Paid 15th of following month

Submitting within the correct window and ensuring Salesforce documentation is complete protects tier calculations and reduces the need for discrepancy form submissions.