Most SaaS companies, as modern as they are, will result in using Salesforce as their CRM. It is by far the vendor of choice by most experienced sales teams. As the engineering team responsible for monetization and billing, you’d be expected to help the sales organization streamline the account creation process from closed-won to account provisioned.
Whether your company is just now layering Sales-led or Sales-assisted GTM models while going up-market, or whether your GTM model was Sales-led since conceiving, translating bespoke closed contracts agreements into the right app allowance and access is not solved off the bat. Typically, someone is assigned to manually take care of each closed-won and make sure the right toggles and limits are switched on, which results in delayed and misconfigured provisioning.
In a happy scenario, that individual needs to be solving this problem using: Salesforce, Workato, Launchdarkly, Netsuite, and a sprinkle of home-grown admin panels. In an unfortunate reality, this person might also be using spreadsheets, YAML/JSON files and prayers 🤞.
As an engineer, you are typically too far and remote from how the sales team is operating daily; this is why it’s easy to dismiss their needs and appreciate their requirements, especially as they insist on using legacy eco-systems such as SFDC. Ultimately, architecting these workflows for scale and setting up tight foundations around entity mapping and automation triggers can help your team avoid a world of pain downstream having to hand-hold every future bespoke contract account creation.
Another consideration is that in most cases the product catalog and pricebook your sales team is operating is likely to have discrepancies from what your self-service catalog looks like. Sales require a lot more flexibility and wiggle room for adjustments to allow large customers to adopt your product. Rigid feature flags and hard usage-metering configurations can become a real obstacle in closing deals, which means they are very likely to become your problems to solve sooner rather than later. On the other hand, too much flexibility and not enough guardrails might result in enabling your Sales team to give away the farm.
The answer lies in a flexible product catalog controlled by the Product & Engineering team, that interfaces directly and seamlessly with your SFDC setup.This gives you control over what can be packaged and sold and in what order, while the Sales team gets speed and smooth experience in streamlining account creation from deal closed won.
Introducing Stigg’s Salesforce integration
Today, Stigg announces a native integration between your existing Salesforce workflows and Stigg's bespoke provisioning experience. In plain english, this means that using our new SFDC integration, Sales teams can easily adjust what features and meters limits should be allowed and applicable for a given customer, and immediately provision and create a new account with the right level of access without ever leaving where they get work done. Example use-cases include provisioning of trial access during a POC, full access when an opportunity is won, and additional product access following contract amendments and renewals.
Stigg’s native integration with Salesforce removes the need for duct-taping and stitching together complex workflows and systems, such as tying together your feature flags with an internal admin panel and your SF account.
Fine-grained entitlements and usage limits are accessible today, directly from SF. Gone are the days of having to maintain and build homegrown workflows to allow that level of flexibility.
See the integration in action below:
Visit our docs to learn more about the integration, or better yet - sign up to Stigg today.
