Ask HN: Please review RoboNOC, phone calls for server alarms | Hacker News Reader

Ask HN: Please review RoboNOC, phone calls for server alarms

robonoc.com

11 pointsmmelin17 comments

Your copy and design need a little work.

One big block of text is hard to read, try breaking it up into bullet points or something similar. The actual text needs work as well; you could pay 40 bucks to hire a copywriter

The blue highlights don't work, hard for eyes to follow.

Put a subtitle below your logo that explains exactly what you are doing. Something like: Dead Simple Server Monitoring

Your FAQ needs formatting, but I'm guessing you are iterating as we speak

The bit about you being in the EU is not needed, unless it's there for legal reasons.

Instead of putting the text explaining you use paypal, just use a paypal icon as well as credit card icons

Thanks a lot for this feedback. All very good points. Since everything is still very non-final (see points on pricing etc.) the copy isn't as polished as it should be.

I've turned off the Paypal integration, so you can try the service without having a Paypal account or giving them any CC information. Just sign up for the service and it'll automatically be set as paid up. Please don't abuse :)

Immediate reaction: Hey, cool, I've been looking for something like this.

5 seconds later: $29/month? No way I'm paying that much for a service I hope to never need.

2 minutes later: Hmm, only email? I'd like something more reliable than email for a monitoring system.

I'd like to see this service changed by:

1. Replacing the monthly fee with a per-call fee. I'd happily pay $5 to get a phone call if my server died. (But ideally there should be some way to test that the system is working without paying $5 per test.)

2. Adding different ways to have phone calls trigerred. Ideally I'd like to seen an HTTP POST gateway -- that way I could write monitoring scripts which can make sure that the message reaches RoboNOC.

Edit:

Also, 3. If you don't have this already, have a "press 1 to acknowledge this message" at the end of a phone call, and have some mechanism for retrying calls.

Hey, thanks for your feedback :)

Per-call accounts are definitely something to be added. The biggest issue holding that back is getting a payment gateway set up to be able to do ad-hoc debits.

Look for a HTTP POST gateway soon - the thing about email is that it plugs right into all existing monitoring systems and apps, so there is no need for any changes apart from adding a new alert recipient. Edit: also, we hope that our email setup is as reliable as can be. Of course you also need to trust your outbound server.

3. Yup - we're also looking into adding escalation routes based on this information.

Have you considered using a prepaid system, i.e., have people "buy 5 phone calls" which sit in their accounts until they are used? Tarsnap uses a prepaid billing model and it is working very well.

also, we hope that our email setup is as reliable as can be. Of course you also need to trust your outbound server.

Right, and it's more the outbound server that I'm concerned about. After all, even if email delivery usually works, the one time when it is most likely to not work is when there's a network problem to report.

Prepaid might work, it is how most external monitoring providers sell their SMS credits. The thing about prepaid though is that the one time something big happens, you've probably ignored the "Please top up" emails all month.

If you're having network problems then a HTTP interface probably won't make much of a difference, though :) To help here you usually have an account with a third party such as Pingdom, JustUptime, etc.

Well, I'm thinking more of transient network issues -- the sort of things which could result in email sitting in a queue for hours, but wouldn't stop a script which loops "send HTTP POST to server; read response; if we didn't get a 200 OK, try again".

Oh, OK :) Well that is definitely something to add. Please check back tomorrow, or if you'd like me to drop you an email, just send to martin at staff.robonoc.com - Thanks.

I tried it, and the robot called my phone. It came from a +46 number. Sweden? nice.

The robot voice was very hard to understand though. You really should record the voice yourself or get a friend to do it. Also, I needed to press 1 to activate, but to deactivate I must call support? huh? Why can't I just press 2?

Thanks for the feedback. The voice is the synthetic voice which actually does the live calls as well, so if you think that's hard to understand then we need to get that fixed.

The authorization message could be clearer, though. It's asking you to press 1 to authorize. What it's supposed to communicate after that is that if you have no idea what RoboNOC is, i.e. if a customer has entered an incorrect phone number to authorize, then you should contact support so that we can take a look at the account. We're assuming here that if you click the "call me now" button you want to authorize the phone number if it goes through.

Caller ID varies between which VoIP server picks up the authorization call. We're trying to get them standardized but there are a few hoops to go through when trying to get downstream providers to accept caller IDs with numbers they don't control.

Thank you again!

This isn't hard to do for free, with open source speech synthesizers and a modem.

That's well out of the reach of the general public, but presumably folks who run their own servers and monitoring systems have the technical acumen required to implement your service themselves if it sounds useful.

Thanks for your reply. Yes, of course this is possible to do yourself, as is almost anything these days. This is geared towards those who don't feel like setting up their own redundant infrastructure offsite just to make phone calls :)

I like the name, and the robot :-)

Not a bad service either, but I too think you should offer it on a per-call basis. That way there is very little reason not to buy it.

  /Ragnar

Thanks Ragnar :) There seems to be consensus that per-call is the way to go, going to work on this soon.

This is awesome. I was going to build something myself with ribbit.

Think over the pay-per-call idea very carefully. On one hand it feels good to potential customers, but if they are in a real emergency, knowing that each of those little robo calls costs them 1 euro or whatever will start to grate.

Also, pay-per-call diverges the incentives. They are essentially making a bet with you. The better their uptime (good for them), the less revenue you get (bad for you). It's dangerous to build in a divergence like that if you want repeat business. You might want to charge a yearly fee plus a small charge per call.

Thanks! :) There are a few API-type options like Ribbit available for those who like to tinker and we actually considered using one of them first for RoboNOC. However the value-add we're trying to provide is both ease of use but also redundancy and security, and so we built our own infrastructure to not be reliable on any one third party.

You have a very good point on the pay-per-call. Going to pay-per-call will of course drastically change the revenue models and forecast, but is of course (or at least looks like) a better proposition for new customers. Combining per-call fees with a yearly charge might be the best of two worlds but will also need careful work to communicate effectively and not complicate things.

Reply on news.ycombinator.com