So you'll see I put e-commerce up there; there are a million different ways to calculate and create commissions depending on the business. Here I'm going to show you a model I used at a client who conveniently was half way there.
In this business the retailer sends emails containing a selection of products to high spending individuals. Each of these emails is hand crafted by a 'salesperson'.
Luckily for me the products going out in these emails were creating records against the customer's account record in salesforce via a 3rd party email tool the business was already using (aka hardest bit already done!).
Ok so what use is that? 🤔
So now we know specific product activity by that salesperson. Which means we can wait and see what purchases the customer makes and try and be clever about all this.
As you can also probably tell I already have access to purchases that customers are making in the same system. But even if you don't and that data lives somewhere else you can either shift that into your org;
Or query the other system on a nightly basis using a tool like Talend Open Studio* and run your smart query in Talend;
Or go half way between the two and use Talend to stage data in Salesforce on a nightly basis where you can run your querys against it. Create what you need, and then bin it all afterwards or move it to 'big object' transactional records in Salesforce.
please note the insane learning curve and immense frustration that this product will return - however do awe at the amazement it will generate when you finally get it/pay someone else - to get it working correctly!
So first the outline -
We are going to, when ever a purchase enters the system, get all the information about it and then go look against that customer and see if they were recommended it in the last x days.
For extra fun I'm going to see if there were any similar products the customer was emailed within the same time frame if we don't find an identical match first then we will create a 'partial' match and award a lesser commission for this activity and sale.
I'm doing ALL of this in config. and so our starting point this time is a process builder to fire on create of the incoming sale record.
First the decision criteria;
And now, what we are going to do with information from these purchases?
First we will mark this sale as 'assessed' so we don't pick it up again in the future, and so we know that the process was triggered. Then we pass our variables into the flow;
Crikey! 🤐
In short it takes the purchased record and its information - grabs all recommended items in the eligible date range - and loops through them one by one. I then (in this version) create everything eligible. So I will for example create x2 exact matching commissions or x1 exact and x1 partial or what ever is found, if that recommendation hasn't been used to create a commission record elsewhere already.
I realised that might not really be desirable from a business perspective so I then bolted on another monstrosity to see what had been created and loop through everything there and prioritise exact matches over everything else, and as soon as it found an exact match - to delete everything else.
Alternatively if no exact matches were found but multiple partial matches were - then to keep only a single partial match and to delete the others.
In hindsight you would do this before you actually created anything but; "agile".
In essence, this process creates only ever a single commission record per purchase where there is an eligible recommendation to match it against. And then only creates the 'highest value' flavour of commission record when it does. (🏅= 💷) While it is creating and then tidying up it's doing so in the same process so you never 'see' the 'deleted' records.
You might find this process quite heavy as it currently is and so this could affect the batch size that you could ETL your purchase data into the system. Assessing the records prior to creating them for a 'create preference' would make the process lighter.
Package Link - coming soon (improved version to follow)