How you can leverage Fyno’s Routing feature to send intelligent notifications

Working in the Operations team of a CPaaS company gave me firsthand insight into the customer communication issues customers faced, both transactional and promotional.

We often take for granted when something works well, commonly saying "If it's not broken, why fix it?". But when we wait for something to break before fixing it, two things are adversely affected: customer experience and brand name. I never felt good about this.

At Fyno, we've identified this problem and, while we haven't solved it, we've gone a long way towards closing the gaps. Our Routing feature helps you stay a step ahead in the communication game.

Routing enables you to manipulate providers, route conditionally, set up failover, and even use variables (placeholders/replaceable parameters) within and outside of notifications.

I'll discuss a few real-life problem statements I've encountered over the years and show you how Fyno has handled them with ease and grace.

⚡ Plain Vanilla Routing Optimizations

We all appreciate having options and choices, especially when we know that some providers have unscheduled downtimes and a backup plan is more than necessary.

One of the biggest issues I have seen over the years is that changes to the notification layer require Engineering (code-level changes of content or API), Marketing (content-related updates), and Vendor Management (provider-related commitments, cost optimization, etc). And usually, a Product Manager is scrambling between these teams to get the gap closed, the set-up functioning, and into production.

A simple change of just revising the notification content sometimes takes around a month! Why? Because sprints and releases are not aligned until then.

Working in Ops, I used to interact with VMs to keep up with vendor commitments. It’s a daily check (and a pain) to ensure we are meeting their commitments.

These were just some of the "easy" issues that were always annoying when they did come up. People complained, saying, "We should solve this permanently," but guess what? As soon as the end result was achieved, this was put on the back burner again and the same process was repeated every time it occurred.

But no more!

Let’s take each case and see how Fyno’s Routing feature will make for a more intelligent notification layer to work with!

The case of “adding a new provider”

We've all experienced this: Adding a new provider for a service such as SMS, Email, or Push Notifications is a task that shouldn’t be delayed. This requires code-level changes, discussions with the EMs about what will be affected, alignment with a sprint or release, code review, and a QA check.

Generally, the implementation alone (without vendor onboarding) can take anywhere from two to four weeks depending on your company's sprint cycles.

With Fyno, you can integrate a provider in just five minutes. For example, if you have a route that's already configured with an operator like "Twilio" for SMS, and you want to add "MessageBird" and split the traffic between them, Fyno's "Round Robin" feature under Routing lets you do it in just five clicks.

P.S: This just took me 30 seconds to setup. Just saying

All you’ll need to do is, log into your Fyno Application and:

1. Configure the new provider - MessageBird.
2. Under Integrations select Providers and hit the “Create” button in the SMS section.
3. Provide the Route name and on the page that opens, choose “Action” on the Component connector.
4. Select your “Routing Strategy” as “Round Robin” from the drop down and select Twilio and MessageBird as the 2 options.
5. Save and promote this route to live.

And thats about it!

But, this is just easy stuff. Let’s make it a little bit more complicated.

I spoke with the Vendor Management team in my previous organization almost daily to check our progress and what remained to be done. For example…

The case of “ Traffic Distribution”

The problem statement is simple: 2 providers needed to be utilized, and based on either commitment or pricing, the target was to achieve 30% on Twilio and 70% on MessageBird

The solution, on any other given day, is not so simple.

Previously, this would have necessitated conversations with the vendor team to determine which provider should receive traffic on a daily basis. The team would then manually make the changes. In the event that any provider failed to provide notification, the team would manually revert the settings.

Not anymore.

Again, 5 steps, 40 seconds and we are done.

So, essentially, if you had an account on Fyno, it would look something like this (working with the assumption that the providers are already configured on the application)

1. Navigate to Routing from “Integrations” section.
2. From the SMS routing page, click “Create” and provide a name and description to continue.
3. On the page that loads, select the “Action” on the component connector.
4. Selecto your “Routing Strategy” as “Distribute Between” and then add Twilio as well as MessageBird in the field provided. Next to each provider, specify the percentage of traffic you intend on routing through  each, i.e. 30% and 70% respecitvely.
5. Save and promote this route to live.

And we are good to go!

No daily checks with the vendor team, no manual switch-overs, no failures.

These are possibly achievable with not too much of “code complication”, which brings us to our next use-case.

The case of “Eliminating and Selective Traffic Execution”

We all know that open parameters may be misused, sometimes just because someone can. Therefore, I want to eliminate the possibility of getting into trouble with the authorities by avoiding spam words. Additionally, I would like to route priority traffic through exclusive vendors.

Sounds pretty simple, right? Let me elaborate.

Let’s take an example of multiple checks where I want to:

1. Perform a spam check at the onset of receiving the content - with keywords (like gamble)
2. Limit message sending only to USA and India. All other countries, do nothing. Routing for USA and India as follows:
3. For USA - Traffic to be executed via Twilio Route, but time sensitive message with authentication keys to go through Twilio OTP Route and all other traffic through Twilio Route.
4. For India - same, but Indian providers, Kaleyra for messages with authentication keys and Gupshup for all other traffic, since its cost effective.

Let’s look at the steps to achieve this on Fyno’s Routing feature if you had an account on Fyno (working with the assumption that the providers are already configured on the application)

1. Navigate to Routing from “Integrations” section.
2. From the SMS routing page, click “Create” and provide a name and description to continue.
3. On the page that loads, select the “Condition” on the component connector.
4. In the pop-up that appears, select “Variable” and fill in the name of the variable where you are expecting spam words. In this case, I have mentioned “name”, expecting unwanted content to be pushing in this. And I will specify “gamble” as the value I am looking for.
5. As soon as this is saved, 2 branches will appear, effectively what I will need to do if the condition is true or false. True: Do nothing, since I want such spam content to be blocked and never transmitted. False: At this stage, all the traffic that has been passed will then be evaluated for the next steps.
6. The next component ( this is a continuation to the false response above), will be another “Condition” component. On this condition component, we will select the If condition for Country and specify the country as “United States”. This will again give 2 branches and they would be: True: If the Country is validated for US and traffic passes to this branch another validation for “OTP” (priority traffic) needs to be done, which can be executed with another conditonal branch on this. If the “Variable”, specified as OTP, is present, then traffic is routed through “Twilio OTP” and otherwise , it will be routed via “Twilio”. False: All the traffic that is not towards USA will be routed here. At this stage our secondary validation of “India” can be applied to this branch. So essentially for the “False” branch, we then add another “Condition” and provide the condition that False: Do nothing. True: Do another check for the Priority traffic with the key word as “OTP” equals “yes” and if true, then execute the traffic via Kaleyra, otherwise route all traffic through Gupshup.

Sounds complicated? It isn't, actually. When building the flow on Fyno’s routing , this entire process took about 3 minutes, as compared to writing about it here right now!

I personally believe that this is a very powerful feature and, when leveraged correctly and efficiently (with closed loops and conditions, of course), the Routing feature can be a powerful tool in your belt.

We are still growing and evolving ( and will hopefully never stop!) and are constantly putting our Routing Feature through different scenarios, to see how we can optimize things. If you think you have a scenario you would love to try out with this feature, let’s talk right away!

We all have scenarios where a customer or a client is tagged with some information, clubbing him into a group, aka cohorts.

While this tag is not necessarily something that would be passed as a part of a notification content, this can be sent as meta-data along with the notification details to Fyno, to help execute a specific action.

‍