Tag Archives: Salesforce

Contact Center Optimization, Operations, System Integration, Workforce Management

5 reasons why you shouldn’t build your own WFM feed

5 reasons why you shouldn’t build your own WFM feed

“WFM often ranks as one the most important applications in the contact centre, as much as 70% of your running costs are staffing related and WFM is crucial to ensure you balance exceptional customer service whilst balancing the costs of that service.”

Aria has been developing WFM data feeds for over 15 years. Even with all our combined experiences across multiple platforms, we know more than any other company how difficult it can be to build these integrations.

All companies aspire to have a single, fully integrated platform for all their business needs — but that’s idealistic, not futuristic. Often, time is the limiting factor for companies adopting a cloud platform. Because of a lack of time, they’re forced to make short-term decisions around point solutions to address the here and now.

Marcela Areiza wrote a great piece of the benefits of an integrated WEM platform which outlines the key drivers and reasons but the one area she doesn’t address is time, or more specifically the lack there of.

The old adage, if it’s not broken don’t fix it, is true here, when we lack the time to remove the burden of technical debt or unpick commitments to technology made under previous incumbents, we continue to focus on the here and now at the expense of our ideals.

But ignore everything stated above as nothing defines us more accurately than Edgar Rice Burroughs disarming simple assessment: “We are, all of us, creatures of habit…”, put more simply, we know what we like and like what we know.

This is often most true whenever I recall my experiences with WFM [Workforce Management] teams and their unquestionable dedication to their WFM platform of choice. I always loved the idea of putting advocates for all the main WFM platforms into a room and listen to them try to convince each other why their platform of choice is the best…it would put any cross-party political debate to shame but unfortunately I suspect the outcome would be no clearer nor any more purposeful, great content non the less.

 

Why is WFM even that important when it comes to adopting the cloud?

For those of us who have never worked in WFM or worked closely to these teams, it will be incredibly difficult to understand why they can’t just use another WFM system.

After a platform to deliver the interactions to the agents, WFM often ranks as one the most important and critical applications in the contact centre, as much as 70% of your contact centre running costs are staffing related and WFM is crucial to ensure you balance exceptional customer service whilst balancing the costs of that service.

The WFM platform is often central, with a multitude of processes and systems feeding in and from it, so simply swapping out the WFM platform isn’t that straight forward as the rest of the processes would fall down around it.

 

Why shouldn’t I just build my own integration and data feed?

For new contact centres adopting the integrated WFM platform removes the need for any form of integration as it’s an integrated suite. For customers wishing to retain the services of the existing WFM system, they have the option to build or buy. Listed below are 5 reasons to not build your own WFM data integration feed.

 

1. The total cost could be up to x10 more than to buy

You generally want to minimize cost whilst maintaining control, this seems like the better route; to build yourself giving you complete ownership it’s not quite that straight forward. The unavoidable truth is that building it yourself has potential to cost you significantly more. Many convince themselves that building in house will be quicker and cheaper, but it’s often difficult to provide an accurate cost of complex software, and often unforeseen problems can and will arise resulting in delays and spiraling costs. Then you’re faced with the tougher question; do you abandon it or continue to battle your way through and risk more cost?

According to Atomic Object: “new systems have a reasonable amount of complexity; the custom solution will cost more than the off-the-shelf solution. In our experience, assuming you hire an experienced external team to build your software, that difference can cost from twice to 20 times more.”

Building your own solution in-house requires you to first build a team to do it. Good software developers don’t come cheap and often (in-house) IT projects are well-known for experiencing major problems and costing far more than the estimated amount.

You must avoid failing into the trap of the perception of a lower cost to build in-house to reduce costs as these projects often lead to corners being cut and a solution that’s not fit-for-purpose. Compare that to a specialized vendor solution which fits your needs ‘out of the box’ and takes on the burden of maintaining your interests as part of their service.

 

2. Inaccurate data could cost you millions annually through staffing inefficiencies

