To touch on your comment about how personal it is to sell into enterprise accounts. In enterprise I've found that most of the time when prospecting the equation for selling is 95% TRUST & 5% VALUE. Enterprise customers have a lot to lose if your offering goes south on them, so they need to trust their vendors.

That said it takes time to build trust. You can establish it over time by building authority and offering social proof in any industry.

Going direct to customers is a good way to start revenue but it's tough to scale. HP sells 80% of its revenue through partners. Instead of going direct to customers you should build a channel sales program and build up partner relationships.

Partners you work with should have clients already, clients you want. Clients that trust these partners because they do a good job.

That's how you get into enterprise quickly and scale.

I have built and sold five companies in the last 7 years. I was CIO at a $50M/year sales organization, now I am starting to take startups through a probono training on how to do sales for enterprise if anyone is interested in joining our sessions. No cost to anyone for as long as I enjoy hosting it. It's over google hangouts. Email me hn (at) strapr (dot) com to get on the list.

"It's not what you know. It's not who you know. It's who trusts you to solve problems." Is the advice I've been giving to people.

Thanks for doing this. Dropped an email.

Email sent. :)

I like this comment. A lot of initial sales are just pure relationship: you know someone who knows someone or randomly someone saw or met you at Meetup, website, forum... Maintaining the first deal is hard though because it's a tricky road: Do you have to do what they ask or do you think the market is bigger than just this one specific use case? Eventually the first 10 Enterprise customers are the ones who pay the bill.

> They made me fill in a disaster recovery questionnaire ... They wanted the source code for this website in Escrow ...

Can you elaborate on the details or circumstances these parts outlined? Particularly in regard to provisions or protocols to be followed in the event you become unable to render product service (due to disaster against the product or its infrastructure, personal circumstances, or otherwise).

I'm in a similar position that you've described. I'm mostly a one-man shop with a SAAS product that has a Fortune 100 customer. As it becomes increasingly integrated within their company they've voiced concern over what happens if I become unable to render service. We likely have contract amendments coming for code escrow, but I've no experience in this particular area, so thought I'd ask what you learned from these parts of your contract.

If it matters, the product is tightly customized to the customer's work flow, and provides a solution they've been unable to readily find elsewhere. So in the event that service can no longer be rendered, having them subscribe to another product wouldn't be immediately viable.

Where I've worked has been an <10 man shop with 2 critical personnel who wrote software that was responsible for the healthcare of hundreds of thousands of individuals, actually probably in the low millions.

We were required to have code escrow contingencies, and one company required those two key personnel not to travel on the same flights.

> not to travel on the same flight.

Did they also asked them not to travel in the same car? Chances of dying in a car accident are considerably higher than a plane, unless I am missing the reasoning behind it

It sort of spins out of bigger companies who tend to have a policy of "no more than 4 CO's in the same plane". It stems from when COs would all pile in to the same chartered plane because it was cheaper to do that and be flexible with time than to have them all drop what they're doing to sit on a commercial flight.

My company has the same policy for high enough management, but these days they all just travel solo on commercial flights anyway. It seems like it was different 20 years ago.

edit: I think they also maintain a car policy too, but I can't recall for certain.

Part of this is about making sure people are available at last minute notification. If you're in transit from Sydney, Australia to London, UK, you're out of action for 30+ hours plus the time to get over jet lag.

I am not buying that, People sleep and do morning routine for 10+ hours and on top of that they have personal life and weekends, you won't ask them to stop doing that so they will be available for you at last minute notification.

Whoever is oncall rotation for that week does.

Guess you're not familiar with the old term "pager duty".

That's typically handled by code escrow, and an legal agreement around you being unresponsive after X days of attempted contact via methods X, Y, and Z, etc... It's a separate thing from DR (which is normally infrastructure focused).

Understood on the difference between being personally unresponsive vs. an infrastructure disaster. I should've been more clear; I've edited my original reply.

Code escrow is in fact what we're looking at. I guess part of my question intended to hear more about how outlining and negotiating that process went. E.g. I'm curious what objections or sticking points may have been encountered, from either side, when approaching the agreement to make a copy of the product accessible to the customer (in certain circumstances).

Hopefully it's straight forward and non-interesting, in which case I'd have no further questions.

I've been on the other side of that scenario.

In our case, we bought a license for the software + source code and hosted it in our data center. We paid for maintenance and a support agreement that included a fixed number of hours for break/fix and new features.

Worked pretty well.

Support SLA is pretty common in enterprise, but what do you mean with "new features"? Did you put SLA also on features development?

With that arrangement, so we basically bought a bucket of use it or lose it hours that could be used for anything. That included enhancements to the software.

It sounds wasteful, but because it was a two-man the cost was low relative to value.

Our escrow agreement is just a two-paragraph addendum to our main agreement that refers to our escrow provider's standard agreement. You sign a three-way agreement with each client and the escrow provider.

We use NCC Group as our escrow provider. There are cheaper options but NCC has good name recognition which helps customers feel more comfortable.

As for what to charge, we just marked up their price a bit and called that our "source code escrow add-on".

Do you still work a day job, or maintain this full-time for them?

I moved on to found another startup.

if you ever want to grow the service, i'd love to chat about either white-labelling it or selling it directly to other real estate brokerages. i have a few connections at a top national firms as well as regional players. my email address is my HN handle [at] gmail if you ever are interested in chatting.