Chapter 3: Deals – Sales Funnels to Fuel Your Business Growth

The Deals module is the central hub of your business development activities and will comprise qualified leads from new and existing customers.

The records in this module will make up your sales pipeline, and the way that you set up and use this module will have a significant impact on the future growth of your business.

The topics covered in this chapter include the following:

  • Mapping your sales process as stages
  • Understanding standard fields
  • Adding fields to quantify the deal
  • Improving data entry using layout rules
  • Adding depth by using subforms
  • Additional best practices

So, let's begin, first and foremost, with probably the single most important objective in Zoho CRM itself – defining your sales process within the CRM.

Mapping your sales process as stages

The most important and first aspect to consider in the Deals module is mapping your sales process. Once this has been defined, it will pave the way for the future growth of your business. The stages of the Deals module with supporting functionality (explained later in this chapter) will have a bigger impact on your business growth than any other field in the system. In Chapter 1, The Foundation Modules – The Building Blocks of Success, you saw an example sales process. You subsequently listed the stages of your sales process that, when followed, will provide the most effective way to process a potential deal until your prospect has agreed to purchase your products/services or otherwise.

If your business provides multiple services where the current sales process has different stages and terminology or you are struggling for inspiration, then you might be encouraged by the following use case.

One UK-based non-profit company with over 1,200 employees and 12 completely different business functions (divisions) made the decision to implement Zoho CRM across the whole organization.

One of the key deliverables was for the board and senior management team to be able to report on the volume and value of work and projects in the pipeline across the whole business. So, the implementation team stripped the processes down to basics and came up with a process that could be used by every single business development manager within each business unit.

The resulting stages were as follows:

  1. Qualified
  2. Discovery
  3. Proposal
  4. Pre-Mobilization
  5. Closed Won
  6. Closed Lost

With the exception of Pre-Mobilization, which is often named Negotiation, it's fair to say that the other stages could be used by many businesses around the world.

So, the moral of this story is that any organization that has multiple divisions and processes right now can consolidate them into one and thus simply report on and automate their workflows later.

Let's have a detailed look at how to set up the aforementioned stages:

  1. From the Home page in the CRM, access Setup by clicking the following icon:
    Figure 3.1 – Setup icon

    Figure 3.1 – Setup icon

  2. Navigate to Modules and Fields, move your mouse over Deals, and then click on Stage Probability Mapping. You will see the following screen:
    Figure 3.2 – Stage Probability Mapping screen

    Figure 3.2 – Stage Probability Mapping screen

  3. On the Sales Probability Mapping screen, you will see the existing stages.
  4. Click the Add Stage (+) link to add a new stage.
  5. Click the Remove Stage (-) link to remove a stage.
  6. For each stage, set Probability (%), Forecast Type, and Forecast Category.

    It is important to set Forecast Type, Forecast Category, and Probability (%) as they tie in with some of the standard reports and views of records and core functionality. These options are as follows:

    Forecast Type: Options include Open, Closed Won, and Closed Lost.

    Forecast Category: Select from Pipeline, Closed, and Omitted.

    Probability %: Add your typical Win Rate value for each stage.

In addition to pipeline reporting, there is a Forecasting module in Zoho CRM that may add further value. Further details are available at https://help.zoho.com/portal/en/kb/crm/sales-force-automation/forecasts.

The stage names you create here will dictate how you measure your sales pipeline. You will measure the volume and value of deals at each stage of your funnel, an example of which can be seen here:

Figure 3.3 – An example sales funnel

Figure 3.3 – An example sales funnel

Visualize your funnel as per the preceding example. Each of the labels will represent a key milestone stage within your sales process. Best practice includes making sure the stage names are clear, jargon-free, and intuitive. Ask yourself the following questions:

  • Does this process provide the most effective route to close more deals?
  • Would a future salesperson coming into our business understand what each of the stages meant and when each record should be progressed to the next one?

If you answer Yes to both of those questions, then your stages will most likely be good ones.

Once you have set up your stages, the following is a screenshot that shows how these milestone stages will appear when a user views a deal record:

Figure 3.4 – The stages as viewed within a deal record, whereby the current stage is highlighted blue

Figure 3.4 – The stages as viewed within a deal record, whereby the current stage is highlighted blue

Once these stages have been set, it is time to add additional fields that will help your team further clarify the customer's needs.

Understanding standard fields

When accessing the Deals module for the first time, for the same reasons as in the previous chapter, we must review and remove any of the standard (pre-existing) fields that we do not need.

