Now that we’ve discussed the four building blocks, let’s walk through an example of how these tools can be used to onboard a new customer in an example scenario.
For this example, let’s say that we have an application where employees go to do training for their company. So, this is a B2B business where our customers are companies that need to train their employees. Our users are the employees of those customers who need to complete their lessons.
Now, let’s imagine that we have a new customer that is onboarding. This customer has the following requirements:
- There are employees that report to different offices depending on their location. Lessons must be customized depending on the office location of the employee.
- Employees should receive a customized email when they sign in to the application for the first time. The customer wants the email to be branded and personalized to help with getting employees to actually do the training.
- If the employee works in the field, send the employee’s manager an email when lessons are completed. That way, the manager can issue any equipment the employee needs.
Let’s look at the work involved with this customer onboarding. We have:
- Three new pieces of customer-specific data we must store on the user: Their office location, their manager’s email address, and if they work in the field or not.
- We have one new business logic driven decision that must be made. We will enable additional functionality If the employee works in the field.
- There are two events that must be broadcasted by our application when they happen so that a Rule can be triggered (and subsequently the Rule’s action)
- We have two new custom emails that must be created on behalf of the customer.
Without the four building block systems, this would be a lot of work and involve the software engineering team adding many customer-specific database columns and logic. Luckily, we have our Custom Field, Condition, Rule and Email Template systems.
Let’s assume that our application already triggers a Rule broadcast for when a new user signs up (because a previous customer already requested that feature). However, no one had ever requested the Rule system to trigger when a lesson is completed before. So, that becomes the work involved in this customer onboarding for the software engineering team. This would result in a single software story to add a Rule trigger when a lesson is completed.
Now, while the engineering team is working, the configuration team can also get started. First, they would create three new Fields for our customer:
Office Location
Manager’s Email Address
Works In Field?
Once our custom fields have been created, the next step for our configuration team would be to create the two custom emails that need to be sent for this new customer. They can use the Email Template system to design two new emails to be sent from our application to the exact customer specifications without ever leaving our application.
Then, we will set up our first Rule, which can be expressed in pseudo code as:
When a user is created, if conditions are true then send custom email
Finally, once the engineering team has completed their work of adding the new Rule Trigger, the configuration team can add the second rule we need, which can be expressed in pseudo code:
When a lesson is finished, if conditions are true then send custom email
Our second Rule should only be sent if certain conditions are met. In this case, we only want the email to be sent if the employee works in the field so that their manager knows to send them the equipment that they will need. The condition we add would look something like this:
Or, under the hood, it would be stored in Liquid as:
Now that we have this condition added to our Rule, we will only send emails to the person’s manager if their “works_in_field” value returns true.
With our second Rule in place, we have fulfilled the requirements of our newest customer! The software engineering team had one story to work on, and the configuration team had three fields, two Rules, one condition, and two emails to write.
This is the perfect example of how two different teams within your organization can work together to make a customer successful for the lowest cost to the business possible. Teams can work in parallel to onboard the customer as quickly as possible with the engineering team working on the Rule at the same time the configuration team is configuring things. Ideally, this request would be fast for your engineering team to build so that team can move on to the next high impact feature for your business!