Salesforce CRM for a global software engineering company

Solution

Discovery phase

The project team included a product owner, who also acted as a project manager and lead business analyst, a tech lead who advised on the use and implementation of Salesforce in line with our needs, a business analyst describing requirements, and developers. During the discovery phase, our PO together with the main stakeholders, i.e., the business development department and the support team administering the system and processing requests, identified the main requirements and pain points to address within the release scope.

Since several internal corporate systems needed to be integrated with the Salesforce solution, our PO also collaborated with BI, internal automation, and support teams’ representatives, as well as SharePoint owners.

As a result, we formed the feature scope, evaluated it, broke it down into four mission-critical stages, and put together a development plan:

1. Re-evaluate and optimize our existing workflows while keeping them aligned with our legacy data model to ensure backward compatibility for hassle-free migration from MS Dynamics.
2. Implement Salesforce functionality to support all key working scenarios, adjusting out-of-the-box functionality to our needs.
3. Integrate Salesforce with internal corporate platforms and set up data exchange.
4. Migrate data from Microsoft Dynamics to Salesforce, ensuring minimum solution downtime.

On the project, we practiced Scrum with one-week sprints to promptly make changes based on discussions with stakeholders. We used all standard ceremonies, such as daily standups, sprint reviews, plannings, retrospectives, and backlog reviews, and conducted demos for stakeholders every two weeks.

Revising the leads workflow

Previously, we had no clear differentiation between the Leads and Opportunities entities, so leads would sometimes be converted to opportunities right before the contracting stage. To make customer onboarding and reporting more transparent, we decided to revise the overall procedure. We reworked the process of creating leads and their allocation and assignment to responsible persons by introducing a distinct difference between a Lead and an Opportunity. 

According to the new paradigm, leads act as important entities at the early stage to uncover possible existing contact points with a customer and determine who was the responsible person. If there aren’t any, we define whether the request should be processed further. From the lead processing perspective, this means that as soon as the lead has arrived, reviewed, and qualified, it should be converted to the opportunity and assigned to a sales representative. This way, lead lifetime is minimized to cover only initial lead qualification activities, with all further processing and communication happening in the opportunity and related entities. Requests received from existing clients are registered as new opportunities.

To make the transition to the new workflow smoother, we asked all users working with leads to follow the new process in the legacy CRM one month before we introduced the Salesforce solution. We made minor adjustments to existing business rules in MS Dynamics that were essential for the transition to the new process. Thanks to the early adaptation period, we minimized the number of post-transition issues.

Functionality implementation

Itransition implemented a new CRM solution on top of the Salesforce platform and set up all necessary workflows. We were able to retain and transfer our established sales processes and modify and enhance them when needed. Our experts managed to realize the majority of features by employing solely Salesforce built-in functionality, thus cutting down on the number of workarounds and custom solutions significantly. Occasionally, we customized the functionality to our needs using the Apex language and add-ons.

The main Salesforce CRM modules our team implemented include:

• Home – aggregating key information requiring users’ attention (events, tasks, recent records, chatter, overdue stages)
• Accounts – managing all client information and related projects
• Contacts – storing contact information
• Leads – creating and managing leads
• Opportunities – creating and managing opportunities
• Tasks – creating to-do lists related to accounts, contacts, and opportunities
• Calendar – accessing all events and meetings that were registered in Salesforce
• Dashboards – accessing analytics and insights
• Reports – creating complex reports with Salesforce CRM data
• Files – storing all the files related to leads and opportunities that users have uploaded directly to Salesforce, located in Sharepoint as the main storage for corporate documentation
• Chatter – communicating with other Itransition Salesforce CRM users
• Marks – participating in evaluation between sales professionals and opportunity coordinators
• Relationship Surveys – logging and storing results of client satisfaction surveys

Adapting default functionality to internal processes

Even though we used Salesforce’s out-of-the-box features as much as possible, some of them still needed to be configured, adapted, and/or customized in line with our established processes. We also elaborated on how we can apply standard Salesforce entities to our processes and which custom entities should be added. 