A list of these standard fields can be found here: https://help.zoho.com/portal/en/kb/crm/customize-crm-account/customizing-fields/articles/standard-modules-fields#Deals.

The following is a list of the fields you should keep along with the reason(s) why:

  • Deal Owner: The name of the user to know the deal is assigned. This is also a crucial field when it comes to workflow automation and reporting later.
  • Deal Name: This is a mandatory field and is used to give the record a name that summarizes the deal. For example, a prospect for booking 25 delegates on a first aid training course would be named First Aid Training – 25 Delegates.
  • Account Name: This is a lookup of accounts that a deal is associated with. It is crucial that you keep this field as it will be mapped from the company name when a user converts the lead. Note also that if you have renamed the Accounts module, then this field will inherit the same name here. For example, if you renamed Accounts to Companies, this field will be named Company Name.
  • Lead Source: This is a crucial field that will say where this deal came from (mapped from Leads).
  • Campaign Source: If the lead source was Email Campaign, then this field will specify the name of the exact campaign this originated from.
  • Contact Name: This is a lookup of contacts that a deal is associated with. It is crucial to keep this field as this will be mapped from the Lead Name field upon converting the lead.
  • Amount: This is a currency field to contain the amount that can be expected after closing the deal. This is most often associated with revenue before tax.
  • Closing Date: This date field should be used to specify the expected decision date and will then become the actual decision (or closing) date of the deal. It is important that we keep this field as it is used in key screens, reports, and workflows later.
  • Stage: The single most important field within the Deals module as described earlier in this chapter. It is used to define our sales process and indicate which stage each deal is up to.

    Probability: Used to specify the probability of closing a deal (linked to Probability % from the stage).

  • Expected Revenue: Provides a weighted forecast amount based on the stage probability. For example, if we had a Stage Probability value of 50% at the Quote stage and the amount of the potential deal was $100,000, then, based on the 50% chance of winning the deal, we would forecast $50,000 (50% of $100,000). If you find this beneficial, then keep this field; if not, remove this field (and Probability).
  • Created By: The name of the user who created the deal as well as the date and time it was created.
  • Modified By: The name of the user who last modified the deal along with the date and time of this modification.

Once you have reviewed the standard fields and removed the ones you do not need, it is time to add some custom fields that will allow the sales team to further detail the customer requirements.

Adding fields to quantify the deal

The first stage of our deal process stage is often called Discovery, Needs Analysis, or Design.

Depending on the type of services and goods you are selling, your sales team will need to be asking questions to ascertain the exact requirements of your client. These questions, ideally, should be fields within the Deals module.

Consider these examples:

  • A business providing IT hardware, software, telecoms, and general IT support will need to ask questions to find out the number of workstations and users and the names and types of software applications that will be supported.
  • A CRM consultancy would need to ask questions about the number of users, configuration, training, and integration requirements.
  • A training provider would need to know the name of the course, the number of delegates, venue, and catering requirements.
  • A hospitality venue hosting events and conferences would need to know the number of visitors or delegates, timings, and the catering requirements.

    Tip

    List all the questions your salesperson will need to ask to obtain all the requirements of your prospective customer or client.

Once you have listed these questions, for each one, consider the data type of the field required in the CRM. Ideally, the fields to capture these requirements will be a mixture of Picklist and Number data types to make sure your team is quantifying correctly. You should avoid Single Line and Multiline text fields unless it is to capture any non-standard or additional requirements.

Now create all these required fields in the CRM, ideally locating them within a new, suitably titled section, such as Discovery, Requirements, or Needs Analysis.

Refer to https://help.zoho.com/portal/en/kb/crm/customize-crm-account/customizing-fields/articles/use-custom-fields#Custom_Fields for additional information on adding custom fields.

Note also that the fields that you mapped from leads as described in Chapter 2, Leads – Getting It Right the First Time, will also be present in Deals, so your layout will need to include these also. It is recommended that you position these fields toward the top of the deal form within a section named Deal Details or Requirements.

Tip

Organize all the fields in Deals in suitably named sections. Ideally, aiming for 10–12 fields maximum per section will keep our Deals records easy to read and intuitive.

Improving data entry using layout rules

Layout rules in Zoho CRM are one of the best features to make your system intuitive and user-friendly and to ensure that users always capture all the relevant details at the right time.

In the Deals module, we can, and should, use layout rules at most if not all stages of the sales process. Let's consider one of the examples cited earlier: IT services at the Discovery stage.