Typical agent salaries can account for  between 60 and 70% of total contact centre costs and even small inaccuracies in your data feed can result in 2-3% staffing inefficiencies which translates into hundreds of thousands or even millions of dollars lost annually.

The cost of inaccurate data is never considered as part of the cost of building your own WFM data feed as you will always start with the flawed assumption that the data, and more importantly your teams view of how the data should be transformed into the format required by the WFM vendor, is not something to be concerned or even factored in, as the goal will always be to create an accurate data feed.

Aria has been building and developing WFM data feeds for over 15 years and even with all our combined experiences across multiple platforms, we know more than any other company how difficult it can be to build these integrations, and that’s starting with a team that has significant experience.

 

3. It could take 12+ months to build

As Donald Rumsfeld famously stated, “there are no knowns. There are things we know that we know. There are known unknowns. That is to say there are things that we now know we don’t know. But there are also unknown unknowns. There are things we do not know we don’t know.”

As much as that might seem like a tongue twister, it’s the unknown unknowns that affect build it yourself projects.

Assumptions are key to the custom development’s business case, and the project’s planning. We often don’t realize them until it’s too late. With over 15 years of building and developing WFM integrations and data feeds across a wide range of platforms, Aria is fortunate enough to have experienced and learnt from all uncovered unknown unknowns and built them into our thinking and design.

With our in-depth knowledge of what it takes to build a WFM integration from nothing, we are confident the build from new will take a team with our history and experience more than 12 months to build and even then it’s likely to suffer from the challenges of inaccurate data as per reason number 2.

 

4. How do you even keep up with the cloud vendor’s rapid pace of change

Vendors like Genesys and Salesforce make changes to their cloud platforms very frequently. For example, Genesys announced  their commitment to ‘Rapid Innovation’ [Press Release].  This is a huge statement of intent in terms of the pace at which they plan to expand and evolve their platform on a weekly basis.

Likewise, Salesforce is a popular CRM with a large market share, that is constantly making updates to their software.

For partners like Aria Solutions, this raises the stakes in terms of our commitment to keep pace with Genesys and Salesforce. Specifically, we need to provide business dexterity for our customers, and exceed Genesys AppFoudry and Salesforce AppExchange standards, by enabling new features for our customers in a timely manner.

Aria’s product is a ‘True’ Cloud platform build using scalable API’s and microservices. Simply translated, we are able to focus much more on the features and functionality of our platform and integration and have significant agility to keep pace with Salesforce seasonal updates and Genesys’ ‘Rapid innovation’.

When building the business case for a new WFM integration in-house you need to also consider this ‘Rapid innovation’ commitment in terms of your on-going technical overhead beyond just building the initially integration, your architecture must be agile enough to adapt and change your approach.

 

5. You have more important priorities to focus your efforts on

For most companies, building a WFM integration will never be your top priority, most likely it won’t even make the top 100 list. Your core business is anything but building and maintaining integrations, but for Aria, this is our core business and is what we have developed our expertise around.

So, the question must be asked at the start of your journey, do you have the time, resources, focus and prioritization to see this through to the end and beyond?

If the answer to any of the questions above is no, then surely the most cost effective and best use of your value resources is to not commit them to complicated project with an unknown effort.

You have more important things to focus on and for Aria Solutions this is a top priority so why take the risk?

This sounds like a long list of ‘known knowns’ that impact most projects that always start off with the best of intentions…. let’s save some money. When in fact it always takes longer and cost more.

Save yourself the effort and simply to get you up and running in a matter of hours with an out of the box solution that will continue to adapt vendor and market changes.

 

CRM/Salesforce

3 Quick Principles of Re-engineering a Process in Salesforce

