Permission Required: Users with Manage Automation profile permission can access this feature.
Free | Standard | Professional | Enterprise |
- | - | 3 (includes default Blueprints) | 20 (includes default Blueprints) |
A Blueprint in Zoho CRM is designed to help you execute a business process in a well-defined, systematic manner. With a Blueprint you can,
See also :Blueprint - An Overview
To learn how to design a Blueprint, let’s consider a scenario. Zylker Inc is a software company sells cloud applications. Their deal follow-up process consists of the following stages.
Let's see how this process can be designed in Zoho CRM using Blueprint.
A Blueprint is designed by creating a sequential order of these stages in a process. In CRM lingo, the primary building blocks of a Blueprint are - States and Transitions.
Each stage in a process is referred to as a "State" in Blueprint.
For example, a deal in CRM goes through different stages until Follow-up - Qualification, Negotiation and Discount approval. Each of these stages will be called a “State”.
States must be dragged and dropped in the Blueprint Editor to design the process flow.
A Transition is a link between two States in a process. It prescribes the conditions required for a record to move from one State to another. For example, the conditions and actions required for a record to move from Qualification to Negotiation are prescribed in the “Transition” block called "Negotiate".
We will look at these blocks in further detail below.
Building a process is largely a 3-step procedure.
Note:
What does the above process flow mean?
This is a pictorial representation of the Deal Follow-up process followed in Zylker Inc. Deals entering this process will go through every stage in the order seen in the picture.
It so happens that sometimes you are not ready to deploy your final Blueprint into CRM yet, and you need to put some more thought into the process flow. When you publish a Blueprint, you will begin having records entering it - so it's not a good idea to deploy it before it's ready. In this case, you can save a Blueprint as a DRAFT.
You can play around with your States and Transitions in the DRAFT version, and once you are satisfied with the final process flow, you can PUBLISH your draft. Note that the draft version is not a testing environment, rather a canvas of sorts, for you to test your process flow. You cannot test the execution of a Blueprint with the draft version - for now, it's only meant for you to play around with the process flow.
At a given point in time, you can have one "Published" version and one "Draft" version of a Blueprint.
The moment you edit a Blueprint, you can either publish the changes directly or save the latest version as a draft. You can toggle between the Draft and Published versions in the Blueprint Editor.
Now that the process flow has been created using States and Transitions, the final step is to define further Transition settings.
“Transition” refers to the change of state in a process. It is the connecting link between two States, where the conditions for the change are clearly defined. A Transition is made up of three parts - Before, During and After.
For example, let's look at the Transition between the States - Qualified and Negotiation Done. Let's name this "Negotiate". In Zylker's example, following are some guidelines to be observed while configuring the Transition settings in this scenario.
Let's see how we can accommodate all of these points in the Blueprint.
This section guides the Transition owners in completing a particular stage in a process by prompting them to enter specific fields, notes, attachments and other information contextually. For example, in the deal follow-up process, sales reps may be required to enter the discount percent, notes and attach a few sales documents according to the organization's policy. In such a case, all these details can be mandated in the During Transition section of the Negotiation Transition.
Following are the details that you can mandate in the During Transition section:
You can guide your sales reps to enter information required as part of your process by mandating fields at the appropriate stages. These could be fields from the primary Blueprint module or related modules. For example, in the Negotiation stage of the Deal follow-up process, you can mandate the following fields:
To mandate fields of the Blueprint module and related modules
Checklists are nothing but To-do items to help your sales teams keep a clear track of the number of tasks and items they must complete in order to get through each stage of a process. This helps you better streamline every tiny step that you take towards executing a stage so that you never miss what’s important at the moment.
Checklist will be part of your During Transition, which, when configured by the manager or the process architect, will be shown to the eligible transition owners.
For example, in our Deal follow-up process, the following items could be part of a Negotiation Transition Checklist.
To mandate checklists
This will be displayed to the selected Transition owners. Only when the Transition owner "checks off" these items from the list, will he/she be able to proceed to the next State in the Blueprint. This gives you a solid, clear picture of progress of each stage.
Apart from fields and checklists, you can mandate the creation of items associated to the Blueprint module as listed below:
For example, once the discount has been approved and the deal is in the Contract stage, you may want the sales reps to associate the Quote and schedule a call with the customer to proceed with the legal requirements. So here, you can mandate Task creation and PO association.
This will be contextual and guide the sales teams in breaking down a possibly overwhelming process into smaller pieces and doable action items.
To mandate the creation of associated items
There's nothing like clear instructions to sales teams to make sure they execute a process efficiently. Include messages to sales teams at each stage, so that every Transition owner knows what's expected of him/her.
To add a message to the Transition owners
You may want to know additional details about various aspects of a process, such as why a sales rep entered a particular discount, why a particular task is pending and so on. These additional details could be added as notes - and these notes could also be mandated in the During Transition stage of a process.
To make notes mandatory
Any process, be it sales, insurance, manufacturing or real estate - any business process for that matter brings with it the need for several documents. Sales contracts, Service Level Agreements, Legal Documents and so on are required at different stages of a process. You can mandate them at the required stage in a Blueprint.
To make attachments mandatory
Define actions to be automated at the completion of the Transition. Actions that can be automated in the After Transition section are:
In Zylker's example, an email notification must be automated to the Sales Manager regarding a deal submitted for discount approval. So, choose Email Alerts and associate the required email template.
In a similar manner, you can build conditions for each Transition until the end of the process. To see how this Blueprint is executed, click here.
When you put a process in place in your organization, you need to ensure that it also gets done on time. SLAs help you do exactly that.
"SLA" stands for Service Level Agreeement - and is usually understood in the context of a service provider and customer. This term in Blueprint stands for an agreement of sorts between teams within an organization to communicate the maximum time a sales rep/team can keep a particular record in a said state. For example, if a deal is the "Qualification" stage for too long, the sales manager or the record owner must be notified of this. But how long is too long? If it does stay in a State for too long, who should be notified and what should be done about it?
These details can be configured as part of the Blueprint via SLAs. When you configure an SLA, CRM watches the records and how long each record is in a particular state. If it exceeds the time limit mentioned, the system will send alerts as configured to the users mentioned in the SLA settings. This helps you be transparent with the progress of a process across your organization and get things done on time.
To configure SLA for a State
A Common Transition is a Transition that can be executed from all States in a process.
For example, in a Deal follow-up process, you typically know if you have won or lost a deal after the record goes through several stages such as qualification, negotiation, discount approval and so on. So Deal Lost is a Transition that is available only towards the end of the process. But assume that a customer shows no interest and you want to drop a deal at the Qualification stage itself. In such a case, you must be able to execute the Deal Lost Transition right then - rather than go through all the intermediary stages.
To make this possible, you must make Deal Lost a Common Transition by selecting the checkbox as seen in the following image. Once you do, you will see the Deal Lost Transition on all States. Currently, you can have 25 common transitions per process.