3 ms·

Show HN: Pocket Alert – service for receiving notifications via API or Webhooks

3 points by Akellacom 3y ago

Hey there, thrilled to share with you my first project that finally went live: Pocket Alert a service designed to receive push notifications that you can send through an API or webhooks. And to that features a web interface for creating messages, looking up messages, configuration applications, webhooks, etc, along with mobile applications for iOS and Android. Would love to hear your thoughts and feedback on this!

jqpabc123 3y ago
So from what I can see, I am limited to sending notifications to one person at a time or everyone, correct? If so, this is not quite ready for "enterprise" use. Let's assume I have 20000 people scattered over 200 locations. Each location has multiple groups/teams. I would like to send a notification to team X at location Y. How do I do this? Also, it looks like I have to keep track of every device and it's type (iPhone, Android etc.). Shouldn't you be doing this? Your software for receiving notifications surely has this info. it looks like you're burdening your users with maintaining data they may not need or otherwise care about --- just to use your service.
- Akellacom 3y ago
  Hey! Thanks for your questions! > So from what I can see, I am limited to sending notifications to one person at a time or everyone, correct? On messages, the only limit is the number of messages sent per day. As for the "enterprise" plan, I think the problem is the naming. Because at the moment there is no teamwork as such, and it is supposed to use one or a limited number of people (number of devices). Thanks again for the feedback, it gave ideas on how to improve this point. I can easily add device grouping, and the ability to send notifications to a specific group. I have in a backlog of tasks to implement teamwork, but I've been putting it off because I'm not sure I can attract some big companies.
  - jqpabc123 3y ago
    I'm not sure I can attract some big companies. Yes, your most likely target customer in my opinion would be a service provider for lots of small to mid-size companies (aka me). Individuals will just use SMS. Larger companies will implement this on their own. My best advice is to make your service as logistically simple as possible. In other words: - Forget device ID. Almost every mobile communication device already has an ID, it's called a phone number --- which your customers will most likely already have stored for other reasons. Any mobile device that an individual regularly carries is likely to have one. - Forget device type. Most people don't care what "type" of device it is. Do you store this info in your contacts list? I don't and most companies don't either. If you need this, collect it from your mobile app and store it. Most customers won't be burdened with doing your logistics for you. - Grouping is essential for convenience but also efficency for yourself and for customers. Lots (if not most) business notifications need to go to more than 1 individual. Doing this one person at a time is unnecessarily tedious and time consuming. An acceptable alternative would be to simply allow the "send message" API call to accept multiple recipients. - Do allow customers to identify themselves with a user friendly name that individuals can select or input to receive notifications from. - In my opinion, your market opportunity here is to build a send only version of SMS that is just as easy to use while costing less. But you have more work to do.

3 points by Akellacom 3y ago

jqpabc123 3y ago

So from what I can see, I am limited to sending notifications to one person at a time or everyone, correct? If so, this is not quite ready for "enterprise" use. Let's assume I have 20000 people scattered over 200 locations. Each location has multiple groups/teams. I would like to send a notification to team X at location Y. How do I do this? Also, it looks like I have to keep track of every device and it's type (iPhone, Android etc.). Shouldn't you be doing this? Your software for receiving notifications surely has this info. it looks like you're burdening your users with maintaining data they may not need or otherwise care about --- just to use your service.

Akellacom 3y ago
Hey! Thanks for your questions! > So from what I can see, I am limited to sending notifications to one person at a time or everyone, correct? On messages, the only limit is the number of messages sent per day. As for the "enterprise" plan, I think the problem is the naming. Because at the moment there is no teamwork as such, and it is supposed to use one or a limited number of people (number of devices). Thanks again for the feedback, it gave ideas on how to improve this point. I can easily add device grouping, and the ability to send notifications to a specific group. I have in a backlog of tasks to implement teamwork, but I've been putting it off because I'm not sure I can attract some big companies.
- jqpabc123 3y ago
  I'm not sure I can attract some big companies. Yes, your most likely target customer in my opinion would be a service provider for lots of small to mid-size companies (aka me). Individuals will just use SMS. Larger companies will implement this on their own. My best advice is to make your service as logistically simple as possible. In other words: - Forget device ID. Almost every mobile communication device already has an ID, it's called a phone number --- which your customers will most likely already have stored for other reasons. Any mobile device that an individual regularly carries is likely to have one. - Forget device type. Most people don't care what "type" of device it is. Do you store this info in your contacts list? I don't and most companies don't either. If you need this, collect it from your mobile app and store it. Most customers won't be burdened with doing your logistics for you. - Grouping is essential for convenience but also efficency for yourself and for customers. Lots (if not most) business notifications need to go to more than 1 individual. Doing this one person at a time is unnecessarily tedious and time consuming. An acceptable alternative would be to simply allow the "send message" API call to accept multiple recipients. - Do allow customers to identify themselves with a user friendly name that individuals can select or input to receive notifications from. - In my opinion, your market opportunity here is to build a send only version of SMS that is just as easy to use while costing less. But you have more work to do.