Designing a process from scratch is already a task and a half for your Salesforce org, but re-engineering a process is even a bigger undertaking when the process has been in use for some time. Many considerations need to be paid towards how to begin re-engineering, how to maintain the design after the solution is built and deployed, and what tools are required to plan its design and execute all this. Recognizing that there are a lot of things to think about, here is a small compilation of ways to tackle some of these questions. These are things that Salesforce solution designers are thinking of when it comes to designing a process to replace another one that just doesn’t fit the bill anymore.

1. Prioritize for value and technical complexity

In my interactive webinar series on how to design a process like a pro, I talked about prioritizing parts of the process to re-engineer based on business values that ranged from revenue generation, to user productivity, to customer experience. While these are important drivers in deciding which parts of a process to re-engineer, the technical effort also needs to be considered because these are the details that give way to an estimate of work involved. Since time and effort are also factors in prioritizing, here are things that we, as a team, discuss, evaluate and estimate effort on, to help prioritize which part of a process to re-engineer.

  1. Consider the existing Salesforce objects involved and the possibility of needing to deprecate or change them to fit the new process.
  2. Review the relationships between Salesforce objects and the possible need to change them.
  3. Consider the number of records that may need to be transformed, and the possibility of leaving them to coexist in the system.
  4. Analyze the existing automation being used given that there is usually a mix of automated processes, flows, triggers, and such, that need to be deprecated, modified, or potentially cannot be changed immediately.
  5. Account for the existing security and access, and the possible need to change them.

2. Demo early, demo often

Much like “save early and save often”, proactively keep tabs on how a re-engineered process is received by users. Don’t wait until it cuts over and is live in production before surveying users how things are going with the newly re-engineered part of the process. A reveal day like this can go awry if you didn’t have a good sense of user acceptance. Since we practice Agile, we demonstrate functionality at the end of each sprint. With sprints being relatively short, users see new releases early and often, as we complete them. Each time we demonstrate functionality, users have an opportunity to point out issues and provide feedback as we walk through functionality. Being able to get feedback from users, on-demand gives us a chance to adjust the solution so that it meets user needs. We consider this to be a pre-emptive quality check before handing the sprint release over for UAT, which is yet another period for users to validate that the changes meet their goals before accepting it in production.

This is not to say we haven’t gone through system testing, sprint demos and UAT with customers, deployed to production, and still had to come back and make adjustments during the support period. We might make changes then or add new improvement ideas to the project backlog, since changes in business and with customers often happen quickly. This is just part of reacting to live situations, find the next best way to work faster, and get more done—practically living and breathing productivity, progress and satisfaction.

3. Traceability, a buzz killer, and absolutely necessary

Certainly, documenting the design of a solution delves deeper than what was talked about in my webinar series, so let’s cut to the chase. Traceability is a bit of a buzz killer. It’s like the heaping pile of clean laundry I haven’t folded and accounted for, but I know eventually, I have to clear it so I don’t buy more socks, impulsively. Traceability is exactly this. It’s a mission to reduce, reuse and recycle, so that you have less technical debt and conflicting processes clobbering each other. Plus, if you’re working in a team all the time like we are, adding traceability helps everyone keep up with changes, decisions, the general understanding of how the solution functions and which user story is fulfilled.

Now, how is the hard part. Currently, my team writes a short design document for each user story we’ve identified. Each design document has two important things for traceability: 

  • A list of pre-existing API names of each declarative and programmatic item that will be modified because we’re recycling it into something else, enhanced, and re-used. 
  • A list of objects that will be created, modified, and re-used. 

These design documents are then related back to the user stories that we’ve released for each sprint. By the time the project is complete, every user story has at least one design document related to it pertaining to what we built and how it functions for users. To take it further, we can search our documents by the project, by the object, by the API name, almost any keyword, to find what we need months later. We can re-establish our understanding of the designed solution and continue with the next stages of transformation and optimization.

Design principles we like

Between my team of Salesforce Consultants and Developers, each group has a noticeably favorite approach in design principles that they use over and over again.

