Here's a demo of an upcoming skill I've been working on called Inbox:
https://www.youtube.com/watch?v=ddNSrORWgro I'd love to hear your feedback or answer any questions you might have, so please fire away :) Description; as per YouTube comments: Inbox enables people to communicate with Users via the Amazon Echo (or Fire TV) over a number of protocols. Initial support will include SMS/text messages, voice, XMPP and email. Users can reply to the message originator using either pre-canned quick replies (e.g. "Yes", "No", "See you later", etc.), or even emojis. Copies of received messages can be sent from the Inbox skill to the User's email. Inbox will also provide an API so that Users can communicate with any external service capable of sending/receiving via this method.
Very Nice! I like that you can actually have audio/voicemail sent through Alexa. IF Amazon every allows people to subscribe to software that allows push technology, then Alexa could tell me I have a new text message as it came in. Do you know when your skill might be listed?
Thank you. The voicemail component was a little tricky as I had to build a dedicated pipeline for transcoding the 'raw' voicemail to the acceptable mp3 spec that ASK requires, and to do that asynchronously so not to impact either the inbound call or lock-step the skill with pending transcode operations. Task queuing, pull work unit consumption and callbacks have been my friend :) When/if Amazon switch on the ability for us to send push notifications, then as you say, I envision this skill becoming an answerphone-like service but the inbound messages being practically any protocol. I've not submitted the skill for certification yet - I need to fix up some bugs, and work out how I'm going to provide every Inbox skill owner with their own dedicated phone number :) I expect this'll be addressed by requesting a small monthly subscription to cover my costs. The question is - do you think users would pay for this service? (I'm thinking $4-6 per month)
To be honest, I think there is precious little out there people will pay money for. Taking money from consumers adds a huge amount of complication to what you need to do. Especially if you are having a weekly subscription. It's almost better to just let them pay once and be done with it. Even if you do that, you suddenly need a whole degree more of support. Since someone might disable the skill, then re-enable it, and want their service continued on the new ID. If you are keeping payment details, you need to keep those secure. If you have an automatic re-billing, then you have more support for people who forget to turn it off, and don't want to pay for it when it automatically bills them. Almost better to support yourself through advertising. I keep meaning to see if there's enough people yet for TsaTsaTzu to offer a "banner ad" like service to skill developers.
I disagree, and believe people will pay for skills that provide demonstrable value. Taking payments from consumers is straight forward enough with services like Stripe - they handle all the messy stuff like reoccurring subscriptions, promo codes, refunds, storage of payment info, etc. - and plugging their service into your own is a snap. I don't believe your suggested business model of one-off payments is sensible for skills like this. As a consumer - what if the skill permanently goes offline next week and I just forked out $xx for it? What recourse do I have if there's issues, or if I realise the skill isn't what I want? I can't stop paying the skill developer if it's a one-shot payment. As a developer - what if I want to deliver features that consumers are demanding, but which necessitate an increase in my operating expenditures? Do I increase the one-shot payment going forward to new users to cover this uptick? What if I want to deliver another feature that costs me more again next month? For this particular skill, if a consumer forgets and are auto-billed their monthly subscription, and want their money back - I can just refund it. Stripe doesn't charge me for this and also refund the original processing fee too. In this situation, the consumer probably hasn't racked up much (any?) costs on my side because they probably forgot the skill was there and so didn't use it.
>I disagree, and believe people will pay for skills that provide demonstrable value. Well, good luck with that. If so, you'll be the first. I don't think anyone else has cracked the egg on making money on productivity skills. I look forward to seeing [i]someone[/i] succeed.
I see all of this in a different light...although more hands on. If my business model is to help a client achieve use of the Echo for their own system, then it would work. Not selling a skill, but a service....and software...so, I could install a web server add my software for their use.
Great job! Depending on the complexity of the skill, I could possibly see the monthly fee thing working out. I think it all comes down to value... if the consumer sees it as a large value, then the likelihood of them paying for it goes up immensely.