Tag Archives: salesforce automation

A female employee speaking to her CFO about Salesforce automation.

How to Talk to Your CFO About Salesforce Automation

In this blog, I outline a strategy for talking to your CFO about investing in Salesforce automation. This involves researching what your CEO’s objectives are and suggesting a solution that’s proven to deliver the desired ROI.

Research Your CEO’s Goals

A female employee speaking to her CFO about Salesforce automation.

Before suggesting a new Salesforce automation to your CFO, you need to have a good overview of the factors they’ll consider before investing in one. 

The role of the CFO involves supporting the objectives of the CEO. They do this by driving top-line growth and shrinking bottom-line expenses. At the same time, they have to protect your company by ensuring it adheres to all the compliance regulations of your industry. 

So if you can attach the automation solution you’re interested in to one of the CEO’s goals, it will likely be accomplished.

How to Find Out What the CEO’s Goals Are

So how can you find out what the CEO’s objectives are?

It’s much easier than you might think. If your company is public, you can research the most recent quarterly earnings statement or earnings transcript and pinpoint what challenges the CEO wants to address. 

If your company isn’t public, research documents such as an OKR, V2MOM, or other company-wide goal-setting framework. Check the company’s press releases or internal newsletters, and pay attention during all-hands meetings.

Attach a Salesforce Automation Solution to a CEO Objective

Here’s an example of attaching a Salesforce automation tool to your CEO’s main objective.

Despite challenging market conditions including market volatility, fluctuating exchange rates, and skyrocketing inflation, your CEO’s main goal remains to increase profit. So whatever automation your CFO invests in has to move the needle towards that objective.

One way your CFO can support the CEO’s goal is to ensure you’re making the necessary price adjustments internally. You need to get the right price points to the sales team so the company doesn’t lose revenue. This has to be accomplished with as few resources as possible while adhering to all applicable compliance regulations.

For example, let’s say your company has business operations across the globe. In Salesforce CPQ, it can take between six and 12 weeks to manually make price adjustments resulting from fluctuating exchange rates. In other words, it would take that long before your sales team can sell at the accurate price point. And that equates to a substantial amount of lost revenue. 

Prodly DevOps for Salesforce CPQ provides automation that lets you accomplish the same volume of price adjustments in two to three days—instead of two to three months. You need fewer people for the project, so you can reallocate team members to other high-priority projects. What’s more: Prodly DevOps automatically creates an audit trail—so you don’t have to worry about being in compliance. 

In short, recommending the cost benefits of Prodly DevOps for moving your Salesforce CPQ changes to your CFO would be a strategic move.

Prove Your Solution Will Deliver the Desired ROI

Of course, your CFO will require proof that any automation they invest in will deliver the desired ROI. So how can you get that?

Many software vendors provide metrics to show how their automation positively impacts their customers’ top or bottom line. You can typically find this type of information in case studies and white papers on their website. If you can’t find the information, ask for it when you get a demo. 

Sometimes, Salesforce features interesting customer stories that illustrate how a specific AppExchange app helped a customer solve a business challenge and what the outcome was.

Prepare a Business Case for Salesforce Automation

Best-in-class software vendors partner with you to make a compelling business case that shows how your profitability can grow as a result of the application.

Business Value Calculator

At Prodly, we use a business value calculator to show our customers how the benefits of Prodly DevOps translate into financial impact for their specific company. 

Our business value calculator considers the cost of investing in our solution and balances it against five quantifiable outcomes:

  1. Deployment maturity: The percentage of efficiency teams obtain by using Prodly
  2. Risk savings: How much revenue could be lost due to downtime without using Prodly
  3. Agility: The percentage of increase in development capacity gained by using Prodly
  4. Pricing change increased revenue: How much revenue is lost while waiting on price changes without using Prodly
  5. Compliance: How much productivity could be consumed preparing for and undergoing external audits without Prodly

Equipped with the numbers of how much your business can profit from investing in a Salesforce automation like Prodly, you can confidently approach your CFO.

Keep It Short and to the Point

As you can see, talking to your CFO about Salesforce automation doesn’t have to be intimidating. Just do your research ahead of time to verify the automation aligns with the CEO’s goals and delivers the desired ROI. 

Pitch your proposal succinctly. Ask for five minutes of the CFO’s time, and give them the most impactful metrics. Then be prepared to follow up with more information if they’re interested.

Follow Up With Metrics to Show ROI

