Hacking the suggested items feature in GP to create a flexible sales scripting system

In telesales, and ecommerce we have three common directions to take a sale:

• Cross selling
• Down selling
• Up selling

The Suggest Sales Item window by default design is intended to suggest other items that could be added to the sales order, on the basis of a trigger item being added to that sales order. A good example of this is when ordering a torch (flashlight), you would normally expect to be able to make a sale of some batteries compatible with it (cross sell). A window in GP would pop open on entering the torch as a sales item, thus prompting the user to to add a quantity of batteries. If the customer and user choses to accept the batteries, then those items are added to the order.

What about down sells? Say you don’t have enough stock to fulfil the customer’s requirement so want to offer a lesser alternative or perhaps the customer baulks at the price and you need a cheaper option? Item maintenance provides two substitute items that can be entered against the item, so the user can check these should that circumstance arise.

If you wish to increase margin on a subset of product by encouraging sales of a slightly higher margin product, or perhaps have excess stock of an alternative product, this is selling up. Prompting the sales staff to move this stock in favour of the entered stock can be helpful. However it may be more of a fuzzy link that is required, not so one to one in nature. On buying the torch we want to get the sales staff to promote hi-vis jackets and personal protection equipment, but the range is large and direct links to items is inappropriate, the need is to simply prompt the sales person to start a conversation. How do we achieve this?

It is helpful that the suggested items window also has a sales script associated with the product suggestion link. This is a free text field where any message can be written for the user to read, using this in combination with a “fake/dummy item” we can do all kinds of fun stuff! It is a good idea to reserve a range of item codes for this purpose.

Example

Lets create “00-095” as an item with description of “Sales prompt”. Create it as a flat fee or similar non-inventory item and create a prices of zero for it.

Now for the trigger items we want to prompt against, go to the Suggest Items button on item maintenance window in GP. Add the item we just created (sales prompt) and type the script that holds the communications of what the user should be doing/saying. This can be up to two hundred and fifty characters. Then set the suggested quantity to zero as this is irrelevant in how the window is being used here.

Entering the test item now prompts the user, note the script, contains what we want the user to do. Users can be trained to always read the “Sales Prompt” item’s script and act on it.

This technique provides for a useful way to prompt sales users during order entry. A number of prompt items could be generated with different names, like “Hazard prompt” or “Shipping Note” or “Limited availability”, to prompt of items that may need special handling, items that have shipping restrictions on them or perhaps just a notice of the fact the item coming to end of life. The scripts are stored individually against the trigger item so each item can have a different variation of a script, should that be required, leading to lots of flexibility in how this can be applied.

SQL

Now we have prompts, but with over 30,000 products these prompts need automating or someone is going to be full time maintaining them!

Tables IV00400 and IV00401 manage the sales prompts.

IV00400controls the “check boxes”, as to what documents should trigger the prompt.

IV00401 is the more interesting table, this is the table into which to squirt the scripts and product relationships.

The following example replicates what was just shown using the user interface only this time using SQL to create the relationships:

-- Generate the next SEQNUMBR 
-- for this prompt type to keep them at the bottom of the item list
    ;

WITH CTE_LineNumber
AS (
    SELECT ITEMNMBR
        ,MAX(SEQNUMBR) + 16384 AS NEXTSEQ
    FROM IV00401
    GROUP BY ITEMNMBR
    )
INSERT INTO IV00401 
SELECT IV00101.ITEMNMBR
    ,ISNULL(CTE_LineNumber.NEXTSEQ, 16384)
    ,'00-095'
    ,CONCAT (
        'Sales Prompt '
        ,CONVERT(VARCHAR(10), getdate(), 20)
        )
    ,0
  ,'Promote the Westway high-vis jackets or other PPE items for April sales push'
FROM IV00101
LEFT JOIN CTE_LineNumber ON IV00101.ITEMNMBR = CTE_LineNumber.ITEMNMBR
WHERE ITEMDESC LIKE '%flashlight%'
    OR ITEMDESC LIKE '%torch%'

Obviously this is just a sample, complete SQL clears down old scripts and merges into the tables for updates. It is also worth noting here that the actual product description can be hacked to whatever you wish here too. So “Sales Prompt” has had the current date appended to it, alternatively this could be used to eek out more text for the messages. Be aware though that if a user does add the fake item to the order, this text may leak out to the customer as the item added will use the description from the suggestions table.

It is worth pointing out a bug or feature of suggested items is that the product description is not maintained in the suggestion table, hence if the description is changed on the item card, from my experience this is not updated in the suggestion table. Should the suggested item be added to the order, an out-dated description will be used on the sales order. This limitation can be addressed by syncing the two description manually or using SQL job whenever a description is updated. Perhaps this may be fixed in future releases, in that case hacking the suggestion description as described above may not be good practice.

It is easy to see how a SQL job could generate scripts overnight for products during certain date ranges for promotional activity or for items meeting certain criteria, such as stock levels and life time or shelf life, weight etc. This could be harnessed to drive sales more intelligently.

Careful use of the part numbers used for the fake, dummy item scripts allows for easier management when there are large quantities of scripts in use.