Ask HN: What to charge for support SLA for one-person SaaS | Hacker News Reader

Ask HN: What to charge for support SLA for one-person SaaS

17 pointsorkj18 comments

Hi HN.

I have a SaaS that has quite a few small and big customers. I am now in the process of negotiating terms with another potential big customer. And they want an SLA for support. Their suggestion on emergency incidents is 30 minutes response 24/7.

The nature of the service tells me it's not going to be any emergency incidents, but I don't like to put it there in writing. I am one person, and I love to sleep.

It's also not suggested this would cost them extra, but I will for sure charge for the SLA separately.

So 2 questions: - What would you state as emergency response time? - What would you charge?

Thanks for any and all answers!

View on HN

You have a bus factor of one.

The potential customer is not in your market segment.

In part because you cannot deliver what the potential customer wants. In part because you don't want to change your business in order to deliver it.

So your choice is basically, forego the sale or sell something you can't deliver. Because your product does not meet their requirements.

There are two options. Be honest with the potential customer about your limitations. Or sell them reliability that you cannot reliably deliver.

Ok there is a third option.

There are 168 hours in a week. That's 4.2 FTE's. A Silicon Valley engineer salary of $120k is $10k/month/engineer. 50% overhead makes that $15k/month/engineer. 33% profit makes that $20k/month/engineer.

Doing it right is $88k per month. Or just north of a million dollars a year. If you cover some of the on call, then you can offer a discount down to $1,000,000/year for a year prepaid. Good luck.

Absolutely this!

I think the question also needs to be is this so mission critical that they need 30 minute response time?

If not a 4 or 8 or 24 hour response time during the week is a much more realistic way for you to cover them or leverage this to bring on the second person.

30 mins SLA for 1 customer means you are almost working for them exclusively if you are 1 man team. So they better be paying six figures or it is a no deal. Are they paying six figures ? Unless you have a support team, don't do SLAs especially that short of a window.

If you really want this business but don't want to hire a support team member, negotiate a different SLA which is not 30 mins. More like 24 hours. But then I don't know how mission critical this app is for the customer.

Thanks. They are not paying six figures, no :D

If they are not paying six figures, they can’t or won’t afford a 30 min response time and are probably trying to see how far they can push you.

Thanks everyone for validation. I just told them that there are 2 options:

1. Change the response times by a lot and find a price for that.

2. Not continue the conversation since the product does not meet their requirements

I am confident this is the right decision

Seems very reasonable IMHO!

As others have alluded to, you want enough to cover the costs of completely outsourcing the on-call and any additional overheads at a minimum.

Support for big customers can often mean dealing with outsourced/contracted employees on the other end who would rather ask for you to 'fix' things than make an effort themselves.

Also, ask yourself one question - Did you build this SaaS to empower yourself, or to be at the beck and call of someone else ?

Response time !== resolution time.

Response time can mean an automated email that a ticket was created and that someone is looking into it.

Now because you are a 1 person company this could be a problem.

Also you need to split incident by categories as an example:

P1 > 1h P2 > 24h P3 > 48h

Your customer may not be aware that their issue may be well classed as P2 or P3 (you mentioned the nature of the service doesn't require this).

Service providers you depend on will fail, either in catastrophic ways or weird almost-working/most-of-time ways, so emergency incidents are going to happen. It is just a matter of time and scale.

Another thing to consider is that your customer might incorrectly point fingers at you when in reality the problem is at their end. This might be due to incompetence or internal politics. And sometimes the blame is more fuzzy when they increase load on your service many-fold one day and latency spikes, which has knock-on effects on their end.

Whatever the cause you might need to spend a lot of time to carefully debug and educate people at your customer to keep that organisation happy with your SaaS.

A response time of 30 min 24/7 is going to ruin your life, so charge what you consider an obscene amount for this and plan to hire help to cover it.

Consider suggesting a very lax but cheaper SLA to them, they might not care much, maybe it is just a check-box on their end?

>Consider suggesting a very lax but cheaper SLA to them, they might not care much, maybe it is just a check-box on their end?

Also a very good point, and something I asked them about. Could be just copy paste and that they really don't need those numbers towards me.

Otherwise thanks for the great advice!

They may just be concerned about ticking a box that your product has 24/7 support. In that case you could charge a smaller retainer and a large per incident fee. This would align the value they recieve with what they have to pay. It also incentivies them not to bother you unless it is a critical issue.

If they do require a flat fee, I would try to cap the number of incidents. This will force them to place value on support requests and not take advantage of the SLA.

You'll need to be explicit when defining the scope of the SLA. If there is an issue with your product that is impacting production, that seems like a reasonable support request. Alternatively, if they want consulting services or training that may be beyond the scope of the SLA. I've had expierence with customers who open a support request, only to request consulting services.

Great advice! The wording in the draft does not even mention that the SLA should have a fee, so I don't know if they expect it to be flat or if they are trying to trick me into getting it as part of the custom plan I am offering them ;)

Charge enough to hire help, get something like pager duty setup, keep up the good work. Set the time at something that doesn't cost you the contract.

Caveats if this is meant to be a lifestyle company

Sounds reasonable, and a good way of looking at it. Thanks!

Go with a big number

Bigger than you are comfortable with

>Their suggestion on emergency incidents is 30 minutes response 24/7.

Why 30 minutes? Why not 29 minutes? Why not 31 minutes?

We worked on a project with a client to predict a certain event which, if it happened, would result in a loss of about $100MM (that's a hundred million dollars).

During that conversation, the client said they'd like us to predict the event 48 hours before it occurs. My question right off the bat was: Why 48 hours? There was some answer.

My next question was: at what point is it too late to notify you?

The client said: never too late. Even if you predict it two minutes before it occurs, we have ways to mitigate the damage and procedures. We can do something to save the situation.

It went from 48 hours to 2 minutes, and the ML team was happy because these are really two different things to tackle.

Therefore, it is useful to ask about what they are trying to do? What systems are impacted? Where's the urgency?

One must be careful not to take client's solutions as a problem statement, but to discover the underlying problem they are trying to solve.

Here's another example of an informal conversation with a friend: the friend asked me "How do you solder a copper wire to a thin metallic plate"?

I could have just answered the question, but instead I asked "What are you trying to do?"

He said he had this fuse but the wire in the fuse melted, so he wanted to use a thicker wire for the fuse. I replied that it's the job of the fuse to die to save downstream equipments, and if he did that, he'd save a fuse but ruin costly equipment. The fuse did its job.

"Solder a thicker wire to a metallic plate" was what he thought the problem was, but it was his solution. A poor solution to the underlying problem.

Here's another example:

One project was stuck before we were involved and doomed to fail because "of the client". We went there. Big table with a bunch of people from legal, security, data, etc. They said there was no way they'd do what our company asked.

So we slid a sheet of paper and a pen and asked them "What are we asking? Can you draw the data flow?". We were hunched on each part of the big table over that piece of paper. Their security engineer drew the flow (VMs and different systems, our system). We smiled and said it's really not what we're proposing. We drew the actual thing, and he said "Oh, if that's the case then I don't have any objection". Unanimous sigh.

That was a mid six figure project unlocked just like that.

Asking questions and digging deeper and helping people figure out what they actually are trying to do really is a good way to find better solutions.

Very good points, I will for sure use this mentality when getting these details in

Reply on news.ycombinator.com