Andrew Newnham HSO Solution Architect

Functionality to sign up (via e-commerce site, or in store or via call centre), against out of stock products, to receive an email notification when an items comes back into stock. The function should not require the customer to be logged in. It should be possible in HQ to see a list of customers/emails signed up for notifications, which site they signed up on (therefore linked to a warehouse), and for the notifications to be automatically triggered once stock is available again for the selected item/variant, (based on buffers). The notifications would need some intelligence to send X numbers of emails based on Y stock available, (based on a parameter, and set by the retailer based on known conversion rates of these emails to actual sales). Sort order should be configurable based on known customers and a customer priority or just based on sign up date. Once the email has been sent the customer should be removed from the list (or record updated as sent). The notification should be periodic and separated by a number of days. For example, Item 123 has 50 customers signed up to receive notifications 20 units are received into the distribution centre 30 customers are emailed, (As parameter set to 1.5 emails per unit) 5 days later, the available stock is now 10, send out an email notification to a further 15 customers from the list. 5 days later, available stock is now 7, send out email notification to the remaining 5 customers on the list. A further improvement; ability for HQ employee to, for specific items / categories / maybe based on life cycle status, build an email to notify customers that the item will not be coming into stock, and recommend an alternative / related product.

Currently the search capabilities on storefront are specifically around product search. It would be great if that could be expanded to site content. For example a search for store hours returns the store opening hours page, or a search for returns & exchanges return results linking you to the returns policy static page. Additionally to this, it would be great to be able to auto-redirect based on specific search terms - for example, if the search contains the word 'Sale' add a redirect to our summer sale page. This would be manually managed as part of the site builder experience.

Core product data is often updated in preparation for specific events or merchandising activities. For example, the product name, description, category assignment and attribute values may be updated specifically for a sale period. The information often needs to be updated in HQ ahead of time, to support SCM functionality (e.g. procurement, assortment planning, inventory management/distribution). However, it is not possible to control exactly when these changes update on storefront. I know you have some control over the distribution jobs - however as they are change tracking based, it is an 'all or nothing' approach. (e.g. if we paused the 1040 products job whilst the update activities happen, then you cannot synchronise any changes - such as an emergency description change to correct an error). We can control the 'content' using the publish groups in site builder, but not the HQ/Core product data. We need the ability to apply 'activation date' against these changes, so that they only apply when we are ready. In particular this applies to both product category assignment and taxonomy changes to the navigation hierarchies - as this impacts browse experiences and pricing & promotions.

The attribute framework is great for enriching product data and enhancing product discoverability. It would be great if the use of them could be expanded to two areas; Assortments - A scenario that often comes up is that certain products are often restricted for sale in certain markets based on their attributes. For example certain materials are restricted for sale in Canada due to flammability or some countries prohibit the import of goods made from animal furs. The use of attributes on assortments would help in restricting product assortment to specific channels based on their attributes. Promotions - A scenario raised by customers in this area is around attribution such as, the product is including in the summer sale, or the item is a preview item. Being able to control promotion exclusions based on product attribute values would greatly expand our capabilities to control promotional activities at a level other than category. Currently anything we do has to be using a supplemental hierarchy - which is not entirely what they are designed for and results in a lot of maintenance overhead.

There are a number of common scenarios where we require to be able to either link coupons to multiple discounts (currently to 1 relationship), or remove the restriction on a single coupon code value being active at one time. (Ideally the former so you can respect the single use etc. logic). Scenario 1: Triggering multiple discounts/discount types from a single coupon code - for example, With this coupon get 20% off X and free shipping Scenario 2: Enabling different discounts on different days, using the same coupon ('Catch of the day' style). E.g. On Monday's Get 20% Off Mens Shoes, On Tuesday's and Wednesday's Get 10% Off Selected Accessories, At the weekend Get... (This can be set up with separate discounts with the discount period set to apply on the correct day for each - but they cannot share the same coupon code).

