5

We have a SaaS business (we host everything) where people, using our software, pay for various services offered by a few "vendors." We collect this money and every week we deposit the balance into the vendor's account. Our cut is a small piece from each of these service payments; so if nobody buys anything the vendor doesn't pay anything.

This model has worked fine, but we're now in talks with a larger vendor (government) that was asking for escrow for our service. They asked the trigger (for the release of the code) to be bankruptcy, not providing the service at a reasonable level (can't remember the actual term used), or acquisition by a third party.

We told them that we don't have a problem with the bankruptcy trigger, but the acquisition part we can not agree with because who would want to buy us if our customers have the option of just running our software for free. Are we rightfully concerned about this scenario?

After we mentioned that a trigger cannot be acquisition by a separate company or if they think our software doesn't live up to some standard, they countered that in this case they would want some kind of SLA with "really high requirements" instead of the acquisition or service trigger -- but still have the escrow for bankruptcy.

Doesn't SLA imply some kind of monthly or yearly service fee? We structured our model so that if a company does use our software they don't pay anything. We thought this would be preferred over a monthly/yearly fixed cost.

Are we being unreasonable? Thoughts?

apaderno
  • 4,014
  • 8
  • 42
  • 53
pbz
  • 168
  • 5
  • 4
    Be very careful when dealing with governments. – Bernard May 02 '12 at 20:13
  • @Bernard: Why do you say that? – pbz May 02 '12 at 20:22
  • They can make it very difficult for your business to operate. – Bernard May 02 '12 at 20:32
  • It looks like you have what I like to call a "good problem" – Michael Brown May 02 '12 at 20:34
  • @pbz - Bernard's comments have a ring of truth to them, and I've certainly seen some onerous conditions myself. However, that's almost always spelled out within an SLA or RFP, so you should have disclosure on their expectations prior to completing the contract. –  May 02 '12 at 21:32
  • 1
    They're probably concerned with acquisition meaning that your company will disappear or stop offering the service or be absorbed into a larger entity that's rapacious or incompetent. Even if you don't foresee that happening, it's understandable why they'd worry about it. Keeping that in mind, perhaps you (and your lawyers) can frame a different trigger that addresses their concerns while still allowing you to sell your company in a way that won't interrupt their service. – octern May 03 '12 at 00:30
  • @pbz - Is this potential project big enough to justify creating a new company with perpetual rights to use the software? Also, there's nothing stopping you having a pricing model that charges a fixed price for SLA service and a per-use charge without an SLA. After all, in order to guarantee service, you need to know what the maximum demands on your service will be. – Mark Booth May 03 '12 at 12:52
  • 1
    How is this "off topic" when when one of the points in the FAQ is "business concerns"? – pbz May 04 '12 at 22:27

4 Answers4

11

Full disclosure - I've been on the demanding side of an escrow request, so please pardon me for any overt bias.

Large organizations such as gov't and utilities generally don't change software applications frequently. It's not unheard of for an application to live 10 - 15 years, with only a few version upgrades in there. They can take "sweating the assets" to an art form... New applications represent a large investment of resource in order to bring in and put to use. Switching applications means throwing away that previous investment.

One of the big risks involved for them when evaluating new software is estimating the likelihood the vendor will be in business next, three, five, ten, and so on years from now. The escrow requirement allows them a fallback option should their beloved application no longer be available in its preferred form.

Acquisitions can mean the death of a product as they bought it. Your future client's perspective may be that they equate acquisition with death. If they've been burned once before, then that's likely how they see it. OTOH, I honestly don't see this as a big poison pill for an acquiring company. Their rights to the software will be limited to just that client. They can't turn around and provide the same service to others with the code they received via escrow.

The SLA clause is a little new from my point of view, but I think that's due to the SaaS model you're offering.

Once you apply a "fear-of-loss" viewpoint, you can see why they asked for the escrow. And it also gives you the key to finding an agreeable solution. On the flipside, it means they want to use your software and will likely be customers for a long time. Big orgs don't buy software just for giggles.

Having a steady stream of low-escape-risk clients can be very attractive to an acquiring firm, especially if they intend to continue or improve the service. Even if the client has a copy of the old code, they'll continue with the new version if it meets their needs.

