Twilio Flex Review

Twilio Flex Reviews

Signup:

The signup process is seamless. In signature Twilio style, the UX is very very user-friendly.

Onboarding:

Once we log in, I could not see anything different from the actual Twilio platform. This is both good and bad news. I remember when we launched KOOKOO platform in India and expected users to build their own call flows, the one group it never took off with was the contact center users. There are not too many developers who work in this segment nor influence the contact center processes within their organizations. The best impact I have seen of developers in the contact center process is with <1% of the 1000+ enterprise client base we have.
But the good news is the brave attempt to leave the product completely open to users and expect/allow them to build. This move reemphasizes Twilio as an API company to the core.

Core functions of a contact center:

Now, Contact Center users are expected to learn a great deal when they switch from one product to another, but core functionalities of a product like ACD or a dialer algorithm is already built in. Twilio Flex is expecting users to build these functionalities on their own. This needs capabilities available very rarely in this industry. Also, expecting every organization to their own ACD is a dual-edged sword. Most of the users would want a ready-made setup, to the extent that we almost always have set up the initial IVR, agents, ACD, Queues and Voicemail/AOH setup for all clients who sign up with us.

It is not about self-signup but more of customer service and helping them launch successfully with your product. Looks like Twilio will have to invest a lot into integration coaches & design specialists who will onboard customers or build a great partner network.

If the idea is the partners will build in a standard app and sell on top of flex, isn’t that what Talkdesk has already done? It leaves a big question mark on whether companies can depend on Twilio to scale a business or will Twilio at some point launch a separate api structure to attract users of that business since the original app gained lot of traction. Looks like future revenue growth target commitments are impacting some core fundamentals they shouldn’t have touched as a platform player.

Features:

While the API usage is one set of challenges, the designer/flow builder is another set. Contact centers are not simple in flow where you give conditional call flow boxes for users to configure especially when you have 100 agents or more. Users would want the system to have the logic to dial agents, in priority, make them sticky to customers, even allow them to go on breaks – the entire Contact Center industry follows a standard process and the product has to work to that Without that, there will be very less organic user adoption and Flex will have to Flex a lot of marketing muscle for users to adopt.

Also, while all contact center features are mentioned on the Flex features page, could not see how we can set it up easily. For example, call waiting is a standard feature and in KooKoo it is a default setting enabled for an account. Here, even on searching, we couldn’t find
This means Twilio will have to invest in a lot of training which contradicts their self-serve motto.

Unlike the tech developer API platform, this segment is tough to change and sometimes it is easier to usher change with a balance in approach than being very radical. Also, I haven’t met too many developers who actually understand what goes in a contact center process.

Outbound Dialers:

Again, coding required ( This statement is redundant for this review ? While all our customers appreciate an API to manage data in the dialer campaign, we haven’t seen too many customers who want to create campaigns with API’s except a few. Further, supervisors like to have manual control of the data so they always can do the right thing, during emergencies in ops.

Configuration:

Almost all the functionality is dependent on being written in code. While this worked at the platform level, expecting 100 users to code on their own to write the same functionality is ridiculous. That is why the product route caters well to this market than the platform approach.

Cost Responsibility:

Twilio has forgotten in its success of the platform, that contact center industry runs as a cost center in any business, unlike the jazzy developers who have adopted their awesome platform. While changing the user behavior itself is a challenge, the bigger challenge is who will bear the cost of the developers who are supposed to integrate Flex into their contact center team process.

As of now, the product looks incomplete, and actually, we can not call it a product…Twilio says its a platform and we ought to build our stuff. Time will only tell whether the $ power Flex’s enough muscle to change users or the users overpower Flex and make it a product.

Pricing:

The pricing isn’t something we can say as good or bad as it goes with a whole loop of functionality, quality of service, SLAs which Twilio will offer. So presenting the pricing for a regular 30 seater contact center who will use the services.

With a price per named user per month of 150$ and assuming agents make/receive 50 calls per day with average talk time of 2 minutes, you will end up paying 5500$ per month approximately or 66000$ USD per annum as the cost of running a 30 seater.

This is way costly when compared to other products in the market (I don’t want to state names here ? Users have way better, easier to use products that go through this pain at such a cost. And mind you, we did not add the cost of a developer to run Flex.

Disclaimer: We have a competing product, KOOKOO Contact Center product we sell in the market.