In Evo Voice, Modularity refers to reducing the amount of duplication and complexity that exists in Flows.
Even though there is no performance penalty for having lots of duplicated Nodes all over the place, by consolidating functionality into reusable Flows, you create a system which is easier to use.
Throughout this section, we will be using a single complex communication example and simplifying it as we go. It is not required that you follow along with your own system although you are free to
The example that we will be using is one of a standard business center. The following list shows the requirements for the Flow
- The business center answers calls on behalf of some of their customers (e.g. call screening)
- Some customers, the phones ring directly to the user bypassing the operator
- If the operator or user doesn't pick up, the call goes into the voicemail for that customer
- Voicemails are sent to the customer by email, text, and push notification
- Some customers are Spanish speaking and those customers go to a different group of operators than the English speaking ones
- The business center has a main line which rings directly to a single operator (not a part of the English or Spanish operator groups)
- The business center also has a voicemail and those voicemails will go to a very specific email address/SMS
Version 1. Flow per Customer
The most inefficient way to solve the above issue, is to create a new flow for each customer, for example
Note that the Node properties are all hard coded for the specific customer such as shown below
The above example meets all of the requirements for our call screening customer ABC Company, it checks the day of week, it sends to the operator mon-fri and voicemail otherwise. However, there are some major problems with creating a flow for every single customer.
- If the location changes their hours of operation, every single flow must be updated.
- If a new operator is added to the call center, every single flow's Dial Operators node must be updated
- If we decide to add an automated message before putting the caller into Queue we must add that to every single flow.
Version 2. Flow per Scenario
A much better solution is to create a Flow for each scenario. Based upon the above requirements list, we have 4 unique situations
- Customers that have their calls screened by the English speaking operators
- Customers that have their calls screened by the Spanish speaking operators
- Customers that have their calls go directly to them
- The Business center main line.
In order to support this, we are going to create 4 flows, we will call them "Call Screening English", "Call Screening Spanish", "Call Direct Customers" and "Main Line"
Call Screening English (and Spanish)
Let's build this flow first. Since we're going to be consolidating all of the unique per customer flows into a "Call Screening" flow, we're going to need some Flow Parameters
|Greeting||Audio File - this will be used for the voicemail portion|
|EmailAddress||String - this is where we will email the voicemail|
|MobileNumber||String - this is where we will SMS the voicemail notification|
The Flow Parameters for Call Screening English look like the following
Note that the top 3 parameters are Public - this is so that they will be configurable on the Endpoint when we assign it. The bottom two recording parameters are used for storing the Recording data.
The Flow itself will look like the following
Note that for the Node properties themselves, we are using Flow Parameters instead of hard coding it, e.g.
If we look at the Dial Operators node, you will see that we have our two english speaking operators
Now if we want to use this Flow for one of our English speaking customers, we Edit their Phone Number endpoint such as:
Note how we have the two properties that we can use to customize the flow, Email and Mobile. Each Endpoint (Customer) can have a different set of values for these but all use the same Flow.
We are achieving some reuse!
For Spanish Speaking, we can now copy the English flow, with the same parameters but change the users in the Dial Operators node to be our Spanish speakers, e.g.
But this is still inefficient because the only difference is English vs Spanish operators everything else is duplicated. We'll clean this up in v3.
This flow is going to be very similar to the above flow, but instead of ringing the operators, we want to ring the customer directly. In order to do this, our Flow is going to need a User parameter in addition to Mobile and Email, such as:
This flow is almost identical to the English/Spanish call screening flows, but instead of dialing the operators, we are dialing the customer as shown below:
Now if we assign this flow to a Customer's main number, we will have 3 fields, such as:
And we can specify exactly where we want the call to be sent (e.g. to which user) and also the Email/Mobile for the voicemail to be received
Business Center Main
We don't even have to create a new Flow for this because the requirements are IDENTICAL to the Customers Direct, and that Flow will suit our purposes, except we will specify the operator we want to dial and the business center's email/SMS e.g.
Version 3. Cleaning Up Spanish/English
We have cleaned up a lot, we now only have 3 Flows instead of a Flow for every single customer/business center, but we can do better.
The English Flow and the Spanish Flow are very similar the only difference is which operators we dial. Let's go ahead and create a new Flow called Call Screening and we're going to add a new Flow parameter "Spanish Speaking", e.g.
And we'll modify our Flow as follows:
We added a Boolean node which allows us to check the value of a Yes/No value and Transition accordingly. You can see that we are checking the value of the Spanish Speaking flow parameter and if it is True, we dial the Spanish Speaking operators otherwise, the English speaking operators.
We can now get rid of our dedicated English and Spanish Flows and instead, just specify for each Phone Number whether it's a Spanish Speaking or not, e.g.
Version 4. Cleaning up Voicemail
We now have two dedicated flows, one for direct to Customer and one for Call Screening, but both have a few duplicated nodes for Voicemail. It would be a lot cleaner if the Voicemail functionality was moved into its own Flow and each of our main Flows referenced that.
Let's go ahead and create a new Flow called Voicemail, and give it Flow Parameters for Greeting, Email, and Mobile, such as:
Please note that the two Recording parameters at the end are used for temporary storage
Voicemail basically consists of the following steps
- Play a greeting to the caller
- Record the caller's voice
- Email/SMS the recording to the destination party
The Flow ends up looking like this:
Note that we are using Flow Parameters for the values for the Greeting, Email Address, etc.
Let's go ahead and save that and clean up our other flows
Our Call Screening Flow's parameters now looks like the following:
And we're going to remove the Play, Record, Email and SMS nodes from it. We're going to expand the Flows section in the Toolbox and add our Voicemail Flow.
And we're going to set all of the Properties of the Voicemail node using the Flow parameters to THIS flow, such as:
Look how much cleaner that is. Now we can go back to our endpoint and make sure it's configured correctly, e.g.
We can now repeat the same process of removing all the Voicemail functionality from the Customer Direct Flow.
In conclusion, by carefully planning out your Flows and choosing the correct set of Flow Parameters, you can convert very complicated communication challenges into reusable Flows that are easy to understand and modify.