Initial demands and reactions are always unreasonable. :-) I think you can find a healthy solution.

  • Right now they do all that by hand on paper. With previous customers we just signed a contract and that was it; there was no investment other than the time they spent talking with us. I take your point on them being steady; that's one of the big positives. My #1 concern was how the escrow situation would look in case of an acquisition. Thanks! – pbz May 02 '12 at 20:37
  • 1
    +1 but I would strongly disagree with the comment "acquisitions generally mean the death of a product"-- if someone acquires a SaaS company, the vast majority of time, they do so precisely to acquire the product and extend it. Perhaps they would extend it by integrating it into other SaaS offerings the parent company already has but it would be pretty rare to acquire a software company and throw away the software. – Justin Cave May 02 '12 at 20:37
  • @Justin Cave - I agree with your point and I've updated my reply to reflect that. Some of my background is in monolithic apps where acquisition is sometimes just a means to remove the competitor from the marketplace. –  May 02 '12 at 21:09
  • @pbz - I know of several (non-SaaS) companies that were acquired that played in that gov't / near-gov't sphere. Escrow rights have not appeared to have any impact upon the acquisitions. I think the benefit of having a large, low-escape-velocity client in place greatly outweighs the escrow issues from the acquirer's point of view. –  May 02 '12 at 21:16
  • 3
    @JustinCave There are all sorts of reasons to acquire a company, especially a small one. All the reasons boil down to: the acquiring company wants *something*, but that something isn't always the target's product. It can be a quick way to hire a dozen smart engineers, or to acquire a patent portfolio, or to quickly enter a new market with a name already established in that market. – Caleb May 02 '12 at 21:20
  • 1
    +1 and more. Reiterating a point that is not all that clear- the cost of software to a large organization is orders of magnitude more than what you will charge them. They need to develop process around how to use it, train people, manage risks caused by your business model, integrate it into there systems (computer and non computer)....... It's not the same as buying the latest game for your iPhone for a buck. All they are doing is protecting there investment. – mattnz May 03 '12 at 01:57
4

My advice to you...get a lawyer. You're playing with the big boys now, asking a group of strangers on a Q&A site something this important to your company is not the right way to do it.

Michael Brown
  • 21,684
  • 3
  • 46
  • 83
  • 2
    Always sound advice when it comes to significant, contractual issues. However, an IP attorney may not have the perspective to know what goes on in the field. OTOH, some parts of the target audience of this site track mergers and acquisitions, especially since they may be our future employers. –  May 02 '12 at 21:18
2

A Service Level Agreement (SLA) doesn't imply a monthly or yearly service fee. A SLA lays out an agreement about things like uptime, performance, data availability, downtime notifications, support response times, and other things of that nature. A SLA with "really high requirements" might specify that the service is to be available 99.999% of the time and specify response times for various operations. If the vendor has to make a bunch of web service calls, for example, they may want to ensure that, say, 99% of the calls return in < 0.5 seconds. And the SLA generally specifies penalties for the service provider if these targets are not met-- generally, that would involve reducing or eliminating the fees the service consumer pays to the service provider but you could structure the SLA to involve the release of the escrowed code if the provider is consistently unable to meet the targets.

Of course, you'd want to make sure that the targets were sufficiently conservative that there would be no real risk that you'd violate them so long as the service was being actively looked after (either by you or by whoever bought the company). But it would allow the escrowed code to be released if your company didn't go bankrupt but simply stopped providing active support and monitoring and let the service go down on a regular basis.

Justin Cave
  • 12,691
  • 3
  • 44
  • 53
  • There are no web service calls (API), not in the current version anyway. What would be a reasonable penalty (a guess is fine)? If it goes below 98% free week? Below 95% free month? I'm just trying to wrap my head about it. Thanks. – pbz May 02 '12 at 20:30
  • 2
    @pbz - Reasonable tends to be very dependent on the type of service. If you were providing email as a service, it would probably be reasonable to say that you'll have 99% availability each month, fees will be cut in half if availability was actually between 95% and 99%, the month would be free if availability was between 90 and 95%, and you get 2 free months if availability was less than 90%. Depending on the service, you might increase the availability but decrease the window (i.e. 99.9% between 9am and 5pm) as well. – Justin Cave May 02 '12 at 20:34
2

First, SLA is the term for providing a service at a defined level, it can include both penalties and rewards, termination of agreements and commitment to higher level of usage. Basically anything you can think to put in a contract, with terms dependent upon service levels (uptime, number of visitors, response time, failure rates,etc).

Secondly, non-corrupt goverments are not interested in stealing your code, they are interested in preserving their investment. Assuming a non-corrupt goverment, they are simply doing risk abatement. Larger organizations of any sort worry more about the cost of downtime and changes than do small companies, because they are more expensive for a large organization -- just as a simple example considering using your service is probably costing several thousand dollars at the absolute minimum, it could easily be tens of thousands; meetings, technical evaluations, memo's, etc...

Basically a large organization will be interested in two things: what happens if your service changes in a way that makes it unusable, and what if your service simply becomes unavailable. To make your service attactive to them, focus on solutions to these problems, not the fact that if you go out of business they don't have to pay you any more -- not paying you is exactly what THEY are worried about.

So, an escrow account (or even automatic release of the current or prior version) with a clear contract specifying that you retain ownership under all conditions, and a non-compete clause that says they can't offer the service to anyone else under any circumstances and can only do so for their own customers/users in the event of you not meeting the specified level of service.

You can actually use this as a selling point, possibly including using their computers as fall over servers (current/prior code releases can mean that their programmers/techs are always ready to do a switch over, fall over servers could mean zero downtime in the event that you pull the plug). Don't forget to include penalties if they DO release your code due to error or dishonest employee.

Honestly, this sounds like a great opportunity.

jmoreno
  • 10,640
  • 1
  • 31
  • 48
  • "clear contract specifying that you retain ownership under all conditions" is a clever demand – ZJR May 02 '12 at 23:40
  • @ZJR: I meant of course that the contract should be clear that it grants no ownership rights to the other party. – jmoreno May 03 '12 at 07:22