

Ask HN: Please review RoboNOC, phone calls for server alarms - mmelin
http://www.RoboNOC.com/

======
steveplace
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

~~~
mmelin
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.

------
mmelin
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 :)

------
cperciva
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.

~~~
mmelin
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.

~~~
cperciva
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.

~~~
mmelin
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.

~~~
cperciva
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".

~~~
mmelin
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.

------
marram
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?

~~~
mmelin
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!

------
hapless
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.

~~~
mmelin
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
:)

------
rlonn
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

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

~~~
aristus
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.

~~~
mmelin
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.