The developers favor complete user stories with clear acceptance criteria. Whenever these were not clear, they felt that they could not design something that would represent what users needed, ultimately lowering the value of the solution. As for the consultants, who concentrate in declarative work and business analysis, they favor the end-to-end flow of process carrying out the expected outcome. For me, my attention over the years have gravitated a lot towards data normalization, and security and access. Even though I am a process engineer at heart, well-designed data and security have proven to be a key factor to the success of re-engineering a process.

Bringing SDLC back! 

Life is a lot different than it was. Salesforce has always been a DIY platform that made it easy for admins and developers to build on-demand. The last 2 years have seen a widespread trend on architecting solutions. Salesforce solution designers are pausing their thoughts to build on-demand because they are concerned about technical debt, extensive org administration and support, and just simply being able to scale for growth. Traditional practices of change management and quality assurance have also made their way back into the fold where solutions are deployed from a Developer Sandbox, to a Full Sandbox and then finally to the production org. I am very excited to see so many great software design principles are being echoed in the Salesforce community. A lot of care is being given to designing processes and solutions holistically in Salesforce. We plan to continue being a part of this movement.

How Aria Solutions Can Help

Are you designing a process and have questions about how to tackle it? Download our design template to start planning out a process solution.

Our team is also here to help! Contact us today if you’d like to continue the conversation.  

Agent Efficiency, CRM/Salesforce, System Integration

Building a Fully-Integrated Contact Center with Amazon Connect and Salesforce

When AWS launched the Amazon Connect cloud-based contact center service, our breath was taken away by the power and the flexibility – making us quickly become one of the first APN partners and take part in creating new add-on functionality and services.

Having experience building customer engagement functionality in Salesforce that only supports digital channels, our team realized that Amazon Connect and its voice-based channel was a natural fit. So, this was the obvious first place for Aria to invest in to provide customers with a fully-integrated contact center.

Bridging the silos with pre-built components

No one wants to have their technology run in silos. By integrating both cloud-based solutions, organizations can:

  • Improve customer experiences by properly managing customer interactions across voice and digital channels
  • Improve employee productivity by automating tasks and reducing the number of screens they must use to handle customer interactions
  • Gain full visibility of how well the contact center is meeting customer demand

To make this happen fast with less effort and lower risk, Aria built two options:

1.  Free toolkit to try things out on your own

This is an advanced adapter that’s using Salesforce’s Open CTI, which brings Amazon’s Contact Control Panel right into Salesforce. The toolkit offers out-of-the-box integration between Salesforce and Amazon Connect, which is built on industry best practices. Agents can receive and control the calls and see customer information right within Salesforce – the same place where they handle digital channels.

As part of this integration, the toolkit migrates Amazon Connect call data into Salesforce, for all interaction data to reside in one place. Providing contact center managers with a clear view of their operations across all channels.

Other AWS applications that are often used in the contact center, such as Lex bot data, and transcriptions with Amazon Transcribe, are also made available right within Salesforce.

Not only does it provide some great features out-of-the-box, it’s also meant to be customizable and extensible, by giving you the rights to copy and modify almost all pieces of code to adjust the functionality to your own needs.

2.  More advanced, supported integration through Legato

Another option to consider is Aria’s Legato, which includes all the same functionality as the free toolkit plus a customizable softphone. It is a packaged and fully supported product that includes automatic upgrades and will soon be available on the Salesforce AppExchange.

This option lets organizations skip the internal development stage and go straight to a supported product – should that be the desired path.

Making your customer engagement center even more advanced

Aria has over 20 years of contact center experience and a depth of knowledge on how everything interconnects as a single solution.

If you want to add more functionality to improve customer and employee engagement in an efficient manner, here are some service options:

  • Setup of Amazon Connect
  • Voice and digital bots with Lex
  • Integration of industry-leading CRM and WFM tools
  • Advanced functionality provided by Amazon Connect partners, such as advanced sentiment analysis, dynamic phone numbers, fraud detection, and in-session SMS

To learn more about these options and what’s possible with Amazon Connect contact us to talk to our experts!

