Blueprint Vs Jouney Builder in Zoho CRM

Blueprint and Journey Builder in CRM may have technical similarities in terms of the components of the builder — such as States, Transitions and automated actions.

However, since they primarily differ in their purpose and objective, there is ideally no room for confusion in what they set out to accomplish. 

The confusion, if any, between Blueprint and Journey Builder could arise from the fact that both the solutions have similar building blocks — States, Transitions, and Actions. This is because both the solutions are developed based on the concept of Finite State Machine (FSM).

Learn more about process management systems and an overview of process capabilities in Zoho CRM. 

Finite State Machine (FSM) — The Model Behind the Process Builders

FSM is a mathematical model that is widely used to devise sequential systems in the fields of software, gaming, AI and more.

"It is an abstract machine that can be in exactly one of a finite number of states at any given time. The FSM can change from one state to another in response to some inputs; the change from one state to another is called a transition. An FSM is defined by a list of its states, its initial state, and the inputs that trigger each transition."

Source: Middle Tennessee State University

Some real-world examples of FSM include a coin-operated turnstile that is widely seen in Metro railway stations, or elevators, combination locks and vending machines. A turnstile can only be in a locked or unlocked state — so there are two states (finite). In order to move from locked to unlocked, it needs a coin. The coin triggers the transition between State A to State B. While it is unlocked, a coin won't put it back to the lock state— it needs to be turned and clicked back into position. Similarly, without a coin, you cannot open it either. So it is a clear and foolproof system — purchase a coin to unlock your way through the turnstile.

In software, various BPM solutions have been modeled on the Finite State Machine, and therefore are bound to be similar. They are all likely to have states and transitions, as that is what the Finite State Machine method primarily involves.

Therefore, Blueprints and Journey Builder in Zoho CRM, which are both modeled on the Finite State Machine, contain the same building blocks — States, Transitions, and Actions. However, what you do with these components differs in both, because the objectives of both solutions are different. Here are some fundamental factors of differences between the two. 

Primary purpose

Blueprint is a business process management tool to promote compliance, whereas Journey Builder is a tool to optimize the customer journey across business touch points.

States in a process Vs states in a journey

States in Blueprint are built out of picklist values present in a record's layout. Because it helps manage compliance, Blueprint allows you to consider pick-list values like lead status, deal stage, as stages and helps you govern a record's progression across different stages from the time of its creation.

States in the Journey Builder indicate where in the entire buying journey a customer stands. This state can be associated to a CRM module. For example, when a visitor signs up for your product, they can then be classified as a lead and their webform entry could be indicated in the Journey as a state called Lead Created mapped to the Leads module. As they traverse through the Journey, you need to instruct the CRM which module they need to be mapped to , in order to keep a track. Aside that States in Journey Builder are free-form states, as in, you can create a State of your choice as you build your Journey. They are not specifically from a pick-list field and do not need to be pre-defined unlike in a Blueprint. 

Transition Vs Triggers

Blueprints guide sales teams through a systematic process. As part of the guidance, Blueprint prompts data from teams at each stage, validates data received, and automates routine actions, thus promoting compliance across the board. The successful execution of a mandate, be it entering fields or fetching attachments or crossing out checklists, transitions the record from one state to another. 

With Journey Builder, there is no question of "collecting data" or guiding teams, because that is not the objective. The objective is to orchestrate a series of events based on a previous outcome. For example, a website visit should prompt a live chat message for a visitor, and a subsequent chat response should alert an agent as well as send an acknowledgement to the customer's email. This email should subsequently trigger follow-up reminders to the agent to attend to the chat message. In this simple example, you can see how the objective is to automate a series of actions or events to make the customer's experience a pleasant one. This is not just for a single customer, but every customer going through the website and chat widget will receive this experience. Therefore, this is all about streamlining the customer journey across the board. 

What moves a customer from one stage in their buying journey to another, is the signals or events received, when trigger or propel them forward in the journey. Based on these triggers, subsequent actions are framed. So the transition block here is not a data mandate but signals or events. Examples: Opening an email, Response to a survey, Filing a Desk ticket and so on. 

 

