More Flexible Order Subtotal Fields
Planned
I have spoken with a handful of current and prospective users, and I would like to propose that having the payment info for an order that has gone though fulfillment locked down is a huge issue from a usability perspective.
Unfortunately there are situations when it is necessary to refund a customer after their order has been fulfilled, but without processing a return.
For example, what about when your carrier misses the delivery date? UPS/Fedex will issue a refund to you, but you need to then refund your customer directly.
Or what about when an order is not handled as well as it should be, and customer service wants to offer an olive branch to a customer?
Sure, right now you can use the workaround of processing a return without restocking any items, but that is a stop gap solution, and we've already had a customer want to then return that item that was used to process the refund initially.
Instead, I propose that all of the subtotal fields (discount, shipping, sales tax, etc.) fields for an order be editable even after an order has gone through fulfillment. Perhaps that should only be available for a certain period of time that is configurable in System Config.
There are concerns here, most notably in the form of financial reporting and visibility of that payment activity that occurs after the order has gone through fulfillment, but I think those can be detailed and dealt with responsibly.
Something that would allow us to recalculate the balance due on an order, and then a submit button to automatically refund funds (or capture if a credit card is provided and a balance is due) would provide much needed functionality for real world scenarios that are constantly encountered, and today require a supervisor to log in to our virtual terminal to resolve.
-
I very much agree with Jason. RO is solid with order processing and routing, but basic order management and order adjustments after shipment are fully lacking. Marketplace orientated businesses make far less order edits, but direct eCommerce, phone and POS channels require a large percentage of order adjustments and we are learning that RO has no functionality in this area. Workarounds will cause significant accounting reconciliation issues that are inefficient and frustrating.
-
Great feedback here! We've commonly referred to this feature as "Miscellaneous Charges & Credits". The edge cases where this is needed for operational flows are well understood and this is on the roadmap for completion.
Jason is correct in that financially accounting for these charges and credits will need to be done carefully. To this end, the feature addition will likely include the ability to record a reason code for the adjustment.
-
Thanks for the feedback Sam. I'm working with our account manager to surround the various improvements that need to be made to the Customer Service tool, and then will likely look at an FSA to move this up the priority list.
The many improvements in efficiency that we gain with RetailOps are completely off-set when required functionality such as this is not present, so this really is a huge priority to get resolved.
If anyone else is interested in sponsoring an FSA with us, let me know and we can explore that option. In the meantime, if RetailOps is OK with it, I'll post an update regarding the functionality we are requesting in this topic so that we can make sure we get feedback from users to address all of the issues in the first go-around.
-
Hi Jason and Patrick,
We're trying to understand different use cases surrounding miscellaneous charges and credits here. We understand different credits that you might want to offer customers. But could you provide use cases for charges you may apply or cases where you would adjust amounts up?
-
1. Customer adds on to an order
-
It could be before or after its in the warehouses hands. We have to charge the credit card on the order.
-
If the value goes down we have to be able to refund the correct amount on the order.
2. Un-cancel an order
-
Customer calls and cancels an order and then changes their mind. It’s nice to be able to re-instate the same order number and use the existing credit card authorization or create a new auth.
3. Cancel an order AND void the credit card auth.
4. Revise Quantity on an order
-
Customer needs to add to subtract quantity of an item.
5. Change the price on an item
6. Customer forgot to add on their free shipping or a coupon code. Would need to refund.
-
-
Patrick hit the high points. Basically there will always be scenarios where the total on an order needs to be updated post fulfillment, so having a way to do that from within RetailOps, and also settle the resulting balance or credit due is what we're after. Right now any of that has to be done from within our virtual terminal, which is not something that I'm going to give an hourly CSR access to.
Additionally, when a payment or credit due does happen, there's no way to resolve that currently, which means our reporting is off and there will always be a balance or credit due on that order.
In addition to this, we also need a more robust payment terminal from within the CS tool. One that allows us to process refunds directly (back to the original payment method or as a store credit) in addition to capturing a balance due.
Finally, there is a bug in how the balance due field is currently calculated. RetailOps shows a balance due of $0.00 when a credit card authorization has expired (this can be remedied by manually abandoning the authorization but not if the order has already gone through fulfillment.
-
Hi Patrick and Jason,
Thanks for your responses.
We've already queued up functionality to be added for miscellaneous credits back to customers. This would cover the scenarios mentioned in, Jason, your original posting. This would also cover, Patrick, some of your use cases: decreasing value from adding to an order (#1), subtracting quantity (#4), decreasing price (#5), and customer forgetting a coupon code (#6).
However, we would still like clarity on miscellaneous charges applied post-fulfillment.
- Currently, there is functionality to add items and increase quantity of items on orders while in "Processing" status. Doing so will create new shipments to be fulfilled under the same order. You can also add another payment charge for those items. If you would like to add items or increase quantity post-fulfillment, would it make sense then to simply create new orders?
- Similarly, there is currently functionality to increase the price of items while the order is in "Processing" status and take additional payment for that. In what situations would you increase the price of items post-fulfillment?
We would also like clarity on two other situations that, Patrick, you had mentioned:
- Un-canceling orders. Once an order is canceled, that brings the order to a full stop. We could possibly add the ability to duplicate orders. This would create a new order with the same items, customer, and shipping service as the previous, canceled order. However, you would need to re-take payment. Would this interest you?
- Cancel an order AND void the credit card auth. Credit card auths typically expire after 3-5 days. In what cases would you want to void the CC auth instantly?
-
Quan:
New Item 1An additional frequent issue I have noticed that I want to be sure will be covered is as follows:
- Customer places an online order for $500 for 5 items at $100 each and the card was authorized for $500.
- Unfortunately, we could only ship 4 of the items due to a stock issue or order change and it's now a $400 order.
- The order is shipped and the card is now captured for $400, which is correct.
- However, the original order is still for $500 and RetailOps shows that we are short $100? Technically, we are not short $100 since we only shipped $400 in product, but with the order fulfilled already this cannot be corrected?
This is a perfect real-world example of having no flexibility with order adjustments after shipment and RetailOps actually is creating an incorrect short order alert. This is primarily an issue in accounting reconciliationa nd reporting, RetailOps thinks the payment is short when the amount due should be adjusted lower to what actually shipped, not what was ordered.
Misc. Charges Post Fulfillment
We prefer to make adjustments to existing orders and NOT create new orders, even post-fulfillment. A new order is not needed in many cases, just pricing adjustments credits or refunds for various reasons on the existing order. If a new order or items were needed, we would just create a new order.
Increasing prices post-fulfillment for items would be rare, but could occur if a pricing mistake was made and found later. However, increases in shipping prices could occur more often. Mainly price decreases would occur for items and shipping, but either scenario should be allowed for and is allowed today in our current system.Un-cancelling Orders
Today we can uncancel an order and utilize an existing credit card auth. over the phone. This is not frequent, but it occurs often enough that we see it as a needed feature. This also saves times as we do not need to ask for payment details again, we just re-instate their existing order and payment info. Copying and creating a new order would require us asking for payment again, adding time and frustration to the customer experience that already gave that info. While it's not our fault they canceled the order, it would be ideal just to re-instate it as we do today.
Void Auths
3-5 days for an authorization to expire is not always the case. This depends on the merchant processing configuration and the cardholders bank. Merchant settings are often 1 day, 3 days, 7 days or 30 days for authorization expiration dates and cardholder banks can add additional time as well. Anytime auths are active they are taking away from available credit for a customer and with debit cards actual cash they can access in their bank accounts. The two main scenarios we run into with this is really as follows:- Large customer orders $500, $1000, $10,000 that we could not ship or the customer cancelled and we need to cancel it and void the auth. We do not want to hold-up their available credit balance when we are not shipping the product.
- We also get complaints from customers, particularly around the holidays, when we cancel small customer orders that are often gift purchases using debit cards with limited cash availability. We have had many calls from a gift buyer that only had $200 in cash on their debit card and the $150 gift they bought that they subsequently canceled is not allowing them to access the $150 in cash until the authorization expires.
These are all real-world situations we deal with every week, some more frequent then others and we have functionality today to deal with these scenarios in our current systems. With RetailOps we do not have any functionality in these areas and work-arounds are inaccurate, inefficient and cause accounting reconciliation issues.
-
Patrick,
"New Item 1", please submit a support request with a specific order so we can take a closer look. This behavior you're describing is not as expected.
"Misc. Charges Post Fulfillment", most of the references here are covered under the scope of credits, you mention rare cases in which you charge customers more after fulfillment, but the use case is still not clear. Adding the functionality to charge more with a reason code associated is not a difficult thing, we're concerned with understanding the use case to implement the solution in the most appropriate way. Many systems provide users the ability to do things that they really should not do increasing risk to the retailer.
"Un-cancelling Orders", understood that re-using an existing auth is the desired outcome. Unraveling a canceled order is non-trivial. We'll put this in the hopper, but in full transparency, at this time this feature is not a high priority feature.
"Void Auths", the necessity here is well understood. We have this caveat in scope for development presently.
-
"New Item 1" - Got it. We have several examples.
"Misc. Charges Post Fulfillment" - Order mistakes occur, especially in high touch cases with customers or when we are adjusting item prices as part of a customer negotiation. If we have undercharged a customer after the order has shipped, we should still have the ability to increase the item prices, shipping and related taxes to then charge the customer an additional amount with ease and a reason code. Sometimes this might be discovered within a short period from shipping within the same day. While I would like this to rarely occur, that's not reality as we often have to make changes to pricing on orders and sometimes these changes are caught after shipping. You could create alerts and warnings that prevent undercharging during processing an order based on certain preset thresholds, but allowing adjustment of pricing and subtotals on items and orders with proper reason codes is likely a simpler and much more common approach.
In our business today we had a very large order where I noticed a pricing mistake occurred with shipping and the customer was undercharged. Why should we not be able to simply make an increase adjustment and charge the customer the additional amount when these situations occur? Shoudl the order be locked down entirely and forced the make this change in a virtual terminal outside RetailOps and causing an variance in accounting reconciliation? If the credit card batch was not yet settled within the same day, the capture amount can be edited before settlement in some instances.
"Un-cancelling An Order" - Ok, this is something we get a request to do several times per week and is a real and common request that saves time and increase efficiency with our customers. This will likely be requested by other RetailOps customers.
"Void Auths" - Thank you.
-
I appreciate the spirited conversation on this topic and look forward to improvements in this arena. Rather than focus on specific examples, it seams like there are a couple of general scenarios that need to be supported:
-
Creating a Credit Due to Customer
There are multiple scenarios where this can occur (reducing the price of a product, adding a discount, reducing the shipping charge, etc.) and it sounds like this one is already planned.
I would appreciate seeing the scope for this implementation before development begins, just to make sure there aren't any key holes. For example, when a refund is due we should have the option to issue that refund back against the original payment method, or as a store credit (I can provide support for this use case if needed), so I hope that is baked into this fix.
-
Creating a Balance Due from the Customer
I appreciate RetailOps wanting to fully understand the use cases that can lead to this situation to make sure they are not opening a door for us to step off a cliff through. At the same time, the reality is that there will always be real world use cases where this occurs.
For example, this happened today on an order (106763) when a customer placed their order in channel and selected our Local Pickup option. The customer does not live locally, so a CSR called them to confirm the shipping method as is our standard policy, and discovered that customer just didn't want to pay for shipping, so chose the "free option" without reading what it was. After explaining the shipping our CSR then changed the shipping method but prior to entering a price for the shipping amount, the order went through fulfillment. At that point the shipping field was locked so it was impossible to update the shipping amount.
Now understandable this is an edge case where everything happened perfectly, and that window is pretty small, but the reality remains that it is absolutely possible to end up with a balance due from the customer after an order has gone through fulfillment.
An additional scenario that is very real for us is when an order is fulfilled without a valid payment capture. Basically an order leaves our warehouse but the request to capture on the authorization failed. In that scenario there is a balance due from the customer, and RetailOps raises a system alert, but because we can't void the authorization to get the due field to recalculate and apply a payment there is no way to clear that system alert. That creates a very low signal to noise level, as we have literally hundreds of payment settlement system alerts that we will never be able to clear out.
Other Topics:
- Un-canceling an order: This is a very real need that we have as well. Miscommunications happen, customers change their mind, etc. Additionally, this is further support for a "lock" feature I would like to see added to orders. Similar to the lock in the PIM, I would like to be able to control which things are changed without first "unlocking" an order. That's just a nice second check to make sure you're not doing something accidentally.
Potentially the Push <-> Hold relationship could be used to manage this. For example, before making any material changes to an order (adjusting QTY, changing prices, canceling, etc.) you would have to put the order on hold. When the changes have been made you would then need to re-push the order, which forces it to go through the screener to ensure there aren't any issues (balance due, invalid items, etc.) - Void Auths: Agreed, we need the ability to right click on an auth and select the void option to force a void with that settlement. Looking forward to adding this.
As terrible as Stone Edge/Monsoon Order Manager was in a lot of ways, they actually managed all of the payment issues on orders VERY well, with lots of automation in normal scenarios and a good deal of manual control for flexibility.
Thanks for listening to our requests to make RetailOps better, these changes are something that will only be requested more in the future.
-
Creating a Credit Due to Customer
Please sign in to leave a comment.
Comments
14 comments