CRM/Salesforce, Customer Journeys

Why Tech Start-Ups Should Start Their Customer Journeys Early

There are more and more start-ups in the tech industry every year. They have become an integral part of our business landscape, driving innovation and entrepreneurship.

All of these start-ups begin with a vision and a few individuals who want to bring it to life. Over time, they will find investors to back them up and the people to transform it into a product. Everyone works hard for the success of the newly founded company. But building this success is difficult, and developing a product to a point where it is marketable requires a lot of hard work and fortitude.

At the beginning, the product is the one and only focus. It’s about developing a platform for the business idea to come alive and building the artifact (product, app, etc.) that customers will want to use or buy because without the product, there is no business.

Later, once the product has matured and larger audiences start using it, the business aspects need to be embedded into the process. Customers need to be managed, sales handled, licensing applied, and even more importantly, the moment the first customers are on board (while the product is still in an infant stage), customer service is crucial to keep the users engaged.

Today, success is not only defined by a vision or product itself, but also by timing and the execution of the company’s ability to attract users. This becomes even more crucial once others start to copy your business model.

However, customer service does not just stand for troubleshooting anymore. These days, customer engagement represents a journey, which starts with:

1. Attracting a consumer to your product (marketing)

2. Followed by collecting information about the product usage (analytics)

3. Then supporting the consumer through common early stage issues (support)

4. To finally – building a brand allegiance that leads to future purchases (overall business)

It is no secret that great products fail due to poor execution of those steps.

But how can start-ups succeed in those areas without devoting too many resources? Last thing anyone wants is to jeopardize the execution of the product itself.

Well, I believe that it is important to pay attention to those business aspects right from the beginning. The product vision needs to be combined with the customer engagement vision.

The Power of CRM in Building Customer Journeys

Customer Relationship Management (CRM) is a key aspect of the customer journey and should be done using the right tools instead of improvisation. At some point, the Excel worksheets and emails won’t cut it anymore and then it will be even more difficult to migrate the loosely collected data to a proper CRM solution.

Since we are dealing with a start-ups, cost is obviously an important factor. Today’s CRM cloud solutions with their different tiers and subscription models help mitigate large financial commitments.

Investing into a CRM tool as soon as the product gets released is a logical choice. However, there are advantages to signing up at an even earlier time. If the product supports connectivity features that allow for an Internet of Things (IoT) business use case, there is an option to collect valuable information about the device and its usage.

The collected data can be very valuable when making product roadmap decisions or for marketing purposes. In the situation of a support service request, having access to the device information can be crucial in locating a root cause and solving the problem.

Of course, there are many ways to implement such a solution. Plus, there are many platforms that offer great services. Salesforce is one of the top cloud CRM companies, and it is named a leader for the ninth consecutive year in the Gartner Magic Quadrant in the CRM space. This platform should definitely be on the list of vendors to evaluate.

Besides being a very feature-rich CRM, what is often overlooked is the development platform Salesforce is built on, including its large set of APIs and tools to integrate with (Standard SOAP/REST APIs, custom SOAP/REST APIs using Apex, Javascript toolkits, Heroku, etc.). A great number of options are offered for integrating your product or other systems with your customer data.

On the business side, everything is there and ready when you need it. Whether it is marketing, sales, customer service, billing… As long as you maintain your customer data on the platform, you can plug in those functions and use them whenever you are ready. And with the per-user payment model, the cost will only grow when your company does.

Using a CRM application early allows you to start building customer journeys right when your product hits the market. Using a CRM may not guarantee the success of your innovation, but it significantly decreases your chances of failure. Plus, it can set you up for a much quicker transition from a start-up to an established, successful company.

If you require assistance in optimizing Salesforce, enabling omnichannel, or integrating it to various business systems – see us at Dreamforce 2017 or contact us here.

 

CRM/Salesforce

Salesforce Data Loads: Using Feature Switches to Manage Apex Triggers