Example 1 – IT Services: One of the questions may be to find out the number of office workstations to be supported. This will be followed by a question asking whether laptops will also be supported (Yes/No). If the answer is Yes, then we can create a layout rule that shows and makes mandatory a couple of additional questions to find out the number of laptops (Number data type) and what type of operating software is installed (Multipicklist).

This layout rule can be set up as follows:

  1. From the Home page in the CRM, click on the following icon:
    Figure 3.5 – Setup icon

    Figure 3.5 – Setup icon

  2. Click on Modules and Fields, then click Deals.
  3. Select Standard (layout).
  4. Locate the field that will be the Parent or Trigger for this rule – in this example, Laptop Support Required – and then access a menu by clicking on to the right of the field:
    Figure 3.6 – Creating a layout rule

    Figure 3.6 – Creating a layout rule

  5. Select Create Layout Rule.
  6. Give the layout rule a name – for example, Show additional laptop fields. Choose a condition to initiate the rule – for example, Laptop Support Required is Yes:
    Figure 3.7 – Naming and initiating (triggering) your rule

    Figure 3.7 – Naming and initiating (triggering) your rule

  7. Click Next.
  8. Click on +Trigger Action.
  9. Click on Show Fields.
  10. In the Create Action section that appears on the right, locate (by scrolling or typing the name) the fields you now wish to show – for example, Number Supported and Operating Software – and then click Save:
    Figure 3.8 – Selecting which fields to show when the rule is triggered

    Figure 3.8 – Selecting which fields to show when the rule is triggered

  11. If you also wish to make these fields mandatory (recommended), then repeat steps 9, 10, and 11 by clicking on +Set Mandatory (instead of Show Fields).
  12. Repeat steps 5-11 for any other layout rules you wish to apply in Deals.

Example 2 – CRM Consultancy: A salesperson may ask the prospect if any integrations to third-party systems are required (picklist Yes/No). If the answer is Yes, then we can create a layout rule that will show and make mandatory further fields that present the user with a multi-picklist of possible systems to integrate with – for example, Office 365, Xero, Google, and Sage.

Tip

List all the conditional questions that need to be asked of the salesperson based on the values of previous responses. This will keep your system streamlined and intuitive as well as help the sales team enjoy using the system. Create layout rules for each one.

Creating layout rules triggered by stages

Most of the value in using layout rules in Deals is gained when they are triggered by a user updating the stage of a deal. As each stage is a milestone within our sales process, it follows that when these milestones are reached, we need to capture specific information.

Details recorded here should either validate that we have achieved a specific milestone or contain information to report on or share with other business functions.

The following table provides a few examples:

Table 3.1 – Examples of layout rules to be triggered at different deal stages

Table 3.1 – Examples of layout rules to be triggered at different deal stages

The examples provided in the preceding table are by no means an exhaustive list, so use these as a guideline and review your own process to identify which ones will add value to you and your team.

Adding depth by using subforms

A subform is a secondary form or table where we can associate multiple items to a single record. In the Deals module, this can be very useful as it will allow us to record additional information about the product or service we are providing to our customers all within a single deal record. This will help keep our CRM user-friendly, effective, and efficient.

For example, let's consider a company that supplies mobile telephones and contracts to businesses and consumers. The deal record will hold information at the top level, including the customer name, contact, and the stage we are up to in the sales process. The requirement may be to supply multiple handsets on varying tariffs, each potentially with a unique serial number or IMEI, as it is known in the industry. To try and manage this in the usual way with sections and fields only could be time-consuming and potentially limiting, as we may not have enough custom fields/layout rules to manage it.

Here are the instructions for creating a subform to manage this scenario:

  1. From the Home page in the CRM, click the following icon:
    Figure 3.9 – Setup icon

    Figure 3.9 – Setup icon

  2. Within the Customization menu, click on Modules and Fields.
  3. Click on Deals and then select Standard (layout).
  4. From the New Fields section, select Subform, and then drag and drop onto your deal form as shown here:
    Figure 3.10 – Creating a new subform

    Figure 3.10 – Creating a new subform

  5. In the textbox provided, give your subform a title, something that describes what this subform will be used to record details of. In this case, use Handsets:
    Figure 3.11 – Naming your subform

    Figure 3.11 – Naming your subform

  6. Now click on +AddField, and then click on the data type of the first field you wish to add within your subform:
    Figure 3.12 – Adding a field to your subform

    Figure 3.12 – Adding a field to your subform

  7. Now give the field a name and set any other properties as required (these vary by data type).
  8. Repeat steps 6 and 7 until you have created all the required fields (maximum of 10 per subform and 2 subforms per layout).
  9. Within Setup, your completed subform will resemble this example:
    Figure 3.13 – Example of a completed subform within Setup

    Figure 3.13 – Example of a completed subform within Setup

  10. Sometimes we may need to aggregate the total of one or more of our subform fields. In this scenario, we will use an aggregate field to sum the monthly rental for all the handsets and display this for the user. This is achieved as follows:

    a) Click on +Add Aggregate Field, then in the popup that appears, set Field Label, set Aggregate Function (choosing from Sum, Average, Max, and Min), confirm the field to aggregate, and then click Done:

    Figure 3.14 – Adding an aggregate field to calculate total monthly rental

    Figure 3.14 – Adding an aggregate field to calculate total monthly rental

  11. Within a deal record, your subform containing entries will look like this:
