Tag Archives: process design

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.