4 ms·

Thanks for the upvotes! Cofounder here, thought I'd add a clickable link to what might interest you more: http://privatelabelsms.com/api http://privatelabelsms.

• e1ven 17y ago
  Can you help me understand what separates this from using clickatell, for instance? I can see that you're API seems designed to handle quite a bit of complexity in what to do when, I just don't understand the value-add yet. Is this lower-level or higher? Who is your target market? I see you're supporting SMPP, which is great for high-volume transfers, but I'm willing to bet most web-developers would prefer HTTP posts for each message, or a single HTTP post with a bunch of JSON/XML messages they want to send. Is that a Wufoo form at the bottom? Nicely done ;) I guess my core comment comes down to, you've explained very nicely that you're a "A robust, flexible & complete private-label SMS marketing solution".. But what IS that, and why do I want one? What is the value-add over dealing with SMS gateways directly? Or is this an example of "If you have to ask, you're not our target market ;) "
  • ytspar 17y ago
    The API was developed primarily around our own - and by extension, clients' - needs, which are more application and real-time notification oriented (I don't want to come off as spammy listing some of the use cases, but can do so if there's interest - some neat stuff there, IMO), rather than just focused on mobile marketing. I haven't looked at Clickatell's offering in a while, and normally don't get past the pricing tables (https://www.clickatell.com/pricing/pricing_wizard.php https://www.clickatell.com/pricing/pricing_wizard.php) when I mean to. The relevant comparison there would be with their two-way messaging services, for which you need a shortcode (Clickatell's explication, https://www.clickatell.com/pricing/shortcodes.php https://www.clickatell.com/pricing/shortcodes.php, and Wikipedia's, http://en.wikipedia.org/wiki/Short_code http://en.wikipedia.org/wiki/Short_code). Why you need a shortcode is another post, if you're curious. We do run our own SMPP binds, but for most developers we offer an HTTP API, which we use internally. And we're Rails guys, if that's meaningful. SMPP would be the way to deal with SMS gateways directly, so we're just as 'direct' as Clickatell, though the most direct way is working with the carriers on your own. You can listen to Fabrice Grinda talk about how much fun that is (http://www.venturevoice.com/2005/12/vv_show_21_fabrice_grinda_of_z.html http://www.venturevoice.com/2005/12/vv_show_21_fabrice_grind...). The next tier down are the aggregators (http://my.safaribooksonline.com/9780596515133/using_an_sms_aggregator http://my.safaribooksonline.com/9780596515133/using_an_sms_a..., and a less charitable take here, http://www.mobilemarketingwatch.com/the-problem-with-sms-aggregators/ http://www.mobilemarketingwatch.com/the-problem-with-sms-agg...), who abstract the carrier connections for you. Just below that are companies like ours. The differentiators at that level are pricing, live shortcodes, two-way messaging, APIs, and experience in building mobile apps. Plus dealing with carrier problems. Mobile messaging can be discouragingly complex and costly. So our ideal client would be another startup or SMB that could benefit from having comparable binds to an aggregator, without the months of setup and at a fraction of the price. Basically, we'd like to be a company we wish had existed when we were getting started. You would have to do decent volume to make it worthwhile, so it's not for everyone. The nice thing about not going mass-market is that we can be a bit more flexible. For example, we don't cap the number of top-tier keywords we offer, so you can use them for A/B testing across, say, print ads in different newspapers. Or you can resell them to customers. And yes, that's a Wufoo form... we have them set up on other sites, usually with a bit more attention paid to the CSS. We don't have to build forwarders and reporting tools - even a couple hours of dev time here and there add up, so we ruthlessly outsource non-core activities :) BTW, I've used Free411, great service.
    • e1ven 17y ago
      Sounds really cool, I'll take a closer look tomorrow- I'd love to hear about the use-cases, if only for my own curiosity. I certainly meant no disrespect, I was only trying to make sure I understand what you do, not impugn the service in any way. From what I've seen, building an internal framework out into a public-facing product seems to be the best way to do it; It ensures you're developing for a real need, not an imaginary "average customer" Your explanation of the market levels, and where you integrate makes a lot of sense, thanks. It might be helpful to add something to the page about why you're better than the competitors, even if you don't directly name them. Thanks again for the explanation, and I hope things work out really well for you.
      • ytspar 17y ago
        We've done a number of internal and client projects. I can name some of the former. We just launched http://RecessApp.com http://RecessApp.com, a SMS paging system iPhone app. We're running http://AntiTow.com http://AntiTow.com, a street-sweeping/towing alert system. We have http://VampireAds.com http://VampireAds.com, an outdoor text-to screen app. There's a list here: http://holmesmobile.com/projects/ http://holmesmobile.com/projects/ Otherwise, we do primarily real-time notifications and mobile marketing. And you're right about the website. This is the kind of feedback we don't otherwise get, so thanks! I'm also pretty terrible at making blog posts or throwing marketing materials into the ether. Much better when there's something tangible to respond to (which I suppose is analogous to your comment on imaginary "average customers"). But do impugn away if need be, though I'm enlivened by the warm reception so far.