Figure 3.15 – Example of a subform containing multiple entries with an aggregate total

Figure 3.15 – Example of a subform containing multiple entries with an aggregate total

For additional information on subforms, please refer to https://help.zoho.com/portal/en/kb/crm/customize-crm-account/managing-subforms/articles/build-subforms.

If you do not identify a need for a subform within your Deals module, this is not uncommon, so simply do not create one at this time.

So far in this chapter, we have provided guidance on what you need to, why, and how. However, there are also a few other tips and suggestions that may help improve the setup of the Deals module.

Additional best practices

By following the guidance detailed in this chapter, you are well on your way to having a powerful, intuitive, and successful Deals module. However, here are a few more suggestions that may enhance performance even more:

  • Try not to have too many stages. Ideally, there will be 6–12 stages in your sales process. Too few stages may result in details either missing or being contained within fields further down, which will make things not as intuitive as they would be if the details were visible on the milestone/timeline. Too many stages will make it harder to focus and effectively measure our progress. Sometimes, however, it is beneficial to have more stages to help manage the process after someone has placed the order.
  • Do not have more than one unsuccessful outcome. In the example earlier in this chapter, we had just one unsuccessful outcome – Closed Lost. When selected, this would trigger a layout rule to show and make mandatory an additional field, Reason for Loss. This method is far more intuitive and easier to report on than having multiple stages, one for each unsuccessful reason.
  • Avoid adding an On Hold stage. There are many scenarios where a salesperson may cite that a deal has not been Won or Lost due to the fact that the client has just had to push back the purchase for one reason or another. While technically, this may sound like a credible reason to have an On Hold stage, it is not really necessary as the user could change the (expected) Closing Date value and add a note and a follow-up task to re-engage at a later date. Another reason for not using On Hold is that this stage is often misused and can lead to procrastination and/or offer the user an easier way out than admitting the deal is lost. Either way, having deals at this On Hold stage will often distort reports and clutter the pipeline.
  • Concede a loss much earlier. One common pitfall is that salespeople don't like admitting defeat, especially when a deal has simply gone cold or a customer has become unresponsive. Failure of the sales team to mark deals as lost will distort reports, clutter the pipeline, and distract focus away from deals that are still on the table. The best advice here is to agree on a timescale of inactivity/no response from a customer – for example, 6 months – and then mark the deal as Closed Lost manually or automatically using a workflow rule (refer to Chapter 6, Game-Changing Workflows and Automations).
  • Avoid too many fields. Salespeople in general do not enjoy data entry. If we add too many fields in the deals module, then we can put the user off using the CRM or encourage bad habits by explaining that they don't always need to fill them in. The best way to manage data entry is by using layout rules as mentioned earlier. The purpose of fields in the Deals module is to make sure we can accurately understand our customer's needs and also record details of the solution we will be proposing.

Summary

In this chapter, you have learned how to set up and optimize your Deals module effectively to create the perfect pipeline for your business.

You have gained confidence from the example of the business with over 1,200 employees across 12 divisions. If they can successfully adopt a sales process with just 6 stages that will work for all their sales teams, then it is achievable for all Zoho users to have a streamlined common process.

You should now have an understanding of the important standard fields and should have learned how to use layout rules to ensure that we capture the correct information at the right time. You should understand that doing so will help improve the discipline of the sales team and enforce consistency. You will be also aware of best practices to keep this module lean, streamlined, and intuitive.

Finally, you should have an understanding of the most common pitfalls that you should avoid when setting up this module.

In the next chapter, you will learn how to best set up your Accounts and Contacts modules, which will conclude the remaining foundation modules and also Section 1, Laying the Foundation, of this book.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.91.17.78