For example, our process didn’t involve Quotes, Products, and other associated entities due to the highly custom offers we prepare for our clients, we introduced the Additional Revenue entity. It enabled us to register upselling related to one opportunity in a particular project without creating a new opportunity, as well as keep track of the upselling history. 

Another example of a custom entity is Marks – internal questionnaires our presales and sales managers use to evaluate the quality of services provided during opportunity processing. Previously, lead qualification was a completely manual process, performed by different people. We automated the lead quality determination flow based on defined rules, taking into account the estimated amount of transactions, the company size, and contact information, thus making the process more transparent and eliminating human error.

We also reconsidered the procedure of working with duplicates in the new system. The revised process applies deduplication rules to all key system entities (lead, opportunity, account, contact) that potentially could have a duplicate, on an ongoing basis, thus significantly improving data transparency. For example, while creating a lead, the system:

• notifies users who have access to the lead about a duplicate (including the account and contact entities) and suggests creating an opportunity.
• if a user doesn’t have access to the duplicate lead, the system displays a flag, warning about a duplicate and not allowing users to convert the lead into an opportunity. This forces the user to go to the step where the presales supervisor, responsible for lead distribution, makes sure that it is indeed a new lead (false positive) or that such an opportunity/account already exists in the system.

By default, Salesforce does not notify users about new Chatter posts without direct mentions, but our CRM end-users are accustomed to working with emails and want to stay in the loop. Therefore, we adapted the standard Salesforce functionality and introduced mentions of specific users in Chatter posts, so these users can get instant mail notifications with the details of a related opportunity (opportunity ID and name, account name, and primary person responsible).

We also considered the mobile CRM app to be a great addition as it would provide on-the-go access to the information and features. People responsible for assigning sales managers to incoming requests would often be out of the office or in meetings, so it would be way more convenient for them to have a mobile CRM version. For this purpose, our team tailored the mobile app to our processes. 

Compared to the web version, the mobile app has limited lead conversion capabilities. So to let users assign converted leads to sales representatives, check for duplicates, and provide extra setting options for the opportunity, we introduced our custom conversion algorithm from lead to opportunity to the mobile version. Furthermore, we implemented custom CRM screens utilizing Salesforce component blueprints, so the UI looks the same on mobile and web, thus ensuring a seamless user experience.

Other than that, we employed the native Salesforce to Outlook addon to sync emails and calendars right in the CRM. Last but not least, we defined access rights and responsibility areas when processing an opportunity by setting up profiles and assigning user roles and permissions.

Integrations

CRM is an entry point for the customer journey within Itransition, so it needed to be fully connected with our IT ecosystem. Therefore, we integrated it with the following platforms:

• SharePoint

• SharePoint CRM materials for creating structured SharePoint folders following Lead and Opportunity creation and access rights distribution
• SharePoint files transfer and display for rendering a document tree with SharePoint contents and enabling automatic retrieval and transfer of files attached in Chatter posts, as well as attachments from emails (via the Outlook addon) to SharePoint

• Jira

• Automatic creation of tickets for new Leads/Opportunities, adding users, and distributing access rights
• Worklog functionality to keep track of Lead/Opportunity processing costs and allocate budget accordingly
• Websites contact and chat forms for automated creation of leads
• Referral forms for the automatic creation of leads submitted by Itransition employees who don't have access to CRM or leads within CRM
• BI system for sending CRM data to our internal BI tool to get valuable insights
• OpenAI for retrieving general company facts based on the initial inquiry and populating lead information using ChatGPT
• Exchange Rates API for retrieving and storing up-to-date exchange rates with rates recalculated in all opportunities once a day based on actual values
• HubSpot (a CRM system of our subsidiary) for managing expectations, evaluating efficiency, and generating analytic insights for a group of companies

SharePoint Online as a document library for Salesforce

Storing, handling, and sharing documents in different formats was essential for our sales operations. Previously, MS Dynamics had on-premise document storage (SharePoint libraries) which provided limited collaboration opportunities but was inconvenient. We decided to retire it and moved our SharePoint and document management processes to the cloud. We designed and implemented Salesforce-SharePoint integration using SharePoint Online capabilities and got the following feature set:

• Creation of a necessary folder structure for operational sales activities and long-term storage of related documents for each lead and opportunity
• Propagation of access permissions from a particular case in CRM to the designated folder in SharePoint Online according to the user’s role
• Sharing documents with other actors (SMEs, supervisors, clients, etc.) involved in request processing without giving them access to CRM
• Concurrent online editing, commenting, and reviewing of the same document by multiple authors simultaneously

We also preserved seamless navigation from CRM to document storage by using built-in SSO against the corporate Active Directory. We needed to retain this functionality and decided to enable automatic synchronization of attachments from CRM to SharePoint. This way all case-related documents would be consistently available in the same location, while end users wouldn’t have to switch to another system to search for project-specific documentation and could upload files and collaborate on documents in the CRM.

The Salesforce CRM solution comes with an in-built document management module and can be integrated with third-party ECM/DMS. However, the system’s out-of-the-box capabilities didn’t fully support all possible document-handling scenarios, such as, for example, a very specific structure of documents we had to follow. We also needed concurrent online collaborative editing over the same set of case-related documents and wanted to be able to involve any number of participants from within and outside the organization while still preserving fine-grained access control. Finally, we needed to preserve the existing document library from our legacy CRM solution.

Thus, our team created a solution that would at no extra licensing costs allow us to fully support our CRM document flow without sacrificing default platform functionality. The Files Connect feature facilitates the integration with SharePoint and access to documents at a target Site/Site Collection or Library. However, it always starts with a root folder, which means that:

1. Even with a small number of cases, the library will likely be hard to navigate
2. Any actor of any case will have access to folders of other cases unless individual permissions are set for each folder on a per-case basis
3. The propagation of folder permissions from Salesforce to SharePoint isn’t supported so far

Having thousands of folders, we considered the inability to narrow the view down to a case-specific folder as a crucial shortage. Based on the gap analysis, we decided that we could get the desired document management features by reintegrating our existing solution with Salesforce without costly third-party components from AppExchange. Since the existing structure and document library’s behavior have already withstood the test of time and didn’t have to be changed, we decided to keep it as is and add a new two-way attachments synchronization feature.

We performed the following steps:

• Adjusted the existing integration to support callbacks from Salesforce for new Leads, Opportunities, and Team Member changes
• Adjusted Files Connect’s default functionality with a custom component to show the folder structure relevant to a specific Lead or Opportunity
• Introduced a custom endpoint for uploading files from Salesforce to SharePoint Online target folder
• Automated the uploading of Salesforce’s emails and Chatter attachments to SharePoint using a new endpoint

This way, we managed to transfer our document library from the existing CRM to Salesforce with minimal code modifications and no data changes. As a result of SharePoint Salesforce integration, we managed to:

• Enhance the interface for document management within Salesforce with segregated visibility and an orderly display of assets related to a specific case (Lead or Opportunity)
• Leverage SharePoint's advanced access control, online collaboration, and document sharing capabilities
• Reuse the established library structure and work processes in a new CRM
• Automatically synchronize Salesforce attachments to the document library
• Enable seamless navigation between Salesforce and SharePoint with SSO against the corporate Active Directory

Besides, by leveraging the Outlook addon, we ensured that files attached to emails from Outlook appeared directly in SharePoint. Last but not least, thanks to SharePoint, documents are now available outside the CRM, which, by our estimation, reduces the number of Salesforce licenses we need by half.

Contact & referral forms

Previously, all requests sent through the contact form on our websites triggered the creation of an email, which was then reviewed by the responsible party from the business development department and redirected to a dedicated email of an assigned sales manager. This action initiated the automatic creation of a lead in MS Dynamics with the assignment of this particular sales manager to lead processing. According to the revised process, everything is submitted directly to the CRM and then processed, i.e., lead qualification, review, deduplication, assignment, and so on. Since the revision procedure and all processing occurring in the CRM, less info gets lost as emails could be sometimes overlooked or forgotten. Original emails are also automatically stored in SharePoint. Our team put a lot of effort into adapting contact, referral, and chat forms on our websites to make work with the new solution seamless. For this, we employed Power Automate to sort out info emails with incoming requests and structure data to the necessary format to then submit it to the CRM.