Let’s say the CFO decides to invest in the Salesforce automation you recommended. Then it’s best practice  to demonstrate the ROI after three to six months. This not only proves the business case—it also builds trust with your CFO for your next initiative. 

At Prodly, our Customer Success team is happy to help you determine the financial impact of our products. Then you can take the numbers to your CFO to validate your actions—which in turn can help advance your career. 

Do you want to find out how Prodly DevOps can boost your profits? Schedule a demo, and we’ll show you the business value calculation for your specific company!

FAQ

Why do I need Salesforce automation?

You need automation in Salesforce so you can implement DevOps best practices. These will enable you to deliver more high-quality changes faster than you could manually.

How do I quickly run a Salesforce CPQ deployment?

Prodly offers automation templates that are built for the entire Salesforce CPQ schema. Using them, you can run deployments in 80 percent less time than using Data loader.

Simplify Salesforce data migration

Simplifying Salesforce CPQ Implementations for Coastal Cloud

Coastal Cloud leverages Prodly to facilitate faster, more accurate Salesforce CPQ implementations.

Salesforce CPQ Implementations Are Smoother With Prodly

Coastal Cloud is a Salesforce™ Platinum Partner based in Florida, with additional development centers in Kentucky and Colorado. They help clients leverage Salesforce Revenue Cloud (Salesforce CPQ and Billing) to improve business results and deliver a superior customer experience.

Q2C implementations can be a time-consuming process due to the complexities of relational data migration. Coastal Cloud has overcome this challenge by employing Prodly.

This Q&A with Mike Ackerman of Coastal Cloud discusses how his team uses Prodly to enable efficient Salesforce CPQ implementations.

Simplify Salesforce data migration

Q: Mike, what is your role at Coastal Cloud?

I’m a senior technical architect at Coastal Cloud. I help our client implementation teams during the design, build, and deployment phases. I promote best practices and best-in-class tools so our consulting teams can deliver projects consistently and efficiently.

Q: Can you describe Coastal Cloud’s experience with Salesforce CPQ and Billing implementations?

We’re a leading implementation partner of Salesforce Revenue Cloud, which includes Salesforce CPQ and Salesforce Billing. We’ve implemented some of the largest and most complex quote-to-cash deployments to date.

Coastal Cloud is on a shortlist of partners with deep experience in both CPQ and Billing. We’re a long-standing partner. We worked with SteelBrick, which was founded by Prodly’s CEO, before it was acquired by Salesforce and became Salesforce CPQ. We’re happy to say that relationship continues today.

We’ve performed many Salesforce CPQ and Billing deployments with complex configurations of products, pricing, availability, discounting, billing, and revenue recognition rules.

Our quote-to-cash projects range in complexity. We’ve completed simple Salesforce CPQ implementations for midsize companies and highly complex implementations for large enterprises. With quote-to-cash playing a central business role, we often integrate with ERP and other systems.

Q: Why is quote-to-cash, and CPQ in particular, so challenging from a relational data migration perspective?

The real power of Salesforce CPQ is the flexibility and configurability. You need the ability to make product catalog reference data changes quickly and easily to leverage that power.

However, there’s a complex reference model working behind the scenes to enable this configurability in Salesforce CPQ. Implementation teams need to treat this reference data as another important artifact to be appropriately managed across environments.

When it comes to disciplined configuration management, you need to treat reference data as a first-class citizen. This is alongside the programmatic and declarative deliverables necessary to build and deliver the project.

Q: Why is relational data migration such a challenge?

Before we discovered Prodly, our teams executed a very labor-intensive process. It involved exporting configuration data changes to spreadsheets and meticulously loading them back into the target environments.

Salesforce’s internal IDs and lookup relationships are very complicated. So that load process had to account for the re-keying of relationship data. We needed to carefully load the parent and child rows in the correct order. Then we have to re-key the child rows to point to the newly imported parent.

This is a concern with related objects, as well as with rows within the same object that have a recursive relationship. You need to ensure that you’re loading the rows within the same object in the right order. Plus, you need to re-key those child rows before you can load them.

When you deliver changes to an existing target of reference objects, you identify each row with a unique external key. That way, you know if a row is being updated, inserted or deleted.

As you can imagine, using export spreadsheets with Data Loader can be a very labor-intensive and error-prone process.

After we discovered Prodly, this became a much more automated process. It saves us significant effort and reduces the risk of error.

Q: How long did it take to migrate reference data without Prodly?

Many factors impact the complexity of the Salesforce CPQ and Salesforce Billing model. Think of how many products are in the catalog, as well as the number of options and features you have. In addition, consider the complexity of the pricing and discounting rules.