The customer search function in the Customer Service form allows you to search based on various criteria, defined by the search criteria setup in Sales & Marketing. It is possible to add postal address to the criteria, but not contact information such as email address or phone number. Email address is the most commonly used way to search for customer accounts. It is however possible to select 'Email address' from the selection box instead of keyword, (although keyword has added benefits of not being exact match due to using full text indexes, so would be better and faster!). Additionally, on the search pop up box (MCRCustSearch form), it displays the search results including the customer address and phone number, but not email address. Again, this is one of the most commonly used methods to validate you have the correct customer account, but you have to open each customer record to identify. Hoping this would be a fairly small enhancement but would make a big difference to call center agents!

Many scenarios in retail orders utilise pre-payments. This may be to take a deposit, or when using payment methods such as cash or gift card. When you take pre-payment for an order, the customer payment journal is immediately (on sales order submit in call center / or on order sync if from CSU) created and posted against the customer account. The result of this is a 'credit' balance on the customer account. Many retailers utilise customer account payments / offer customers credit limits, (common practice in mainland Europe, especially DE & AT, also often used for 'credits' from refunds, or where retailers serve both B2B and B2C customers - such as builders merchants). The result of a pre-payment being taken for an order, causes the credit to be applied to the customer balance. Although the customer transaction is marked as a pre-payment, this value is included is still included within the credit limit calculation. Even when using the sales ledger 'Credit limit type' = 'Balance+All' (which should include open customer orders to reduce the available credit), the pre-payment order is ignored for that calculation, so the pre-payment value is still 'available credit'. As a result, customers believe they have additional credit available to spend against, and the system will allow 'on-account' orders to be created, utilising the pre-payment value. The end result is the last order to be dispatched will fail, as not enough credit is available, (long after the customer placed the order, on the assumption they had enough credit). One example is: - Customer A has a credit limit of $200 - Customer A places and order, and uses their $100 dollar gift card to pay for the order. - Customer A goes online, and their account shows as $300 available to spend (the first order is not yet dispatched). They now create an order for $250 and chose to pay on their account. - The second order happens to be dispatched first - The first order now fails to dispatch, because it will take the customer over their credit limit. This is confusing as the order has been fully paid for using a gift card. Microsoft has rejected this bug as 'Working as designed'. I appreciate this is a cross-team issue in Microsoft, but the scenarios given are specific to retail, hence adding in Commerce section.

The idea is to exclude a basket from having promotional discounts applied to it, if a designated affiliation has been applied to the basket (either based on customer assignment or manually via POS). This will allow us to prevent specific customers from being eligible for promotional offers. Possible implementation: - New field on the affiliation setup 'Prevent retail discounts' - Amend the price engine logic, if any affiliation with the above checkbox enabled is assigned to the current basket, do not apply any retail discounts to the entire transaction. There are a couple of real world scenarios I have encountered where this solution would be utilised. Employee orders - Often times employees are given benefits which exclude them from being allowed to take advantage of promotional discounts on top. Some retailers give their employee an 'allowance' to spend (could be via a gift card or credit on their account) or it could be a set price list specific for employees (whilst this is possible with standard affiliations, you cannot prevent them from getting discounts on top). Customer specific pricing - Another common scenario is for 'elite' groups of customers to be given their own price list, with heavy discounts already included in that price. These customers should not get additional discounts on top of their exclusive pricing.

Problem statement: When a customer visiting an e-commerce site attempts to checkout, they are prompted to enter their delivery address. The country/region picker on the site, displays all country/regions configured in Dynamics 365 HQ. However, e-commerce sites often have restrictions as to where they are allowed to ship goods for reasons such as tax and import restrictions. There are likely also limitations around currency and language translations for the site. The full list of countries are required in Dynamics 365 HQ as this serves the entire ERP application - so for example you may purchase goods for APAC countries, but not support delivery to those countries. Suggested solution: The new feature of geo-detection and redirection added the capability to specify which country/regions apply to an online store. The country/region picker on address creation (both on checkout and customer account pages) should be limited to this list of countries, rather than enabling all countries. Additionally, it would be great if a 'default' could be selected (similar to languages setup on the online store), so that the country/region picker can be defaulted correctly based on the channel.