Results 1 to 1 of 1
October 26th, 2004, 02:59 PM #1
- Join Date
- January 17th, 2005
I put this in a different thread. Handling spikes in sales is different from handling deadbeats.
I like the SAS temporarily off line and autopay features. However, I believe that SAS should have a different financial mechanism for handling spikes.
Spikes can occur because of seasonal fluctuations, fraud or publicity spikes (for example a product gets mentioned in the news, a site gets slashdotted, etc..). Who knows, an affiliate might cause a spike. Giving a merchant the coveted top position on ecomcity might cause a spike.
A spike is different from just being a dead beat. The dynamics of spikes generally mean that a web site is due for an unexpectedly large influx of cash. In the case of mass fraud, the spike is usually followed by an unusually large number of reversals.
It is absurd to expect a merchant to be able to cover spikes with a standard line of credit. Such lines of credits generally have fixed limits. Even worse, there is a good chance that commission spikes will occur at times when a merchant is employing its line of credit on other matters...such as the thing they are selling.
Imagine, for a moment, that a liquidator buys up a large quantity of goods in a bankruptcy sale. They then want to liquidate this merchandise on the internet. Well, it is likely that the merchant has exhausted their line of credit for the purchase, meaning they may have difficulties covering a spike in SAS commissions if they have a special through SAS. Should we deny SAS affiliates the ability to cash in on a spike because a merchant has a fixed line of credit?
(NOTE if the SAS merchant itself is going out of business and they are liquidating stock, then the spike is risky. Spikes are not risk free.)
Spikes are different from just being a dead beat. As such, they require a different financial tool than dead beat accounts. The financial tool for spikes might be like reinsurance popular in the insurance industry.
The first step is defining a spike. SAS would have to define the risk and rewards of the spike, and which merchants are susceptible to spikes. For example, SAS might define a spike as a jump in commissions that is either $2000 more than the average weekly sales or four times greater than average weekly commissions (whichever is greater). SAS might also have to define the class of spikes. Seasonal merchants are more likely to have spikes than apparel merchants.
The next question is who should bear the risk of spikes? Quite frankly, as an affiliate I would prefer to ride out the spikes than being cut off at the heals...even if that means greater risk to myself. I have no intention of promoting a merchant that can't pay their average weakly commissions.
SAS could externalize the risk of spikes to affiliates simply by adding a spike status to the merchant status field. If a spike (as opposed to poverty) exhausts a merchant's account, they would move into a spike status state rather than the off line state when a spike exhausts available funds. SAS would then demand accelerated payments. SAS does not need to include Spike protection for all merchants. It might require additional payment or involve an underwriter to handle the risks of spike management.
Addition of a spike status would be the simplest solution to implement.
Spikes are unpredictible. They can be wonderful windfalls. I hate seeing SAS automatically denying affiliates the windfalls of spikes.
Autopay is not a sufficient tool for handling true spikes because spikes are unpredictible...even with autopay, there needs to be an upper cap to the amount of commissions a merchant might face.
Creating a program with an upper cap on autopay might encourage more merchants to join autopay. Quite frankly, if I were a merchant I would not join a program without an upper limit.