All these factors influence the migration effort. However, it can easily take a full day to do one load without effective tools. This isn’t a scalable process when you’re following an agile development model.

Q: How do you integrate Prodly into your Salesforce CPQ implementation process?

In an agile development environment with two-week sprints, you want to set up and shut down feature development environments frequently.

To make your developers productive, provide them a full copy of the product catalog from which to develop and test. And you need to reduce that full-day migration process to execute refreshes reliably and frequently.

Let’s say we have three developers working on a two-week sprint. We start the sprint by setting up three empty DevPro orgs . Then we use Prodly to instantly populate these empty orgs with current product catalog reference data. Later, we’ll migrate that reference data to a fourth environment to support testing activities.

We also use Prodly for quick, ongoing deliveries of incremental data changes for bug fixes. When a fix is ready for production, we save time and reduce risk by delivering the final reference data using Prodly.

Note that we reduce our users’ outage window significantly by using Prodly during the production migration.

Q: How do you avoid duplicates when you migrate relational data?

You’ve got to ensure you have a unique surrogate identifying key on each of the rows of the product reference objects.

Prodly uses this key to identify whether it’s an insert, update, or delete action when copying the data. Hopefully, a surrogate key exists in your data set already, but a lot of times we find one does not.

For instance, you might assume the product SKU is surrogate, but in reality there may be business meaning in that SKU. Perhaps those first two letters of the SKU indicate the line of business.

Perhaps the business team decides somewhere down the line that they want to change that SKU during a rebranding effort. Where you thought something was a surrogate unique identifier, it may in fact change in the future. That could break your deployment process.

Ideally, you want to start the project by identifying truly unique surrogate IDs for each row. You want the developers to set a surrogate ID once—and know it is never going to change.

IDs should have no business meaning and must reliably identify the uniqueness of a row as it moves across environments.

As Salesforce developers know, we can’t use the Salesforce ID for a surrogate key. The ID is not updatable and it changes as it moves from org to org. Surrogate IDs are an important success factor in making the reference data management process reliable.

Q: How exactly do you configure Prodly data sets to migrate CPQ reference data?

Today, this is part of the startup steps for getting a Salesforce CPQ implementation project up and running. We install Prodly in the client’s org. Then we the data set or template for the objects we’re going to ask Prodly to move back and forth.

The data set represents the configuration, or instructions, on how the data will be moved. We define this initially in production to prepare for the copy of data from production to our development and test orgs.

When you’ve made changes in the development org, it becomes the new source. Those changes can be copied to test and later to production. To re-use the data set configuration we already defined in production, we copy it to the development org. That way, it can also facilitate that org’s new role as being the source for changes.

Currently, Prodly must be installed in any org that acts as a source for copying data. We can also use Prodly to push its own data set configurations to and from various source orgs. That way, we don’t need to re-define the data set from scratch. We’re essentially creating our own template.

With Prodly’s centralized deployment architecture, pushing data sets and installing Prodly in the various source orgs will no longer be necessary. Instead, we’ll be able to manage deployments from a central org. This will be another big time saver.

The centralized deployment console can potentially offer smaller clients a shared reference data management service based on Prodly.

Q: How do you hand off the reference data update process to a client once you finish your Salesforce CPQ implementation?

Our standard methods and tools now include the use of Prodly for managing complex reference data migrations.

During our discovery phase, we identify if these challenges are present. Our teams identify this risk early and ensure the project is scoped to include the appropriate tools to mitigate this risk. This helps to ensure our clients and delivery teams are set up for success.

Prodly is a key part of our risk mitigation tool set.

Ideally, we want our clients to procure their own Prodly licenses. That way, once we’ve successfully delivered our project, the client’s Salesforce support team can continue to smoothly execute the process.

We ensure the process is well documented and train the client’s administrators on how to use the tools. We have a very robust configuration and release management process that’s well documented and repeatable.

Some clients opt to engage us for long-term Salesforce support. In those cases, which we continue to leverage Prodly for highly efficient reference data management.

Q: Any final thoughts?

Using Prodly, we’ve been able to dramatically improve the efficiency and quality of managing our Salesforce quote-to-cash data. We’ve taken a day-long reference data process and now execute it reliably in mere minutes. Prodly has drastically improved the way we operate and increased the ROI for our Salesforce quote-to-cash clients.

Do these Salesforce CPQ data migration challenges sound familiar to you? 

Schedule a free demo now to see how Prodly can help !