When accepting ownership of any technology project, an IT office typically receives from business requestors only a set of vague requirements and timeline.
Then, the IT office usually is responsible for detailing requirements, and from there makes a “build or buy” decision.
In other words, IT typically takes on the responsibility to make the best decision on how to bring a technical solution to life, including whether the business would benefit most from building an in-house solution or rather the better path is to license existing technology.
Consent management technology decisions are no exception. However, given the complexity and end-to-end nature of consent management platform requirements, IT teams will find it useful to keep in mind these three considerations when making that first, all-important build/buy decision.
Consent management is an end-to-end process
A consent management platform goes far beyond just recording when a customer unsubscribes from marketing. Rather, consent management is an end-to-end process that starts with the customer and continues through a complex path that navigates multiple systems, stakeholders, and uses. A build-buy decision should take into consideration all steps in the comprehensive process.
Interfaces require multiple types of resources to build
A consent management platform starts with a compliant, appealing, and often individualized customer interface through which the customer can learn about their options, give their consents, express any preferences, and feel good about the experience. Not only does building this sort of interface require web developers, web designers/artists, and customer experience professionals, but since customers frequently interact with a company in multiple ways (and expect a consistent experience across devices), building a customer interface will require developers, copy writers, designers, artists, and customer experience pros with specialized expertise in apps and mobile devices as well as websites. Add into the mix security, legal, and privacy skills needs, and an IT office. This means that any buy-build calculation will need to include customer experience development efforts.
Integration, integration, integration
As an end-to-end solution, a consent management platform will need to hook into multiple systems and applications. First, as a source of truth for consents and preferences, the consent management system will need to provide consent/preference information to all systems involved in data uses/activities (so, all systems with personal data except pass-through systems). Second, as different systems and applications obtain current information about the data itself or data consent/preferences related to that data, those systems must be able to communicate with the source of truth consent/preference system. An IT organization developing its own consent management platform will need the people and development cycles to enable two-way communication across a wide range of different systems and programming languages. Security will need to get involved to help ensure the right security in transit (and at rest). Together, IT will need to find, organize, and manage a wide range of technical experts over time-consuming development cycles. On the other hand, a vendor-provided consent management platform typically has built-in APIs for common interfaces and expertise to assist other integrations which as the potential to reduce resources, time, and cost.
Compliance is hard
If consent management were easy to do well, it is likely that IT organizations would never even have to be involved. However, the complexity and criticality of consent management done right drives most companies to technology for help. Building the right technology assistance, though, is as complicated as the need. Building in that complexity takes time, budget, and expertise.
Multiple rules and documentation needs
Especially in a multi-jurisdictional world, compliance with consent requirements is difficult. Each jurisdiction has its own unique sets of rules, and sometimes even within a single jurisdiction different rules can apply according to data uses, data types, and other factors. Overlay this complexity with the need to maintain accurate records over time about what the user saw and agreed to during the consent experience and multiply that over the number of customers making (or not making) choices and the number of choices and preferences the company makes available. An IT organization that makes the decision to build its own homegrown solution will have to plan for not only the complexity of the ecosystem, but also the complexity of the decisions and legacy documentation needed to demonstrate compliance on all fronts. A vendor-provided solution will have templates and platform structures already thought out and available across multiple jurisdictions and use cases. This can save enormous amounts of legal costs and technical engineering and design time.
Reporting is critical
Related to the need to store consent experience as well as the consent itself, reporting is critical from both a compliance and practical perspective. Regulators will ask for documentation in case of an inquiry or investigation. The litigation team will ask for documentation in case of a legal matter. Also, a savvy privacy compliance function will want documentation to review accurate application of consents and preferences, and to address complaints that might come into the privacy in-box. In addition, however, marketing departments will find it useful to identify campaigns that resonate (or offend), calculate marketing spend Return On Investment (ROI), and better tailor their programs. Other stakeholders, like customer experience professionals, will benefit from similar information about customers and their wishes.
In other words, good, customizable reporting is not only a must-have in service of compliance, but it is also necessary for other groups so that they can improve their activities, identify, and prevent issues, and align with corporate strategy based on real data. Though organizations often overlook the need for robust reporting initially, they face the need to build it eventually. Good reporting capabilities take time and budget to build, and most ready-made consent management platforms include that functionality for no additional cost.
Consent management is not a one-and-done event
An organization that builds its own consent management solution will also need to factor in future, sometimes significant, costs that go far beyond pure development. Any sound buy-build calculation will need to consider these additional future costs.
Implementation takes training and support
Any complete cost calculation must include implementation costs, of which training and user support costs are a part. Users, which in the case of consent management platforms may include a wide range of stakeholders, must learn to use and understand the system. Then, as individuals change roles, leave the company, and hire into the company, those new users (or users with different responsibilities) also must go through training. Moreover, even after training, some users will require support, from logging in to effectively using the tool and everything in between. This translates to an ongoing need for technical and procedural support. An IT organization making a build-buy decision will have to consider these costs, which often the consent management platform vendor will provide at no additional cost or a small incremental cost.
The one constant is change
One fact that an IT organization can predict with certainty is that things will change over time. Laws change. Business requirements and use cases change. Security risks and controls change. Systems change. This means that any in-house system also needs to change. An IT organization making a build-buy decision will need to account for maintenance costs over time. A purchased solution typically consistently makes updates to adjust for legal, security, and other changes. These vendor platforms also tend to continue to add enhancements that improve the user experience, functionality, and sophistication.
Summary
A consent management project has the potential to drive not only a reduction in compliance risk, but also an increase in efficiency, customer satisfaction and engagement, and revenue. Once an organization has determined the value of implementing a consent management technology solution, any responsible IT organization will do its diligence to determine whether it makes better use of company resources to build that solution, or to buy it. Given the complexity and evolution of consent management, the build-buy decision will want to consider factors that may not apply to other areas. These less apparent but critical factors include the costs associated with designing and creating sophisticated user consent/preference experiences, implementing multiple integrations with dissimilar systems, creating complicated sets of internal rules the system will apply, and developing robust reporting. Additionally, the decision should include the full cost of training and support, as well as on-going system maintenance and improvements.
Managing customer consent and preferences is crucial for building trust and maintaining loyalty. Our Build vs Buy guide breaks down the following:
- Build vs. Buy Decision: Enterprise organizations face the choice of building or buying a consent and preference management platform. This decision is critical due to data privacy laws and personalized experiences.
- Choosing the Right Solution: Align with your business vision, product roadmap, and goals. Consider future technology evolution – not just the current landscape.
- Exploring Challenges and Opportunities: The guide covers regulatory compliance, integration, scalability, cost, and vendor expertise. Equip yourself to choose the best approach for your organization.