Apart from the manual conversion of a lead into an opportunity, we automated this process when the lead was submitted through our custom referral form. The system checks the lead on duplicates and determines who has submitted this lead:

• If this employee has access to the CRM, the lead is automatically converted to an opportunity, while this person is assigned to this opportunity and becomes the owner of all related entities
• If the person does not have access to the CRM, this lead has to be verified by the Supervisor

Migration

While planning the migration flow, we decided not to concurrently support two systems during the transition period as this would confuse the users and complicate and prolong the migration process, making it more costly. Besides, all conversion KPIs impact the company’s internal forecasts and sales statistics, which was another reason why we didn’t want to split the release into many parts. Instead, before the migration, we introduced a month-long transition period, so that people would use MS Dynamics according to the new revised paradigm and get used to it. This approach allowed us to make the migration a one-time event.

We elaborated migration rules at the design stage to retain consistency and ensure the new data model stays compatible with the legacy model in order not to complicate the migration. Before migrating to the production environment, we performed a test migration of the most recent data to the UAT environment and had the test group evaluate the quality of the migrated data as an additional sanity check. We employed the Pentaho Data Integration tool, an open-source ETL tool automating data extraction from the old system, transformations to map the data to a new system, and loading data to the new system.

One month before transitioning to the new CRM, we set up the production environment and tested all integrations with external systems. On the migration day, we switched MS Dynamics to read-only mode for a limited time to serve as a backup, the new CRM started receiving new leads, and the migration process was initiated.

This is how we performed data migration step-by-step:

1. Analyzed all entities for migrations (leads, accounts, contacts, opportunities. etc.) on data quality and identified critical issues that had to be solved
2. Performed data clean-up. Apart from manual data cleansing, we elaborated on data transformation scripts and defined rules for solving data issues (e.g. some info was missing and had to be parsed from other fields) to ensure additional data clean-up during migration
3. Created mappings for all migrated entities 
4. Initiated the migration process. The sequence of CRM entities migration was determined as per interdependencies between the entities:
   • Accounts and contacts were migrated to the system first, followed by opportunities and then leads linked to each other. Deduplication rules were applied.
   • Other related entities such as opportunity team members, additional revenues, marks, and so on were migrated
5. Granted users access to the new system

In total, the migration of all data took less than 12 hours, causing minimal disruption for end users. We migrated around 30,000 leads, 10,000 opportunities, and 7,000 accounts and contacts each.

Testing & feedback

We gradually released the system to the UAT environment, usually at the end of a sprint or uponfinishing a functioning module. We granted access to the system for a trial group halfway through the development phase to let them get used to the system and provide feedback at an early stage. We also tested receiving production leads on the UAT environment for one month. The test group included frequent users, such as supervisors, sales managers, presales coordinators, and production representatives. All questions, answers, suggestions, and comments were collected and addressed in a dedicated MS Teams channel.

We delivered the system one month before the release date, all at once. It was fully functional and configured to receive leads from the production environment. We had a testing period to check the automated creation of new leads and make sure the system withstands the varying load. We also carried out performance testing of integrations according to OWASP.

Upon releasing the CRM to the production environment, we collected feedback from all CRM users, giving them access to a dedicated Jira board where they could submit tickets. Alternatively, they could also create requests to our Service Desk, an L1 support department that processes basic requests and collects requests from users. Together with stakeholders, our PO prioritizes all requests into high, medium, and low, thus forming the feature scope for the next releases.

User adoption & training

To ensure the smooth adoption of the new system, we carried out several demo sessions for all frequent CRM users. During these sessions, our PO underlined the main differences between the legacy and new CRM, described the main workflows in detail while focusing on the newly introduced rules, highlighted changes, and addressed all possible ambiguities.

Apart from that, we conducted separate Q&A sessions with end users to help them understand what to expect from the new system. We also created a dedicated FAQ page and listed there links to videos with key functionality overviews. Finally, we put together an extensive CRM user manual and gathered feedback from CRM end users, making sure the content was clear and accessible. The manual covers such topics as:

• Quick answers to hot questions
• Salesforce CRM basics and lifehacks
• Features overview
• Leads and Opportunities – submitting and processing new requests
• Efficiently displaying data
• Creating and managing reports
• CRM personalization