“Lite” telephony with MV

Over the last year I’ve been working intensely with telephony apps which integrate with MV – and I’ve blogged on this topic as well. This includes voice in/out and SMS in/out. If you have any interest in adding telephone or texting access into your app, check this out…

As some of you know, I’ve been building a new consumer-facing business on this technology. Unfortunately relations with the investors broke down, so that project now needs funding – so if anyone here wants to invest in a new business, this is a sweet opportunity… 🙂

But as a by-product of this work I now have components which can be re-used in other applications. As an example, I would be relatively easy to add these functions to an existing app, using nothing but BASIC:

Outbound voice

• Collections calls with transfer to company rep.
• Political announcements.
• Appointment reminders.
• Product sales announcements to existing customers.
• Notification of order shipment.

Inbound voice and DTMF

• Mini PBX with forwarding or blocking based on MV data
• Menu (for Sales press 2…)
• Product enquiries (enter product ID at the tone)
• (Toll Free numbers are available)

And SMS can be used for similar bi-directional functionality, even shortcodes.

To be clear – any app can process inbound phone calls or SMS requests with BASIC, and any app can make outbound phone calls and send SMS as well. Inbound calls can be transferred to any number you wish based on some table lookup that you do in your code. You can get PBX functionality without any hardware. I have to believe that you VARs have end-users who want this, and it would certainly be impressive in your sales efforts if you add it to your apps. For you end-users – one of the questions that I hear people ask all the time is “yeah, that PBX looks great, but how do I integrate it with my Pick system?” Well now you have an alternative solution.

I was thinking about packaging some of this into a “Lite” product offering. For example, add an account to your system and use some pre-defined BASIC functions, and you get tons of functionality with all of the technical details completely abstracted. This would allow a typical VAR or end-user to add functionality very quickly, and move toward something more sophisticated later if they wish.

But the “build it and hope they come” model hasn’t worked well for me in the past. I’d gladly productize an offering that has high-demand features, but unless such a set of features can be defined, I’d prefer to work closely with VARs and end-users to implement specific features for specific apps.

The difference between adhoc projects and productization is huge. It can take months to create an easy-to-install product which can be demo’d with a nice GUI, and sold to a general audience. That’s a tough investment to make, and I’ve done it too many times in this market with unfortunate results. Whereas, an extension to an existing application can take hours or days – or sure, weeks if it’s extensive. On the other hand, a product is “write once and sell everywhere” where custom code is not as portable, so similar work needs to be re-done. But for this functionality right now I’m tending toward services rather than products.

So, I welcome requests for products, even something “Lite”, and I’ll be happy to work out a commission deal with anyone who funds development of something that can be marketed. But in the mean time, if you’d like to discuss adding any of the above functions to your existing app, we should be able to do it quickly.

Please see our contact page and call or email. Thanks!