What is CommandCenter?
CommandCenter allows you to build online replicas of your business processes using multiple modules. It is ideal for organizations that have several departments, services, or third-party applications participating in the culmination of a single business process.
For example, loan sanction process, supply chain management, inventory management, ecommerce, etc. are lengthy, complex, and intricate processes where each level involves multiple transactions. To make sure the process flows without iterruption, it is important to monitor every stage closely and gather forecasts on: overall performance, stagnancy or loopholes in stages, and delays during transition.
CommandCenter allows you to design these elaborate processes and link independent teams and modules together to give collective and accurate insights about its performance.
Difference between CommandCenter and Blueprint
In Blueprint you can create a process for a single module, whereas in CommandCenter you can create a journey using multiple modules and third-party or Zoho applications.
For example, you designed a perfectly functional and productive blueprint for the supply chain process in your organization. A few years later, your company begins to also manage other arenas like vendor management, financial transactions, and courier tracking services.
To ensure the SCM process is running smoothly through all of these services and not stalled at any particular transit, you decide to include all the processes within the existing blueprint. However, you realize that though these processes are within CRM, they are not part of a single module and thus can't be added to a single process builder. This is where CommandCenter can help you.
In CommandCenter, you can build complex and widespread journeys that put together multiple modules and third-party applications under one process builder to give a bird's-eye view on the process's performance.
Users with the Manage Automation permission profile can access this feature.
Let's look at a few business scenarios where CommandCenter can be used effectively. See more use cases.
Loan sanction processes
Zylker Finances provides monetary assistance to small and medium-sized businesses. Applicants looking for a loan enter the necessary details in the loan application form and submit it for further processing. During this process, their form sails through different stages and departments like pre-approval, document verification, fund release, legal verification, and pre-closing before the prescribed amount is approved. Here, each stage plays a crucial role in propelling the application to the subsequent stages and finally completing the process. Therefore, an online replica of this process should be able to capture details like stages where an application is stalled, if a stage is skipped, the amount of time spent at one stage, and more.
The journey builder in CommandCenter gives a perfect platform for this by allowing you to add stages and transitions from multiple CRM modules. One can even define the deadline for a process's completion, add automated actions between stages, involve actions during transitions that can be captured in different modules, and more. Here is an example of how the journey will appear in CommandCenter.
Supply chain management
Zylker Logistics operates a supply chain management business. It transacts with several departments—production units, vendors, shipment logistics, and third-party services—to complete its production-and-delivery cycle. Their SCM cycle follows this route:
From the time the buyer shows interest in a product until it's successfully delivered, the SCM creates a network including individuals, organizations, departments, activities, and resources that culminate in the selling-and-buying cycle. All these touch points add value to the SCM operation, and it's important to monitor, manage, and track the efficiency and gather accurate insights on the performances.
Replicating this journey using CommandCenter will give detailed information about stages that propel a product's movement to the subsequent level, stages at which the product gets stalled, time spent at a particular state, and more.
These metrics in turn can help in revising the existing process, having tighter control over the associated costs, forecast customer's purchase behavior, throw light on lead nurturing efforts, and more things that impact the company's bottom line.
Core elements in CommandCenter
Similar to a Blueprint, you need to define states and transitions in CommandCenter.
The CommandCenter journey builder is same as that of the Blueprint. Here you can build a single business model using different modules and third-party applications.
States are the different stages of a journey, for example in the above mentioned loan sanction process: waiting for pre-approval, waiting for manual approval, document verification are the different states.
is the link between different states. It prescribes the conditions required for a record to move from one state to another. For example, the condition required for a loan application to move from Document verification to Loan rejected are mentioned in the transition Rejected.
Now you have some idea about the building blocks of CommandCenter, which are same as that of a blueprint. See also building blocks in a blueprint.
In CommandCenter, the number of journeys that you can create depends on the CRM edition that you have subscribed. Each journey or model can have five different versions, but only one version can be active at a given time.
To create a journey you need to follow the steps below:
Step 1. Adding basic information
Enter the journey name and give it a description.
Step 2. Adding States and their actions
Adding a state
In the journey builder, add a state that defines the first step of your journey. As CommandCenter lets you link all the CRM modules, you should select the module to which a state belongs. This must be repeated for every state that you add to the builder. You can add up to 70 states in a journey.
Defining actions in every state
You can define instant, scheduled, or recurring actions for each state. The action will be dependent on the state the record is in and will apply to all the records that reach the state.
: Let's say you want to send an email notification to the vendor when an order is placed, or send a payment link to the customer via SMS once the order is confirmed. You can configure it in the following manner:
- Record's state - Order placed/Order confirmed
- Actions configured - Email notification to vendor/ Payment link to customer.
Following instant actions can be set:
- Field update
- Email notification: 3 per state
- Task: 3 per state
- Add/remove tags: 10 tags/state
- Slack and Cliq notification: 5 notifications/state
Scheduled actions: You can set a particular action to occur after a record is in a state for certain days, hours, or minutes. For example, you can assign a task to call the customer a day after the first instalment is paid or a day after the vendor ships the product. You can configure it in the following manner:
Following scheduled actions can be set:
- Field update
- Email notification
Recurring actions: If you want an activity to occur repeatedly at regular intervals, you can set a recurring action. For example, you can send reminder emails every day for a pending payment, send notification to the vendor after the client confirms booking, or send email alerts to support agents until a ticket is closed. You can configure it in the following manner:
Following recurring actions can be set:
- Field update
- Email notification
Step 3. Defining the deadline for a state
If you want records to be in a particular state only for a specific period, you can specify a deadline for the state. You can also choose what should happen to the records after a state has reached its deadline—the record can either be escalated or moved to another state.
Note that the option to select a deadline for a state will appear only if you have added a transition between the states. Defining a deadline is not a mandatory step.
Step 4. Defining transition and when it should be triggered
A transition creates a link between two states. It lets you define the condition at which a record can move from one state to another. For example, a record can move from "order placed" to "order confirmed" only if the conditions and actions defined in the "product availability" transition is satisfied. You can add up to 110 transitions in a journey.
You can select when a transition should be triggered (this is a mandatory step):
- Submission of a webform — A transition will be triggered when a record has entered CRM through a webform. This trigger is available only at the beginning of the journey or for the first transition of a journey.
- Creation of a record — A transition will take place whenever a record is created in the specified module and layout.
- Edit of a record — A transition will be triggered whenever a record is edited. You can also add a condition. For example, whenever the lead status is changed to qualified, a payment link must be sent.
- Receiving an API call — If you want to invoke any transition from the third-party application, you can select this option and copy the API URL provided by us. Also, you can mention the parameters that should be passed along with each API call. You can select a maximum of six parameters from the following data types: string, number, date, date/time, boolean.
Note: Journeys created before
14th July, 2021 will have Long Integer ID and Journeys created after July 14th, 2021 will have String type ID.
- Approval of record — A transition will be triggered only if a record is approved. For example, an order will be placed only upon payment approval. You must select to which approval process the record belongs.
- Rejection of record — A transition will be triggered on rejection of a record. For example, the order will be canceled if the payment fails. You must select to which approval process the record belongs.
- A date/date time — A transition will be triggered at date or date/time field of a module.
- Sales Signals from different channels - A trigger can be initiated based on the response received on emails, chat, calls, support tickets, and marketing campaigns. For example, a support ticket can be created whenever a call is overdue or when a customer clicks on an email campaign "thank you for registering" email can be sent. You can also set criteria to state that the trigger must occur only for particular tickets, emails, surveys etc. For example, a transition will be triggered only when the "registration email" bounces not for other email bounces. Similarly, a trigger can happen when response is received to a particular support ticket only.
You can select a trigger from the following system generated signals:
- Outgoing emails - Sending, Opening, Clicking, Bounce, Not opened, Opened but not replied, not replied, unsubscribed
- Incoming email - Receiving
- Call: Receive a call, outgoing call is unanswered, schedule calls goes overdue.
- SalesIQ: Missed chat
- Zoho Desk: New ticket, comment to a ticket, overdue, response to ticket, rating, escalation.
- Email campaign: Opening, clicking, bounce, marking as spam, receiving reply, unsubscribing
- Zoho Survey: Sending, visiting, receiving response, survey visited, survey not visited.
- Zoho Backstage: Purchasing or canceling ticket, check-in by attendee.
- Zoho Webinar: Sending invitation, Registration received, attended
Aside from these you can create custom signals if you use other applications (that cannot be integrated with Zoho CRM) in your business and use them as triggers. See also Creating Custom Signals
- Once you define a trigger, it cannot be edited. You must delete it and add a new one.
- You cannot delete a module that is part of a state and the trigger point of a transition once it is defined in a process.
- The current record name field in the CommandCenter module will display the record's name based on its position in the module. For example, if the record is in leads module it will show record name - Leads module, if its in contacts module it'll show record name - Contacts module.
Step 5. Defining an action that should take place during a transition
You can set an instant action that should happen during the transition. For example, once the quote is approved, a notification must be sent to the vendor with the product details, quantity, and recipient's address. You can select the following actions:
- Create record
- Field update
- Email notification
- Add/remove tags
An instant action during a transition is particularly helpful when the state and transition are in two different modules. For example, in the above case, the state occurs in the "Quotes" module, whereas the transition takes place in the "Vendor" module. In other words, you can define different sets of actions for different modules in a single journey. Two different actions can be performed simultaneously at different states.
Step 6. Specifying criteria for the selected records to undergo a transition
If you want only specific records to go through a transition, you can define which criteria the records should satisfy in order to move into a transition. For instance, you can mention that only invoices above $3,000 should undergo a transition for "discount" before moving to the next state.
Step 7. Defining connectivity between records
This option can be used in cases where you want to track the specific records on which a transition occurred. For example, say you received a request for a product demo from three different customers through email. You send them webinar invitations, and a week after attending it, one of the three customers purchases the product. So this customer moves from the "lead" state to the "contacts" state. Since moving these states means moving between two modules, by using the connectivity options—look-up or reference—you can trace the path and find the action that propelled the record to the next state.
In our example, after attending the webinar, the lead makes the payment and moves to the next state (contact). You must add the contact's look-up or give reference of the contact within the lead's record to:
- Understand how the two records are interlinked
- What activity led the record to the next state
- The connectivity tab will be available only if the states are defined in two different modules. Like in the above example where the record moves from the leads module to the contacts module.
- Reference can be given only if a record is created through CommandCenter. Manual creation will not be considered. For example, a contact (record) is created after a lead is qualified.
Step 8. Adding a log to the transition
If you want to note any important details or information, you can type it in the log section. This can be viewed in the timeline under CommandCenter. You can add up to three logs in a transition.
You can insert merge fields in the log to view the complete journey of the record until the particular transition. For example, the below image shows which journey the transition belongs to, the name of the transition, when was it triggered, the action that took place upon trigger, and the result.
Design a journey in CommandCenter
To design a journey
- Go to Setup > Process Management > CommandCenter.
- Click Create Journey and enter the Journey Name and Description.
- Click Proceed.
- In the Journey Builder, select click to add a state.
- In Create State, enter the State Name, Description, and choose a Module from the drop-down list.
- Click Save.
You will be redirected to the journey builder. You can either add Actions to the state or click +Add State to add more states.
- Click Set deadline for this state and enter the number of day(s), hour(s), or minute(s).
- In the Actions tab, select Instant, Scheduled, or Recurring action.
- In Instant Action, click Add and select an action from the available list.
- In Scheduled action, enter the number of day(s), hour(s), or minute(s) and click Continue.
- In Recurring action, mention the number of day(s), hour(s), or minute(s) and click Continue.
For both scheduled and recurring actions, you can also add instant actions (field update, email notification, task, webhook, and function).
- Create Transitions by clicking on the + button between two States.
- In the Transition info tab, enter the Transition name, Description, and choose Trigger on from the dropdown list.
- Click Save.
- In the Action tab, click Add action and select an Action from the available list, under What actions do you wish to do during this transition?
- In the Conditions tab, click Add Criteria to define Which [records] would you like to apply this transition to?
- In the Logs tab, click Add Log > Enter the details and click Save.
- Click +Add State to add more states.
- Click Publish to make the CommandCenter live or Delete draft if you want to discard it.
System-defined lead qualification journeys are templates that give an idea about a basic lead qualification process that takes place in any organization. This prebuilt journey is provided to help you get started with automating the journey of a lead from creation till conversion.
In the template, we have broadly classified the Lead qualification process
into following steps:
- Lead created
- Call scheduled
- Attempted to contact
- Converted to contact
- Contact failed
At every stage the sales person performs certain activities to make sure the lead is qualified within the stipulated time. The activities can be sending emails, making follow-up calls, sharing details with other team members, conducting a meeting with the lead and so on. In the template we have provided some basic
actions that are ideal suited for the qualification process.
We are currently providing the following two templates:
- Lead Qualification through Call
- Lead Qualification through Email
The journeys for representational aide to the administrators.
The templates are built using the Leads and Contacts module only you can include other modules as per your business process.
Depending on your organization's requirement, you must customize the journey by adding, removing or replacing states, entering transitions and actions of your choice, defining deadline for a state, etc.
Note: The system-defined journeys are in draft mode by default, the administrators must manually enable them.
To enable the system-defined journey
- Go to Setup > Process Management > CommandCenter
- Click on the desired system-defined journey.
- Customize the states and transitions.
- Define actions and other details.
- Click Publish.
Define the order in which a transition must occur
In situations where the first state in the model has multiple transitions, the transitions will occur in the same order as they are listed in the configuration. But if you want, you can change the order of execution by setting the order of precedence.
Let's consider the loan sanction process. If the state "waiting for pre-approval" has two transitions—"incomplete information" and "exceeds approval limit"—the application (record) will follow the transitions in the listed order. If you want to reorder them, you can drag and drop the transitions to the desired order of execution.
Specify deadline for the journey
You can specify a deadline for the entire journey. For example, if your model concentrates only on lead generation, you can set a deadline for the journey after the lead generation state is reached. You can add a deadline either while configuring the journey or later. You can select the process and go to the Deadline tab and click Set deadline for the journey.
Here you must mention the number of days, hours, or minutes after which a journey should end. You can choose a deadline a few days after the start of the journey or after a state is reached (for example: lead qualified). You can define if the records should be escalated or moved to a state.
Setting a deadline allows you to see the number of records that reach the completion state and take remedial actions on the ones that are stalled at a particular state.
Edit versions of a journey
You can create up to five versions of a single journey, but only one version can be active at a given time. When you edit any active journey, there are three options:
- Delete draft - You neither save nor publish it. Just delete it.
- Publish as a new version - The edited version can be published as a new version. This will retain the existing version and allow you to compare the performance of the versions.
- Republish - You can overwrite the existing version.
View records in the CommandCenter module
Once a journey is created in an CommandCenter, a system defined module called "CommandCenter" is added to your CRM account. You can view the records that participated in a particular journey and filter them according to their instance ID, CommandCenter start date, CommandCenter deadline, state deadline, and more. When you have multiple models, you can use the custom view to filter and see the desired model. You can also use the smart filter to see specific records.
View CommandCenter reports
CRM gives three pre-defined reports for every journey built in CommandCenter. You must hover on the journey under CommandCenter list view (Set up > Process Management > CommandCenter) and click View reports to see the following reports:
- State-wise segregation — Number of records in each state.
- Average time taken in each state — Amount of time a record spends in one state. You can figure delays, pinpoint the bottleneck states, identify the states that have maximum stagnation, and note the time taken for a transition.
- Overall report — The overall report will give a pictorial representation of the entire journey with the record count in each state and transition.
Reorder, deactivate, and delete journeys
Reorder — Records enter the CommandCenter journeys based on the listed order. All the journeys you've created will be listed in the order of creation, but you can reorder them by clicking the Reorder Journeys option under Process management > CommandCenter. When you reorder the journeys, the records will enter the journeys according to the new order.
— You can toggle the
to deactivate a journey. Once deactivated, new records will not enter that journey until it's activated. However, the data within a journey will be kept intact.
Delete — You can hover on a journey and click the delete icon to delete a journey. However, before deleting the journey, you must note that:
- All the records that are currently in the journey will be exited.
- The history of the records (states and transitions that they participated in) will be permanently deleted.
- Actions that are scheduled for the current records will be stalled.
- You cannot delete the module that is part of a state and the trigger point of a transition once it is defined in a journey.
- If a record is part of the CommandCenter, an orange strip will be added to for easy identification. The strip will be visible in the record detail page and it will display the state where the record is coming from to the next state in line.
- CommandCenter is available in copy customization and sandbox.
- You can edit an existing journey and republish it, which will overwrite the existing version. You can also save the journey as a new version.