Can you use Twillio as a smart routing business phone solution?

Yes, a consistent sales process is vital so that you know where you are. You also want to know why you lost some orders and won others--I was over a decade into my career before I realized I had no idea why. And that's what lead to the change. You need to understand your numbers. You need to know what the process steps are, and how to proceed to the next one--or let the opportunity die if it should (hint: if you're trying to turn every prospect into a client, you're doing it wrong.) And you must have your fulfillment process dialed in, which at present with the description of murky data-gathering and pricing it sounds like you do not. Loads of info my my blog at http://www.salestactics.org Let's discuss specifics on a call.

Instead of repeating the wisdom of others, I'll link to it below. Here is a great blog post on hiring your first salesperson: http://tomtunguz.com/when-to-hire-a-salesperson Also, Mark Suster has written a ton of great post on his blog about startup sales. http://www.bothsidesofthetable.com/on-selling/

I've been involved in several projects that hinged upon this question (generally start-ups or web+mobile apps), and it's not a clean or easy answer unfortunately! Plus every developer you talk to is going to try to sell you their services, but what you need is simply the truth! I'd suggest that you consider shifting your focus away from finding a best language. That sort of premise can eliminate options that are actually quite valid solutions. Keep in mind that any mobile app will require multiple languages working in harmony - all while used in a commercially consistent and standards-based manner. That's the part that determines your technical scalability! Almost every programming language can achieve this functionality with an experienced developer on your team. The best advice I can give you, is to consult with at least two people on this, and three if your app is os-specific. The most important insight will come from a "full stack" developer. One who's got a variety of enterprise experience, and can code at all levels of the stack. This person needs to have experience in leading a team of other developers, which forces the strategy of which technologies to use and why onto their plates daily. Secondly, you'll want to consult with a "front end" developer, who can tell you what's possible using advanced OOP JavaScript techniques (like Google's angular.js), because in an absurdly fast change over the past 3 years, much of the formerly back-end work has made it's way to the front-end, and is driven by JavaScript, predominantly JSON data, and awesome API's. The game has changed and the front-enders are the poor souls dealing with this rapid shift daily. To do this, they're also fantastic JavaScript programmers, which is a language that runs on all mobile devices and all browsers, too. Love it or hate it JavaScript is the most commonly used language in the world. Finally, if your app is OS-specific, you'll want to consult with a developer who works predominantly with the OS your app is built for. This person lets you know what's possible from the device POV, should know what stacks and JavaScript approaches can and can't be done on that OS, and how to leverage the resources of the device for your app as well as extend it's functionality. BONUS - loop back to the full stack developer to double-check the claims of the front-ender and the mobile developers. Always double check with your most senior programmer ;) All of these consults together in addition to your own research and due diligence will get you comfortable and allow you to navigate on this rather daunting but deeply important journey. There aren't any turn-key options. Instead it's a series of inter-connected modules driven by different languages, and all working in tandem. Every solution will have bugs, and no one group of technologies can do everything without proper developers. If you'd like to go further down the rabbit hole, then we should definitely set-up some time to speak. Otherwise, I wish you great luck in research and encourage you to learn as much as you can! :) It's going to seem hard, and might give you a headache here or there, but learn everything you can about how different technologies "talk" to each other, and then you will be able to build a map for keeping your app and business scalable regardless of the changing tides of technology!

Hi. I'm a Business Intelligence consultant with most of my customers being call centers. There are definitely guidelines you can apply but it will be based on several factors. Your question references ratios, which I assume means you would like to know how many agents per customer. That number will vary greatly depending on a number of other factors including: -what is your ASA target (Average speed of answer)? -what percentage of calls should meet the ASA? -are their penalties below a certain threshold (if less than 80% of calls meet ASA in 24 hours, for example) -how long are calls waiting when they don't meet ASA? -what is the call distribution by day of week, time of day and holiday v. non-holiday. -what is the average call duration? -what is the % of calls requiring escalation or call back versus calls resolved on first contact? To simplify it though, the two most important (IMO) will be call volume and your target for ASA (assuming you aren't answering then putting them back on hold, etc). To simplify though, the top 3 are: ASA, Call length and call volume. Regardless of the size of customer base. A good reporting system that combines live metrics and daily/weekly/monthly analysis will help a great deal. Feel free to set up a call if you'd like to talk about this in more detail.

I've been developing web and iPhone apps for a while and I usually recommend to first use the provided sharing mechanisms. They provide great flexibility and as well don't require your app to request permissions on external networks. Using the iOS SDK sharing components will also save you precious development time. The most important part is the content that will be shared. On that side, make sure all the content has a unique URL, and can be properly consumed on all plateforms, desktop and mobile. Pay a particular attention to the head meta tags of those pages. Open graph and Twitter tags are not optional anymore and help driver a better visibility on the networks your content is being shared onto. Don't forget to track with an appropriate analytics tool how your users use the sharing module. Then you can evaluate the pertinence of building something custom.