Factors of difference	Blueprint	Journey Builder
Purpose	Compliance management	Customer journey optimization
Who is this designed for?	Internal organization teams	Customers
Definition of State	Each stage in the business process. That is, the values of the chosen Status picklist field.	The stage that a customer is in, in their buying journey.
Definition of Transition	The Transition in a Blueprint prescribes guidelines to be followed, actions to be performed, and data to be submitted by the indicated user or team. Fulfillment of the prescribed actions will move the record from one state to another.	Transition in a Journey Builder indicates the signals/triggers/events indicated that when encountered will move a record from one state to another.
Example of States and Transitions.	State 1: Enquiry received State 2: Requirement brief created Transition between States 1 and 2: Create brief Attach document Add a Note about the requirement Add Mandatory Fields: "Product/Service required." This means, after an enquiry has been received, the next step is to verify and add the correct contact details. Only when the Phone, email fields have been provided will it move to the next stage "Enquiry nurtured".	State 1: Lead created State 2: Lead interested Transition (Signal/event) between States 1 and 2: Opened email When the lead has "Opened the email", which was possibly sent as part of State 1. So the opening of email is a signal or event for CRM to acknowledge and move the prospect from point 1 to point 2 in their journey.

 

FAQs 

Is it accurate to say that, in Zoho CRM, Command Center is a "Blueprint across modules"? 

No. It is not accurate to say so, because Blueprint and Command Center (Journey Builder) are essentially different in their objectives. It is true that currently Blueprint is built for a single module and Command Center can be built across modules. But this is a technical piece of difference and just because of this difference, one cannot assume that Journey Builder is a Blueprint across modules, because they are both meant to solve different problems. 

1. Blueprint is meant for internal process streamlining and compliance.
   Even if Blueprint were to soon be built across modules, it will continue to address compliance, so its workings will be different from that of a Journey Builder.
   
2. Whereas Journey Builder primarily helps you orchestrate a series of planned engagement actions across business touch points.
   Even if it is built for a single module, it will comprise of triggers and engagement actions and not data mandates as in the case of a Blueprint. 
   

How is Journey Builder different from Cadence Studio?

1. Cadence Studio can be seen as a subset of the Journey Builder. 
   
2. If your need is ONLY to streamline followup  actions — that is use a combination of Email, Task and Call to follow up with a prospect until a desired response is achieved— then use Cadences Studio. 
   
3. You can achieve the above in Journey Builder as well, however it may be laborious in Journey Builder, now that Cadence Studio will help you achieve follow up orchestration in no time. The association of email, task or call, based on a previous open, click or bounce is more seamless and handled directly in the interface of Cadence Studio, that you don't have to configure these triggers meticulously in Journey Builder. 
   
4. This way you can also offload all the follow-up based engagement orchestration from Journey Builder to Cadence Studio and effectively use Journey Builder to focus more on dedicated engagement actions after a successful follow up. 
   
5. Cadence Studio is effective during lead management until your prospect is engaged. Journey Builder could be more effective to continue engagement after the first successful contact and go on to streamline the journey till purchase, retention, loyalty and advocacy. 

How is Kiosk Studio different from Wizards? Is Kiosk Studio a process management solution? 

Kiosk Studio and Wizards are both solutions to customize your Zoho CRM account. Kiosk Studio is essentially a customization solution, which helps customize your UI flows in order to execute ad-hoc processes. It is a no-code platform to create your own widget inside which you can perform customized actions such as data entry, retrieval, automation and so on. Whereas Wizards is a specific customization solution which focuses on data experience.

Wizards currently addresses the creation of a record in a systematic manner by breaking a long, cluttered form into more thoughtful segments or "screens", thereby making data entry a less confusing and even enjoyable experience. You can save a record as a draft, and come back to it when you are armed with more details. For example, you have a lead on the phone, and you are trying to explain your product to them. Some of the lead's fields such as details about their requirements, their company background etc are unclear to you during the call. So you can simply save the record as a draft and come back to it when you have all the details and then publish the record into the system. Therefore, Wizards focuses on achieving this flexibility with data experience in CRM. You can also automate alerts.  Learn more>> Help Document

Whereas Kiosk is not just about data entry or retrieval but also beyond that — it can help with data entry, retrieval, execution of alerts, custom functions and other routine actions. More importantly it can be deployed at a convenient location in your CRM such as the Home tab, List View or Detail view and even the Setup space. You can use it to fetch selected records and update specific information from multiple modules inside a single widget, you can use it as a call script, and pretty much customize it the way you want in your organization.

Learn more >> Help Document

Here is a simple Kiosk for a company called Zylker Travels. Picture that a travel agent is on a phone call with a customer. The customer wants to quickly reschedule their trip. It may be difficult for the agent to navigate to the right module and update the correct fields. So Zylker has created a Kiosk, without the help of a developer, to create a customized widget and deployed it on the Home page, so that the agent can quickly access it, interact with the widget, update only the relevant fields, and navigate a flexible and super easy UI flow that is specific to their organization. 

This is what the configuration of a Kiosk looks like:

Can a Blueprint, Journey Builder and Cadence flow all run their flows without any problems?