Don't hate your Deal Desk Process

Boom, the sales person got the sign off (or wants to send a contract out) - Woohoo!

Everything's going great, but there are a lot of internal stakeholders that need to give their two cents to make sure everything is aligned.  For a lot of companies, this is a nightmare of emails, attachments and has a lack of visibility as a whole.  Reporting doesn't exist (or it's in a different system), and there is money on the table you might be able to get sooner with a better process.

Thankfully, it doesn't have to suck, and Salesforce can easily take care of this using flows, wizards, and custom objects.  Step 1 is the hardest, but if you follow this you'll take a complicated process and turn it into a beautiful candy land of visibility.

Define the Deal Desk Process

The sounds dumb... (of course you'd need to design it) but here's what to look out for:

1. Approver Variance - Large teams many managers and the Owner of the Opportunity, Products, or Size may determine who is notified, when, and what they need to.
2. Permissions - If you need to ensure that one group shouldn't review the contract before another person, or only certain people can access specific fields and designate d times.
3. SLA's between Teams/Players - Everyone will have visibility into the progress of the Deal Desk request, so it's more a matter of setting expectations of turn around time.  Ensuring that each player has bandwidth and ability is essential before anything is built.
4. Software Access - Is everyone in Salesforce? Or do you need to create an API to communicate to a 3rd party tool.
5. Key deliverables at each step - Finally, what each person needs to deliver.  This could be a POC, Financial Review, or Contract Conditions.
   

The Salesforce Build

The best, and most fun to build deal desk systems, are those designed for complex internal users.  Often when I step in, the AE would need to know when/who to get approvals from as the deal changes and there is a ton of risk on the AE's that doesn't need to be there.

I would build.a custom object on the Opportunity that drives the user's experience.  A screen flow on the Opportunity then drives the user through filling out exactly what they need to (only those fields would populate).  Then the deal desk request would be on the Opportunity, with Status' so the rep could see exactly where it is.  Here is how I'd solve the above sections again.

1. Approver Variance -
   1. Simple - Use Standard Salesforce Approvals if an Opportunity needs to be approved by a Manager or by several layers and it's within the Sales and Finance Teams.
   2. Complex - If you are building out a custom object on the Opportunity/Quote then you may want to create a flow to associate approvers.  This would also allow you to create Custom Metadata to control approvers in a nicer UI.
2. Permissions - Generally permissions would be Validation Rules, Page Layouts, and which screens you show the user in the process.  I try to stay away from Field Level Permissions as occasionally I'll want an automated process by the running user to update that field (just remove the user's capability).
3. SLA's between Teams/Players - Once you have the SLA's, create a tracker on each step using a Start and End Time. If it's sequential, marvelous, if it has the ability to be rewound (for status' to go backwards), it can be more complicated.
4. Software Access - Ideally everyone is working in Salesforce, but if they aren't try creating an external chat user and/or sending automated emails.  If there is an external system you need to API into, that's fun too.
5. Key deliverables at each step - Custom fields, abilities to make attachments etc... Easy part.

Don't forget to Train

Training a new process starts before the build is done.  Before even starting on the build, think through the roll out process and who will be responsible for ensuring that the process is followed.  Ensure that all your team is aligned on the process and the expectations that you've talked through.  Identify a key user that people on the team listen to bring them to train first.

If you are building it to report on delays in the process or because the right approvers weren't getting notified, doesn't matter... Report on it. Bring it to the forefront of your users and allow them to understand the significance.  Let them see the impact of it.

Like I said, this is one of my favorite builds.  It reminds me that the most important part of a large scale business transformation is unifying teams around a process that can be followed into the future. At The Sales Nerd we focus on developing a unified strategy before jumping into any build with tools like The Sales Nerd App to ensure communication happens throughout a project. If you have a fun build, or want to geek out about revenue operations, reach out!