Dealing with larger data loads in Salesforce often leads to the task of turning off automations, such as validation rules, workflows or process builder flows. This can be done directly in the Production Org, or even better, by using tools such as the Ben Edward’s Salesforce Switch.

Although the tool also offers to turn off triggers, it isn’t quite that simple. That is because any changes to triggers can only be done through code deployments, and those require the unit tests to succeed for the changes to take effect. However, some unit tests may depend on other triggers or automations to be active, which can make this a very complex and time-consuming undertaking.

Turning Apex Triggers On and Off with Feature Switches

A possible solution to this dilemma can be the implementation of feature switches. Feature switches are a simple concept of turning features on and off. In traditional software development, especially in cloud applications, this practice is used for controlled feature deployments, A/B testing, and more. In Salesforce, this principal can be used to quickly turn off all your trigger functionality to run data uploads – without the risk of trigger errors. This also improves the speed of your data upload.

How to Implement Feature Switches For Data Loads in Salesforce

Feature switches are based on a configuration object. This can either be done by using Custom Metadata Types or Custom Settings.

Custom Settings have the advantage that they allow for hierarchical overrides of the global settings. Depending on what use cases the feature switches are needed for, this might be a desirable option. Each feature switch would be represented as a checkbox field in the Custom Setting. The downside to this approach is that any new feature switch requires the Custom Settings metadata to change, which is not ideal.

In Salesforce, I would consider feature switches to typically be of a global scope only. So, my personal preference is to work with Custom Metadata Types. Each feature switch is represented as a new record in the Metadata Type, which does not require changing the actual type itself as it would for Custom Settings. Those records can also be migrated as part of a metadata deployment.

Now, Let’s See What Such an Implementation Could Look Like

1. Creating custom metadata type

We start by defining the Custom Metadata Type. Create a Custom Metadata Type called “Feature Switch”. The type will need a new custom field.

Creating Custom Metadata Type - Salesforce Data Loads

2. Creating custom field on metadata type

From a development perspective, it will be easier to consider an exceptional case for when the feature is turned off, so I will create the custom field type “checkbox” and label it “Turned Off”. Creating Custom Field on Metadata Type - Salesforce Data Loads

3. Adding a record to turn off triggers

Now, let’s add a record to turn off triggers, by clicking the “Manage Records” button or link and select “New”. I named the record “All Triggers”, used the default API name, and left the “Turned Off” checkbox unselected. The image below shows the list of records for the feature switches including the record that was just created. Note that I created a new view to include the custom field.

List View of All Trigger Feature Switches

4. Creating an Apex class 

Next, create an Apex class that can be used elsewhere in the code to conveniently retrieve the state of a feature switch. The class will contain a single function to ask if a switch is turned off.

In our environment, feature switches are commonly used, so it makes sense to load them statically. However, using lazy loading is also a good option here. Making the SWITCH_MAP visible for unit tests decouples the manager from the actual configuration and allows the unit tests to inject the values they need for testing. In this case, changing the value of feature switches will not impact the success of an Apex unit test run.

5. Querying feature switch in the trigger

Last, the feature switch needs to be queried in the trigger. This can be as simple as introducing an early return statement in the code. If a central trigger dispatch pattern is used, the All Triggers feature switch requires the following snippet to be introduced in a single class only. However, if the pattern isn’t used, simply add the snippet to any trigger deployed in the Org.

6.  Adding a unit test for the manager class

All that is left to do is to add a unit test for the manager class to ensure the code coverage requirements are fulfilled and you are good to go.

That’s all! Now, when another data load is about to happen, all that needs to be done to turn off triggers is to set the “Turned Off” flag for the “All Trigger” record to checked and you are ready to go.

There is no deployment or code hack necessary anymore. We used this pattern successfully during large projects with numerous data loads. It has saved us a lot of time and stress, as well as allowed us to focus on the data migration tasks, instead of getting distracted with environmental prerequisites.

