| Oracle® Retail Returns Management User Guide Release 14.1 E54473-01 |
|
 Previous |
 Next |
The sections in this chapter can assist you in determining your return policies.
When a customer tries to return an item, you might want to consider these and other questions:
Does the customer have a receipt?
What is the condition of the item?
How many days have passed since the item was purchased?
What is the customer's cumulative exception count?
Does the customer have a gift receipt?
Is the (original) transaction a split tender?
In Oracle Retail Returns Management, these questions are called rules.
You can determine what action to take based on the answers to the questions. Your options include the following possible actions:
Continue processing the return, stop and require a manager override, or deny the return.
Send particular response codes or receipt messages to inform the cashier, manager, or customer of the returnability of the return.
Limit the refund to certain types of tenders, depending on the answer to the question.
Require that a positive ID be obtained from the customer so that the customer's previous return history can be checked for similar situations and so that this and subsequent return activity can be tracked.
All of these settings are configured on the response to the rule.
A collection of rules used to determine returnability of a line item to a customer is called a policy. Two types of policies exist:
Default
Exception
Default policies cover all return situations that are not specifically defined by an exception policy. Default policies are always in effect. If Oracle Retail Returns Management does not find a specific exception policy that covers the situation, the engine falls back on the appropriate default policy.
Two default policies must be defined, one for receipted situations and one for nonreceipted situations.
You must decide what constitutes a receipted situation versus a nonreceipted situation so that the receipted/nonreceipted flag can be sent in the Authorize Items for Return request message. For instance, if the customer does not have a paper receipt for a transaction, but the transaction can be retrieved by search, you may choose to treat this as a receipted return attempt. Retailers usually treat returns using gift receipts as receipted return attempts. If you accept item returns without a paper receipt or other proof of purchase, this is most often processed as a nonreceipted situation.
Each line item attempted for return is considered separately as receipted or nonreceipted so that the retailer can mix different return situations within one return attempt, if the point-of-return allows this.
This section helps you determine your default receipted policy.
The following is an example of a spreadsheet used to define a default receipted policy. You may find that using a spreadsheet is helpful for drafting your return policies and distributing them for review or approval within your organization to operational, loss prevention, legal, or other departments that review your return policies.
Flowcharts may assist with evaluating the progress of an attempted line item return through the policy. You may find the flowcharts helpful for drafting your return policies and distributing them for review or approval within your organization as well as for developing test cases and user acceptance criteria.
The first step in policy configuration is deciding which rules you wish to use in evaluating returnability of a line item in an attempted return transaction. Repeat this process for each type of policy you wish to configure.
For information on available rules, see Chapter 11.
The next step is determining the order of the rules. During this process, consider the following features of rules:
Any rule that results in an abrupt response, regardless of any other rules that could be evaluated, should be placed earlier in the policy. For instance, if no returns with receipt after 180 days are accepted, the rule How many days have passed since the item was purchased? should be placed early in the policy, with the range value of 181 (for 181 days) set to a Stop and Denial.
Some rules act specifically to determine appropriate tender response. These can be placed at any appropriate position in the policy.
A rule can be included in a policy more than once. This is appropriate under the following conditions:
A rule checks for a condition in a particular merchandise hierarchy or other configurable input. For example, How many times has the customer attempted to return merchandise from a particular merchandise hierarchy with an item price greater than _ in the last _ days? can be included multiple times in a policy for each merchandise hierarchy that you want to check.
A rule is used for two different purposes within one return policy. For example, How many days have passed since the item was purchased? can be used to determine whether the receipt is older than the allowed number of days as well as to determine whether a potential check fraud problem exists, if it is used in conjunction with the rule What is the original tender? and the value "check."
Your next step is to determine the values that you wish to evaluate for response for each of the rules that you include in the policy.
Determine the action to take based on the answer to the question. Based on the type of question being asked, the answer may be yes or no (Boolean), a certain numeric or currency number (Range), or one possible response from a valid list of responses (Discrete). For instance, Does the customer have a receipt? would have a yes or no response. What is the customer's cumulative exception count? would have a numeric response that would fall within a range that you can configure. What is the condition of the item? would require the point-of-return user to choose from a list of possible responses such as Excellent, Good, Fair, Poor, Open Box, Damaged, Used, Worn, Tags Removed, and so on. The analytic engine can use these to decide returnability.
When determining values for boolean rules, consider the following issue:
Is there another rule that is evaluated based on the choice of yes or no?
When determining values for range rules, consider the following issues:
Do you have a published policy in effect today that establishes limits for numeric values, for example, the number of days during which a return is allowed?
Have you already identified possible patterns of potential fraud for which you need to set limits?
Are there limits on customer behaviors that you wish to put in place?
What tolerance is your organization comfortable setting and publishing?
You can choose to track customer exceptions for some time before configuring range rules in order to help you determine the ranges that you wish to tolerate. You can also change the values on the range rules later, as you use the system to tune your values and return policies.
When determining values for discrete rules, consider the following issues:
Do you want to configure specific actions for types of refunds or item conditions?
Are there different responses or tenders that you want to use in different circumstances, for example, do you want to use a different tender for a return than for a layaway cancellation?
Three possible actions can occur, based on the answer to the question:
Continue—This instructs the system to proceed on to the next rule within the policy.
Continue At—This instructs the system to proceed to a particular named rule name within the policy.
Stop Processing—This instructs the system to discontinue any further processing.
When determining what action should occur, consider the following issues:
Some rules ask a question to determine if the current line item return attempt is a particular type of behavior. These rules should be set to Continue At other rules that determine how many times this particular customer (identified by positive ID) has performed this same behavior in the past. Rules can work together to identify behavior and check the customer's exception history for occurrences of that behavior.
Any rule with a value that should trigger an absolute approval or denial without regard to any other rule should have a Stop Processing action.
The system does not check for potential loop situations. Therefore, it is a good idea to model each policy in a flowchart to determine whether there are any potential loops.
If the rules engine reaches the end of the return policy without encountering a Stop Processing, the response for the last rule is the response that is returned to the point-of-return.
A response type is the decision on returnability that is sent to the point-of-return for each line item attempted for return and for the overall return transaction. The response type assigned to the overall transaction is selected from the response types for the individual line items; it is the one that most constrains the return.
The response types, in order of most to least constraining of the return, are as follows:
Denial
Manager Overrideable Denial—The engine has denied the item but the denial can be overridden at the point-of-sale/point-of-return by a properly authorized user.
Contingent Authorization—The engine has approved the item contingent upon capture of an override at the point-of-sale or point-of-return by a properly authorized user.
Authorization
When determining the appropriate response types for rules, consider the following issues:
What are the behaviors that you want to train your customers to perform? What are the behaviors that are within the limits of your published return policy? These can be set as authorizations.
Are there situations that you wish a manager to approve? Are there situations in your published return policy that state that a manager approval must be captured? These can be set as manager overrideable denial or contingent authorization.
If you intend to allow overrides of responses at the point-of-return, are there always managers available who are authorized to enter the overrides, or can cashiers do so? In smaller stores, if no users have approval to override, you may want to send only denial and authorization responses or configure a separate exception policy for those stores.
Are you comfortable denying returns? The system does not require use of any particular response types, so you do not have to set any rules to justify denials.
You can always change the response types on the rules later, as you use the system to tune your values and return policies.
You can set a configurable response code either to carry on with the Continue or Continue At rule action or to record based on the Stop Processing action.
Responses consist of the following:
A required numeric code
A response type
A response priority within that type
A short description
An optional long description that can be used for scripting customer service responses to customer inquiries
The response type for each response code is selected from the following (listed in priority order):
Denial.
Manager Overrideable Denial—The engine has denied the item but the denial can be overridden at the point-of-return by a properly authorized user.
Contingent Authorization—The engine has approved the item contingent upon capture of an override at the point-of-return by a properly authorized user.
Authorization.
Response codes are prioritized within response types. No two response codes of the same response type can have the same priority. The analytic engine evaluates policy rules. After evaluating the first rule, it selects the first response code based on the answer to the rule. It moves on to the second rule. If that results in a higher response type or the same response type with a higher priority, it selects that response code. This continues until the evaluation process is complete.
Response codes must be configured in the system before they can be selected for use with policy rules. See Chapter 10.
When determining the response codes to configure for policy rules, consider the following issues:
How much information do you wish to show:
On screen to the cashier at the point-of-return?
To a manager at the point-of-return?
On any other manager-paging devices?
To a customer on an e-commerce point-of-return?
To a customer service user handling a phone-initiated return or customer service inquiry?
How fine grained do you wish the responses to be? You can have as few as one authorization response code, or as many denial, manager or overrideable denial, contingent authorization, or authorization response codes as you need.
What level of reporting do you wish to be able to generate? Which of the following do you want to see:
100 Denials
50 Denials for expired receipts, 20 Denials for an excessive number of layaway cancellations, and 30 Denials for nonreturnable open box or worn items
Do you need specific codes to convey information to the point-of-return? You can use response codes at the point-of-return to control reductions in return prices or to suggest or require a restocking fee.
Once the full set of response codes is configured in the system, what response do you wish to use on each rule action in a policy?
You can either let the rules you choose help you build the response codes you should use or let the responses you want to send to the point-of-return drive the rules you want to use in your policies. As necessary, you can change the response codes configured for the rules.
Each rule response can be tied to a specific configurable receipt message. The point-of-return can handle the receipt messages in several different ways:
Print the messages on receipts
Show the messages on-screen to cashiers or customers
Show the messages on customer points of interaction associated with registers such as PINPad devices or customer-facing kiosks
Show the messages on the screen if the return is being processed through an e-commerce site
The message can contain information useful for shaping the customer's return behavior, such as informing a customer why a return was denied or why the return required a manager override or warning a customer that he or she is approaching a limit on return behavior.
Receipt messages must be configured in the system before they can be selected for use on policy rules. See Chapter 10. The identifier for the receipt message is then configured for the rule response. As the rules engine processes the attempted line item return and selects the most constraining response code along the way, it also selects the identifier for the receipt message that was configured for the rule response that picked up the response code. The receipt message picked up for each attempted line item return is sent to the point-of-return in the Items for Return Authorization response message. The point-of-return determines how to use those messages.
Each rule response requires a receipt message identifier, even if that identifier is 0 (no message).
When determining the receipt messages to use for rules, consider the following issues:
Do you wish to provide positive reinforcement for desirable return behavior? For example, for an approved, receipted return, you can configure a receipt message that states the following: This return has been accepted. Thank you for providing the original receipt so that we could process this return quickly.
If there are range rules for a behavior, do you wish to warn the customer that he or she is approaching the limit for the behavior? For instance, if five nonreceipted returns in ten days is your limit for nonreceipted returns, you can configure a receipt message that states the following: "You are approaching the limit for allowable nonreceipted returns. The next nonreceipted return may be denied." You can use this receipt message for the value 4 configured for the range rule How many refunds without receipt has the customer performed in the last _ days?.
Do you wish to inform the customer why a manager approval was required for a return? For instance, if all price adjustments require a manager approval because they can involve cash coming out of the drawer and therefore can be a source of cashier fraud if the cashier is reprinting original receipts for purposes of taking the difference, you can configure a receipt message that states the following: "This price adjustment required a manager override for security purposes. Thank you for your patience." You can use this receipt message for the value Price Adjustment for the rule What is the refund type?.
Do you wish to inform the customer why a return was denied? For instance, for nonreceipted items that have a condition of Out of Box, you can configure a receipt message that states the following: "Nonreceipted items with no packaging are not accepted for return." You can use this receipt message for the value of Out of Box for the rule What is the item condition?.
A rule response can include an indicator that requires a positive ID; in other words, the rule cannot be evaluated unless a positive ID is obtained. In that event, an additional roundtrip to Oracle Retail Returns Management is made from the point-of-return for a second evaluation once a positive ID is obtained from the customer.
If a positive ID is not provided in the Items for Return Authorization request message and the rules engine reaches a rule that requires a positive ID, an indicator that a positive ID must be collected is sent in the Items for Return Authorization Response message. The system skips the evaluation of that rule and continues through the policy to the next rule. The need to collect a positive ID does not stop policy evaluation, because another rule response can cause the return to be denied, regardless of whether the positive ID is used to check customer history.
When determining which rules require a positive ID to be collected, consider the following issue:
All rule responses that concern a behavior for which you wish to check the customer's history should require collection of a positive ID. For example, for the rule Does this item, and the date on which it's being returned, fall within the Return Pattern Watch file?, the rule response Yes should be set to collect positive ID. The rule that checks the customer's history, How many Return Pattern Watch exceptions does the customer have in the last _ days?, should also be set to collect positive ID.
You also determine the tenders that are allowed for the return. When the response to a particular rule is Continue or Continue At, the tenders set for that rule response carry forward to the next rule response. If there is no following rule for evaluation, then the tenders collected as a response to the last rule evaluated are the available tenders that are returned to the point-of-return in the response message.
For each rule response, you decide the appropriate action of the rules engine:
Replace the tenders accumulated thus far with a new set of tenders
Add specific additional tenders to the list accumulated thus far
Maintain the list accumulated thus far
You can also select a default tender and establish that all other tenders be used as override tenders. This enables the point-of-return to limit the return tender to a small set of preferred tenders.
When determining which tenders to configure, consider the following issues:
Do you wish for Oracle Retail Returns Management to control allowed tenders?
What are the allowed tenders stated in your published return policy?
What tenders do you wish to allow for return?
What tenders would you never allow for return?
Are there any situations in which you want to limit the allowed return tender to a tender that does not leave the store, for example, limiting nonreceipted returns to gift cards or store credits?
Are there any situations in which you want to limit the tender to one that allows time for more investigation or reconciliation, for example, a mail bank check?
Do you have problems with customers writing bad checks on an original purchase and then returning quickly to try to receive a cash or cash-equivalent refund?
Because the ultimate decision of returnability is performed at the point-of-return when the engine response is Manager Overrideable Denial or Contingent Authorization, you should consider configuring tenders on each rule response, regardless of response type. The point-of-return should discard the tenders for any line items that are not ultimately authorized by a manager override.
On a receipted return where the original transaction was split tendered, the system uses a Least Risky Tenders order to determine the appropriate refund tenders. The tenders of the refund and the amount of each tender are determined by the original tenders used, the amount of each tender used in prior returns, and the order of tender risk as defined by the retailer. Thus, you can control the order in which original tenders are backed out.
If no tender amounts are provided in the Authorize Items for Return Request or are otherwise made available to the rules engine, then no tender amounts are provided in the Authorize Items for Return Response.
To draft your default nonreceipted policy, repeat the same steps you used to draft a default receipted policy.
When determining your default nonreceipted policy, consider the following issues:
Do you accept nonreceipted returns?
What are your published policies for accepting nonreceipted returns?
Are there different behavior tolerances, time frames, and tenders that you wish to enforce for nonreceipted returns?
Do you wish to limit all nonreceipted return activity to a particular tender?
After drafting your default receipted and default nonreceipted policies, draft your exception policies. Repeat the same steps to configure exception policies that cover items, stores, or time frames that differ from the default policies.
When determining your exception policies, consider the following issues:
Are there items that you need to treat in a manner different from the majority of your items?
What are those items?
Are they related to each other within the merchandise hierarchy?
What are the published return policies for those items?
Are there return-guaranteed items, such as house brand items?
Are there items that are problematic or under recall by the vendor so that they are always accepted for return?
Are any items never accepted for return?
Are there items that are not accepted based on condition, such as worn swimwear or out-of-box small electronics?
Are there items for which you need to control the return tender?
Are there stores that you need to treat in a manner different from the majority of your stores?
What are those stores?
Are they related to each other within the store hierarchy? If not, are they defined together as a store group? (For information on setting up the store hierarchy, see the Oracle Retail POS Suite Implementation Guide, Volume 1 - Implementation Solutions.)
Are there stores that should be watched more closely because they have more Manager Override points than the defaults?
Are there stores that could be watched less closely because they have fewer Manager Override points than the defaults?
Are there stores that do not always have users with manager access on duty?
Are there time frames, such as holiday seasons, that you wish to configure in a manner different from the defaults?
What are those time frames?
What is different about those time frames?
Do you need fewer manager override points?
Do you need more or fewer authorization or denial points?
Do you need more relaxed tolerances?
Do you need more stringent tolerances?
Are you changing your published return policies as of a set date?
Two examples of exception policies are shown on the following pages.
