Web APIs have been in use for the past 20 years. The growth of API use has allowed companies to focus on what they are really good at, their core competencies, and outsource the things they need in order to deliver a great customer experience. Salesforce.com first showed a demo of their Web API at the IDG Demo Conference on February 7, 2000. Now there are over 22,000 APIs available according to ProgrammableWeb.
APIs make it easier to build microservices architectures by seamlessly tying things together. Being able to outsource web services to APIs has dramatically transformed the way you can get services up and running very quickly and for less cost. If you think about your own company, chances are there are a lot of things you need to include for a great customer experience that are not your core focus. Some things you likely should not be doing yourself so that you can focus on your core expertise and outsource the rest using available APIs.
When you’re integrating real-time communications there are some things to look out for, as you’re trying to incorporate them into your SaaS offering. Typically, when people think about real-time communications, they may think that the implementation or integration is fairly straightforward. The reality is that quite a lot of challenges and decisions can come up when you’re starting to integrate real-time communications. There are a number of issues around number management, inventory management, porting, and the actual routing taking fraud analysis or traffic quality into consideration.
So, as you’re starting to implement or integrate real-time communications, we’ve seen that there are a number of different on-boarding challenges that you may encounter. Many of our customers have the interesting challenge of trying to create that best experience, the very first touch that your customer will have with you. You definitely want it to be a smooth one because that’s the very first moment they’ll touch a service.
We start off the process of creating this experience by setting up endpoints. This could range from an actual mobile application that you’re building that has a calling and messaging stack baked into it or something that could be browser-based, like a WebRTC-implemented service.
It’s best to think about the experience that you’re trying to craft, and then make sure that you deliver the best one possible. You don’t want your customer to try to configure whatever the devices, communication channel or endpoint really is. Those things should be pre-configured and ready to go the minute your customers wants to use your SaaS offering.
If your intention is to actually incorporate real-time communications between different users inside of your SaaS offerings, or between your customer and your staff, then you’ll want to think about how you introduce that into the actual flow or service. The context should really be focused on what you can do, versus how you get things configured.
For example, if you’re incorporating physical devices like desk phones, or maybe a conference phone, you may want to consider working with a drop-ship provider that allows you to pre-configure these devices. When it comes down to the actual “unboxing” experience you want someone to be able to just plug it in and be off and running.
The worst situation is where you have your customer open up their device, connect the elements, and then say, “what do I do next”? All of a sudden it’s a support call and that means they need to talk to support agents and spend time troubleshooting network issues and configuration issues instead of using the service. That’s a frustrating experience for your customers.
Incorporating phone numbers into your service using the Flowroute Numbers API
There are many ways to incorporate phone numbers into your services. Whether you want to use phone numbers for messaging, for multi-factor authentication, or for customer engagement between your staff and your customer, you will want to develop a game plan for using numbers inside of your service.
Here are some considerations using numbers in your service:
- How large is your customer base?
- Are phone numbers critical to your service?
- What locations or regions do you want to serve?
- Are you transferring phone numbers when you’re onboarding customers
- Are you developing a vertical SaaS offering?
- Are you designing a network that allows for many layers of high availability?
- What are your failover routes?
- What self-troubleshoot options can you include to resolve service quality or network issues that may arise?
The lesson as you’re developing your service is to be proactive about controlling the customer experience and set their expectations. Don’t allow them to come to you and say, “Hey what’s going on here?” because at that point it’s a very reactive model.
Learn more about the Flowroute Numbers API.
