How do you guarantee Business Continuity for enterprise customers?

Discussions
#1

Hi Guys! Long time since my last post here …

I had a demo call yesterday with a prospective customer for my new application Docparser. The customer really likes the product and wants to integrate it into their system. They already upgraded to a paid subscription in order to better evaluate the product.

Now here is the catch … the customer is a rather big company and they would want to rely a big part of their business on Docparser. Understandable, they are concerned about me going out of business or changing my business model one day.

So the question which came up during the call was: “What happens if you go out of business? How can we secure continuity of operations in this case?”

The customer basically told me I should come up a proposition. I think they would not mind paying extra for a some kind of Technology Escrow service. I’m however not sure if I want to deal with all the overhead associated to such an operation.

Did you guys go through a similar situation already? Are there any best-practises I can follow?

1 Like
#2

An excellent question.

There were some good responses to a similar question earlier:

Some escrow options were discussed here:

2 Likes
#3

Thanks @SteveMcLeod for the two links! I searched the forum but apparently I used the wrong terms.

The first link is very helpful and the answer of @patio11 sums it up pretty well. I think for now, I’ll just tell the customer that the contract volume is just too low to justify setting up the legal framework. That being said, creating a continuity plan for the business is definitely something I will be doing soon.

1 Like
#4

This is the wording I’ve recently proposed in a similar situation:

Mitigation against SUPPLIER being unable to fulfil this order

If, during the term of this order, SUPPLIER ceases trading or for any other reason is unable to fulfil the terms of this order, CUSTOMER will have the right to:

  1. Take ownership of the Heroku environments for https://customer.example.com for use only by CUSTOMER and its subsidiaries.
  2. Receive non-exclusive, non-transferable licence to the PRODUCT source code for use only by CUSTOMER and it’s subsidiaries, together with access to the source code.

To exercise these rights, a representative of CUSTOMER will contact SUPPLIER and request that access. CUSTOMER will need to provide a Heroku account to take ownership of the environments. SUPPLIER will transfer ownership to the provided account and provide the PRODUCT source code as an archive file. The non-exclusive, non-transferable licence will granted in the act of sending the source code in compliance with this agreement.

Under this agreement, SUPPLIER will ensure that at least two members of the SUPPLIER team are able to give effect to this agreement. These contacts are A and B. Their contact details are provided below. SUPPLIER will advice of any change to these contact details as soon as reasonably possible.

It’s currently getting reviewed by their legal team.

I went this route because I can’t see how escrow would practically work for either of us. Of course, this turns on the customer paying enough for a dedicated environment in the first place.

2 Likes
#5

For picky corporate customers we are giving a read-only access to the repos in Bitbucket, as well as instruction how to build and install software. In the software there is an option to backup your own data and import it into any environment.

1 Like
#7

This is probably the approach with the lowest headache, unless it can be profitable to steal your code.

#8

Thanks guys for all the good advice and insights! It seems like the customer will continue using Docparser even without fully guaranteed business continuity (contract + escrow) in place. I think it really helped discussing the topic on the phone and assuring them that we are not planning to shut down operations anytime soon.

2 Likes
#9

Thanks for this discussion!

I’m launching a commercial counter-part for an OSS Rubygem (https://www.kiba-etl.org) and made my first sale. The first client main concern is continuity in case of troubles at the company. I will add them as GitHub collaborator for now (since this is a cheap way to implement a solution in that case).

Does anyone has more legal wording to share + concrete solutions that would be cheap to implement, for someone selling software components?

Also I made some research, and most of the software escrow full-fledged services are quite out of touch for a bootstrapper starting something at a mid-pricing point (Kiba Pro is currently sold 950€/year):

(still sharing it in case it could help someone).

1 Like
#10

Congrats!

Does anyone has more legal wording to share + concrete solutions that would be cheap to implement, for someone selling software components?

Legal wording, no.

Concrete solution, yes. What I’ve been doing now for years is this:

  • My client and I agreed to use my accountant as a trustworthy third party.
  • I created a git account with access to the relevant repo and gave the credentials to my accountant
  • I’ve instructed my accountant to pass the credentials to my client in the event of my incapacitation.
  • Each month my accountant’s assistant signs into to git, making sure the credentials are still valid.
  • She then emails both me and the client to confirm that the sign in was successful.

Here’s the content of the email I (and my client) receive each month:

Today I successfully signed into the Acme Solutions/Foobar Inc escrow account on github.

#11

Another strategy is to include the full cost of the escrow service in your fees to them. You could offer to spread cost over other folks who request it in years 2, 3, …

Essentially say yes but since you are the only one asking for it you will need to pay for it. Make sure that you are the one to pay the escrow service firm not them so that in event of a disagreement over whether the escrow release has been triggered the escrow service views you as the customer.