of the
Welcome back to the Tipping Truckstop.
This is where fellow tipping truckies get together to discuss topic du jour and add some collective wisdom to complex and often contentious but always fascinating world of Dynamics CRM. Grab a cup of coffee.
Today’s topic is opportunity products in the situations when, uhm, not all your dreams come true. Dynamics CRM 2015 makes some big improvements with products, such as child product hierarchies, product properties, and product relationships. These features are fantastic and remove many of the hurdles to using the product catalog in Dynamics CRM. However, one thing I still trip over with using the standard Opportunity Products relationship is how to best handle win/loss analysis when not all products on the opportunity are purchased simultaneously. What if I have an opportunity that contains 5 widgets, 3 whatnots, and 4 add-ons? The customer decides to purchase the 5 widgets now, buy the 3 whatnots next month, and not buy the 4 add-ons at all (maybe they found a cheaper price at a competitor). If I remove the add-ons for the opportunity, my won/loss analysis for that product is now incomplete (as it doesn’t reflect the items being “lost,” just the “won” items. Also, if I wait to close the opportunity until next month when the widgets and whatnots are sold, the widgets sale won’t accurately be reflected in my opportunity history.
Let’s see what the trucking tipsters recommend:
Feridun “The Fifth Beatle” Kadir: It depends on how the company wants to track and report on the items. For this scenario, I would separate them into multiple opportunities. If they need to be combined, create a self-referential opportunity relationship for parent/child opportunities and link them.
Gustaf “Swedish Elvis” Westerlund: Some organizations also use Quotes and orders within an Opp that just contain a subset of the products of the opp. When the order is created from the quote, the opp isn’t closed, and hence several orders are created from the same opp. When the final order of the opp is placed the opp is closed to the sum value of all orders. This can be used in frame agreements or similar. However, if you would like the tracking on opp-level, I am inclined to agree with Feridun.
Joel Lindstrom: I think the quotes and orders solution can work well if you are going all the way to orders in CRM; however, many large deployments don’t use orders in CRM, they do order entry in the ERP–they may interface the order data back into CRM, but they aren’t manually creating orders in CRM. In that case, having to do quotes on top of opportunities is very cumbersome to users.
Larry “Tex” Lentz: You could also add the close dates to the opportunity or order products.
Gustaf: Another option is to create a new opp for each win/loss, use the “Get Products” to get the products from the original opp, and then remove products from each of the opps according to requirements.
George “$0.02 + GST” Doubinski: While in the past we have implemented complex opportunities by splitting them at the invoice level (similar approach to using multiple orders above), in CRM 2015 I would definitely consider adding a hierarchical relationship and split the opportunity itself (and its children, if needed). Not only the users will get access to the visualization tools, it’d be easy to add new rollup fields that would automatically calculate correct combined opportunity value.
Joel: Thanks guys–you’ve helped me focus my thinking on this topic. There are multiple approaches that we could take, and not a one size fits all solution. It really depends on what you want to track and how you want to report on it.
Another option here is to reimplement Opportunity Products as a custom entity so you can open up the XRM stack for reporting and custom status reasons. It’s a lot of work, but as long as your customer doesn’t want to use Quotes & Orders, and isn’t planning on changing CRM systems already, there’s a decent ROI if their Sales process and reporting needs are more complex than the OOTB Opportunity Products allow. This also allows customization with subgrids, forms, workflow and business rule automation, and all kinds of extended functionality that you just can’t do with OOTB Opportunity Products.
Specifically, in the case mentioned you could have a custom Status Reason called “declined” and one called “deferred” that would remove the revenue from the total Opportunity Revenue, but in the case of deferred items you could automagically create a new Opportunity and Clone those items into the new Opportunity as active line items if you use WorkflowEssentials DistributeWF.
Given how restrictive and tightly structured the OOTB Opportunity Product entity is, I think there’s something to be said for either requiring the business protocol to be adjusted to work within the OOTB stack, or start from the studs and build the sales line items to meet the business requirements, XRM style.
Just a thought. Good stuff guys!
Joe
Addendum to previous comment: all it would take to keep track of the Revenue left on the table for the Opportunity would be to create revenue field(s) for Revenue that wasn’t captured in the Opportunity and roll up the Line Item amounts into the fields based on the Status Reason of the child Line Items (another configuration tool that you can’t use with OOTB Opp. Products). You could then see “I sold $4,000 and left $2,000 on the table, and moved $1,500 into a new opportunity” and track/chart that data macroscopically.
Good stuff, Joe, of course, XRM approach is an option. One thing implementers would want to consider is the minty fresh OOB capability in 2015 to calculate product prices.