Using Feature Switches for Integration Classes

Using the feature switches for all triggers is only one use case. Feature switches are also extremely useful for any integration classes using web requests to third-party services.

For example, if the third-party service is currently experiencing an outage, the feature switch can be used to activate a routine that deals with this situation. This allows your organization to inform users of the current outage. Plus, it will give the third-party service time to recover without penetrating the system with additional requests.

If there are triggers that should run during data loads, I would just rename the trigger to “Data Load Sensitive” or similar.

Are you looking for help with Salesforce implementation? Let’s meet at Dreamforce 2017, or contact us to discuss over the phone.

Agent Efficiency, CRM/Salesforce, System Integration

Softphones – Finding the Last Piece for Your Salesforce Service Cloud Puzzle

Many companies are using Salesforce Service Cloud with Omni to engage with customers and handle their service requests. With Service Cloud, you can connect with your customers through social media channels, email, and chat.  Setting up those features paints a great picture to your service team.

However, the picture is not complete because voice still remains the most important way for many businesses to communicate with their customers. Consequently, it is crucial to enable your agents to handle phone calls through the Service Cloud Console as well. Only then will the full picture of the customer journey be completed.

But Integrating the Voice Channel Can Be Tricky!

Salesforce offers voice capabilities through third party vendors that are using their Open CTI toolkit. As a customer, that means you are free to choose from a wide variety of vendors and products. Integrating the voice channel into Salesforce also means that there will be a second routing engine active, which is evidently not aware of Salesforce’s Omni routing engine, and vice versa.

This also extends to the handling of agent capacity and can make the management of your workforce more complicated. Agents will have to deal with two separate interfaces to select their presence status and handle the interactions, which introduces more complexity to their daily work and can lead to more mistakes.

Now, What Can Be Done About This?

One option could be to separate the voice channel from the other channels and have a group of agents (or multiple groups) dealing with phone calls exclusively. This will get you out of the Workforce Management and reporting nightmare, where you can use the reporting capabilities of the voice platform for your voice agents and Salesforce’s reporting capabilities for all other media types.

However, an increasing number of agents do not solely deal with phone calls anymore, but either operate in a blended environment handling multiple media types, or they work on back office tasks during times of low call volumes.

All of this requires a deep integration of the voice channel into Salesforce Omni in order to give your agents, and therefore your organization, the most powerful platform to build on the processes and customer service strategies.

While the softphone needs to fulfill your business needs first and foremost, I would recommend adding the following questions to your checklist when evaluating Open CTI vendors:

  • Does the softphone support both Open CTI frameworks, ̶  the classic and the lightning version?
    Although both integrations require the Open CTI framework, there are actually two different libraries available today. The softphone must be able to utilize the correct library for each of the user interfaces.
  • Does the softphone integrate with Omni’s or Live Agent’s user presence?
    Ideally, the agent should really only have one presence control, but if there are two of them, do they at least synchronize their states, so that one routing agent can be influenced by the other?
  • Does it support screen pop configurations beyond the simple contact or case search?
    Depending on your framework, you may have more things you want to look up based on IVR choices, or create and open multiple records. You may also want different screen pops at different times of the call (i.e. ringing, answered, or released). 
  • Does it properly record the phone call in Salesforce, with the correct records (case and contact/account) associated to it? 
  • Does the softphone provide an API for additional integration?
    An API would allow for the most flexible integration. Depending on capabilities, you might be able to create very sophisticated screen pop behaviors, provide softphone controls from Salesforce record pages, and it can be used to couple your voice channel very tightly with Salesforce Omni-Channel. 

Based on your needs, the perfect puzzle piece to complete your customer service picture may seem elusive. Nonetheless, looking at the above mentioned criteria very closely will help you to find a piece that will be a very good fit. As a result, your contact center agents will see a seamless workflow and your customers will have a better service experience – leading to the customer engagement goals that your business set out to achieve.