The SaaS Back Office

Hiya guys! Patrick (patio11) here. You signed up for periodic emails from me about making and selling software. Sorry for this email being delayed -- illness and travel have thrown off my fall schedule quite a bit. [Edit: Alright, strictly speaking, you might not have ever gotten an email from me. Somebody might have just given you the link to this page, which is an online archive of an email that I sent to folks who had asked for it. If you'd like to get articles like this in your inbox, totally free, about once a week or two, give me your email address.]

All complicated systems, from computers to insect anatomies to human communities, have fractal levels of detail which most people never get the chance to appreciate. This is part of what drew me to software (and business, another fractally-complex Russian nesting doll of systems) in the first place. Recently, I've talked to some folks about particular details that are widely known in the software business but perhaps not obvious to everyone, so I thought I'd gather my thoughts on them publicly.

The "back office" is the unsexy part of Wall Street which does the boring mechanics of moving money from point A to point B. The sexy part of Wall Street that makes the big bonuses and gets immortalized by Gordon Gecko is the front office, whose chief concern is figuring out what/who A and B are. In the software industry, our product and marketing generally occupy most of the limelight, but there are actually many sides to the business that are equally crucial but perhaps not as celebrated. Call it the software back office. (Not to be confused with the software Back Office or another similarly named piece of software, both of interest to administrators of Windows systems, for rather different reasons.)

Here are some examples. Hopefully they'll be useful to a few of you in your own businesses.

Smart Software Companies Usually Have Permissive Refund Policies

Recently an article titled We Do Not Negotiate With Terrorists made the rounds. It explains why a particular software company chooses not to have refunds. This is probably a mistake (for one, any policy which causes you to refer to your customers as terrorists seems to have questionable optics), but folks don't seem to believe that refunds is always a win, and (apparently) some folks in the wider software community haven't heard about this issue yet. (Feel free to skip this part if you're a long-time Joel Spolsky reader since the conclusion is old news.)

I have a ridiculously permissive refund policy. I usually describe it as an unconditional 30 day money-back guarantee, but that's actually a white lie. My true policy is that I'll refund people for absolutely any reason at absolutely any time. I routinely remind customers of this. I grant refunds even to people who I am absolutely positive are abusing my trust.

Why? Because refunds make excellent business sense.

Customers take advantage of refunds rarely even with very generous refund policies. Bingo Card Creator's consolidated refund rate -- from all causes ranging from mere dissatisfaction to payment fraud to customer error leading to a chargeback -- is only about 2.7%. Appointment Reminder and my productized consulting business run at about 1% and 0.5%, respectively. (I attribute the difference partly to customer mix, partly to business model, and partly due to vagaries like what payment form a fraud ring decided to exploit to verify credit cards in summer 2013.)

Refunds cheaply terminate expensive, soul-sucking interactions with pathological customers. Pathological customers (about which more here) are the worst possible users for your service. If you've run a business at scale, you know the psychograph I am talking about. If not, imagine someone who is a poor fit for your product. They send in excessive support requests, half trivially answerable on the website and the other half feature requests for things your software will never, ever do. (e.g. Bingo Card Creator is not currently optimal for my shopping list management needs. Oh hoh, you think I am joking.) They are frequently abusive to you and/or your staff. They complain about the pricing and ask for special favors, but do not follow through. They push any policy/quota you have to the limits and beyond, and unilaterally invent obligations to themselves, such as you being required to support free trial customers with personal phone support at 3 AM on a Sunday. (Oh ho, you think I'm joking.)

If you and a customer aren't great fits for each other, just apologize, explain you aren't great fits, refund their money, and wash your hands if it. That is all you're obligated to do. This doesn't require antagonizing the customer, citing a policy which they'll be inclined to argue with, or having a long discussion. It just quickly stops you from getting into an argument with a customer, which is an argument that you will never win.

Refunds soothe the soul. I frequently have the ingrained engineers' distrust with taking money for my services. Still working on it. A permissive refund policy allows me to charge what my stuff is worth and sleep soundly, because I know that I can look at a mirror and say "Everyone who paid me money is happy. If they weren't happy, I would give them their money back." This is preferable to alternative methods of assuaging engineer guilt, like gratuitously underpricing your product.

Customers can get a refund with or without you consenting to it, by calling their bank and asking for a chargeback against an Internet merchant. The card networks (Visa/Mastercard/etc) live and die by one thing: transaction volume. Their policies are designed to encourage transaction volume. This includes stomping over every possible objection you could have to using a credit card for every possible purchase. One frequent objection is "What if this merchant screws me?" Their answer: "If that ever happens, you'll get your money back. We guarantee it." Another objection is "What if I type my credit card into this scary Internet thingamagig and then someone steals my number?" Their answer: "If that happens, you'll get your money back. We guarantee it."

One mechanism for enforcing these guarantees is the chargeback. Flip over any credit card you own and look for the 1-800 number. Calling that will, within a minute, allow you to talk to a human being who will take your side against virtually any business in the planet, under almost any circumstance. If you call and say "I ordered a hamburger at a restauraunt and when it came out it was made out of beef!" they'll tell you "That's terrible, sir! We will investigate this and get back to you. In the meanwhile, here's your money back. Thanks for your business, please continue feeding us transaction volume." The issuing bank will then open a dispute, called a chargeback, with the provider who originated the charge and, eventually, with the merchant.

A fact of life for Internet merchants: while you will be asked to provide evidence for disputes, you will very, very rarely win them. The entire model of chargebacks assume that customers are generally right, and Internet merchants in particular are seen as being exceptionally high risk for not delivering on claims or for being used for card-not-present fraud, so you should expect to lose as a matter of course. Even when you win, you still lose, because you'll spend an hour fighting every chargeback. You almost certainly have better uses for that hour (for example, instead of trying to rescue a sale to a customer who will be pissed, try to make a new sale to a customer who will be thrilled).

You will typically suffer a $15 to $25 fee for each chargeback lodged against you (generally even if you win the dispute), and will very rarely be given back the money that gets seized instantly when they're filed. Additionally, if you consistently have high chargeback rates, you can have your merchant account yanked. You profoundly don't want this, and thus you profoundly don't want chargebacks.

There's a few ways to avoid chargebacks:

  • Make contacting you the easy, obvious option to complain about a purchase, rather than calling the bank.
  • Put a phone number and dedicated landing page URL in the merchant description, which gets written in people's credit card statements. This is to resolve intrafirm communication issues. A bookkeeper might hypothetically look at a charge which said [PP* KALZ SOFTWR] and immediately chargeback six months of service for the law firm she works at. To use a totally hypothetical example. I switched to Stripe, which lets me include more descriptive messages, like [Appointment Reminder 1-800-555-5555], where the actual phone number connects people to a recorded message explaining what the charge was about and how to email me if they need to ask any questions. 37signals goes one further and embeds a URL, like so: [Basecamp http://37signals.com/charge], which will bring you to a pretty brilliantly done page that resolves many common issues before the dreaded chargeback.
  • Bounce transactions which are likely to be fraudulent before you send them to the credit card processor.

What transactions are likely to be fraudulent? Well, that's a deep topic.

Defanging Fraud And Abuse

If you do business on the Internet, it is inevitable that sooner or later you're going to come to the attention of some not-very-nice people who will attempt to do not-very-nice things to you.

Businesses span a spectrum from low-risk of fraud and/or abuse to high risk, chiefly based on how attractive it is in monetary terms to exploit your service. If you are in a low-risk business, you can literally go for years at a time without ever thinking about fraud, abuse, or the risks associated with them. If you are in a high-risk business, you will be attacked early and often, and your responses to those attacks will come to define the character of the business.

Most software companies are comparatively low-risk businesses, with exceptions. Why is that?

  • The typical B2B SaaS company takes payments from customers and keeps them for itself, but doesn't pay users directly. This means that compromising them doesn't allow you to use the software company as a vector for financial attacks, like credit card fraud, cashing (turning stolen credit cards into money), or money laundering. Your life would be a lot harder if you ran e.g. a Bitcoin exchange. (Don't run a Bitcoin exchange.)
  • Some fraudsters use stolen credit cards to steal products/services, either because they help enable the fraud business (hosting, VPNs, telephone numbers, yadda yadda). If you're e.g. a Twilio or Rackspace, the fact that your infrastructure would be useful to a fraudster makes you higher risk than if you sell e.g. internal developer tools.
  • B2B companies rarely deal with friendly fraud, which is endemic in B2C companies. What is friendly fraud? It's when your customers love your stuff so much they'll steal from you to get it. This is quite common at B2C companies selling games, digital goods, and the like. For example, if Little Timmy buys $100 of virtual currency to spend on his game of choice, and then Little Timmy's father calls up the credit card company to dispute the charge as unauthorized, the credit card company will probably not say "Sir, you sound like you're 16." They'll just stick the merchant with the chargeback.
  • Companies which don't ship anything (like many software companies) often have very lax requirements for validating credit cards. Credit card numbers which have been recently validated as working are worth more than ones that are not, so this is a key requirement for carders, the criminal specimen that attempts to turn stolen credit cards into money. Validation is as simple as running a card for your software and then observing if you reject it or not. BCC was the target of a fraud ring which did this 65+ times. Even charities like watsi.org get abused in this fashion.

So what can we do about it?

First off: I generally wouldn't invest a huge amount in fraud prevention until after you're having recurring fraud problems at above the level of noise, unless you're in a business which is intrinsically high risk. If you lose $500 to fraud every year, writing code to reduce that to $200 is probably a poor use of your time.

If you do develop a non-trivial fraud problem, you should look into revising some tradeoffs which you've made between ease of use and security.

For example:

  • The idealist in me loves the idea of the Internet connecting all people everywhere equally. The businessman in me is capable of reading numbers. Here's what the numbers says: if geolocation on someone's IP suggests that they're physically in Country X but their card was issued in Country Y, to a first approximation, that transaction is fraudulent. I hate this, because I live in Japan and use American credit cards, and have been caught 22 times by filters due to that. But the stats don't lie, and (frankly) people like me are rarer than fraudsters and have lower transaction volumes (becaues I have to, you know, actually pay for things I buy, whereas a single frauster can run 100 cards in a day... and will, given the opportunity).
  • Your threat model, in a low-risk business, can generally assume a single adversary who is technically proficient but not backstopped by teams of PhDs with millions of dollars of funding. You probably just read geolocation and thought "I could defeat that with a VPN!" A very sophisticated adversary could, but most won't, so that stops 90% of your problems immediately. My typical adversary assumes clearing cookies is l33t skillz, yo.
  • Have system-wide velocity checks for important things, like e.g. monetary transactions. Wake somebody up if they go crazily out of bounds. Be prepared to throw people into a manual verification queue if their transaction is high-risk or if you're under attack. A lot of the financial risk to you isn't losing a transaction here and a transaction there, it's losing 700 transactions in one day to a shell script. *

If you run a marketplace site, sell to a market of intrinsically pathological customers ("a virtual currency for people who want to buy file sharing!"), or are similarly in a very high-risk business, God be with you. It is highly likely that you'll have to have dedicated fraud experts at your company working on this problem more-or-less constantly.

What's abuse and how is it different than fraud? Abuse is causing your product to do things which are damaging to your business, users, or the public at large, ranging from facilitating crimes to just giving people opportunity for mischief.

Many software companies have abuse risks, even where they don't have obvious fraud risks. An example: Appointment Reminder doesn't appear to have huge issues with fraud, since if a legitimate business wanted to get the service for free when I discovered it I would shut them out and that would be the end of it. It does, unfortunately, have issues with abuse. Let me hum a few bars: supposing you were estranged from someone you had once been married to and wanted to leave them harassing messages but didn't want to get arrested again, you could arrange for an innocent software company to send those messages on your behalf.

There are as many forms of abuse as there are ways to use software. Happily, many of the techniques for combating them are similar to ways for managing fraud, since they often appear in concert.

Until next time.

Regards,

Patrick McKenzie