WWF Switzerland Prints Documents from Salesforce Cloud
WWF Switzerland has used Compart to develop a document management architecture that allows multichannel documents to be created and sent from within Salesforce Cloud.
MoreCentralization of the CCM
Customer Communication Management (CCM) has become increasingly significant in today's business landscape, as organizations recognize the importance of delivering personalized, relevant, and consistent communications across various channels to improve customer engagement and satisfaction. With the rise of digital channels, CCM has evolved to include digital document creation, management, delivery, and analysis. By implementing effective CCM strategies and solutions, businesses can enhance customer experiences, streamline communication processes, and drive business growth.
Over the last two decades, the definition of cloud computing has undergone a significant transformation. It's no longer limited to just offering storage capacities on a globally distributed infrastructure or providing software functions through the internet. Today, the cloud is a virtual platform where entire applications can be operated, such as AWS, Salesforce, or Azure. As a result, cloud computing has emerged as a key component of IT infrastructure, impacting areas like Customer Communication Management (CCM).
When businesses migrate to the cloud, they often encounter a significant degree of heterogeneity among their existing tools. This can lead to situations where almost every specialist application has its own customer communication database, creating data silos that need to be adapted for each new communication channel. These ad hoc adjustments require a high degree of effort, and even then, they cannot guarantee that all the information collected during a communication process can be returned to a central system for managing customer relationships, such as a CRM system. However, the ability to have stringent Customer Communication Management that spans all analog and digital channels is a significant benefit, as it provides a central repository for all customer-relevant data associated with a business transaction.
Case Study: Creating a Unified CCM Foundation in the Cloud
A case study from a European service provider highlights the benefits of creating a unified CCM foundation in the cloud. This company faced challenges in meeting increasing customer demands for responsiveness due to the limited scalability of its business applications' CCM capabilities, the proliferation of different applications, and the increasing number of digital communication channels. To address these challenges, the service provider decided to switch to Salesforce, a leading cloud-based CRM platform.
The company's long-term goal was to harmonize the CCM capabilities of various applications, closely link CRM and CCM, and gradually move them to the cloud for optimal customer communication. Centralizing all information from various communication processes (digital and analog) into the new CRM system was critical to avoid "two-class communication."
Salesforce Cloud Integration
Automated messaging platform that integrates with Salesforce.
Container for Functions
To achieve this goal, the service provider developed an infrastructure with a uniform but personalized basis of functions accessible by all applications, regardless of whether they were running on the company's servers or in the cloud. These functions are made available in the "cloud" as containers, significantly reducing the complexity of the previous infrastructure (many heterogeneous tools and associated permanent adjustments).
By unifying CCM capabilities in the cloud, the service provider can now provide more responsive and consistent customer communication across various channels. The centralization of all customer-relevant data associated with a business transaction into one system allows for a holistic view of each customer, facilitating better decision-making and improving customer satisfaction.
Event-driven CCM Architecture
for Transactional Operations
The new infrastructure developed by Compart brings a multitude of benefits for modern customer communication. The central role is played by the powerful DocBridge® Gear and DocBridge® Impress solutions (replaced by DocBridge® Communication Suite), which allow for the easy configuration and automation of processes for all customer communication, including specialist and Salesforce applications. With the help of the REST API interface, all business applications and data sources can be brought together in a single cloud infrastructure, allowing for efficient and streamlined communication processes.
The two solutions enable various CCM scenarios, including interactive processing, batch processing, and transactional processing. An important aspect is the event-driven monitoring of communication, allowing intelligent workflows to be developed that proactively detect and resolve issues with document delivery. This level of proactivity and personalized communication is essential in today's competitive environment, where customer loyalty depends on more than just the quality of service provided.
Furthermore, this new infrastructure reflects the changing relationship between CRM and CCM. By putting them on equal footing in terms of accessibility and scalability in the cloud, the project recognizes the importance of a robust infrastructure for personalized omnichannel communication in today's market. The integration of all data sources and communication channels required for business performance makes it possible to deliver a seamless and efficient customer experience, ultimately leading to increased customer satisfaction and loyalty.
More than two million communications daily
Compart's innovative architecture offers an unparalleled level of user convenience, making it easier than ever before for businesses to access the full range of benefits provided by DocBridge® Gear and DocBridge® Impress (replaced by DocBridge® Communication Suite). The powerful REST API allows for quick and easy querying of multiple data sources, with customized results available on demand. This means that any business application capable of exchanging and processing data in JSON or XML format can take advantage of the full functional spectrum of CCM Basis, preventing the emergence of "communication silos" or "two-speed communication."
What's more, this cutting-edge CCM architecture makes it possible to process over two million communication transactions per day - including one and a half million SMS messages and half a million emails - without experiencing any performance issues. This is a volume of communication that would normally exceed the capacity of cloud-based platforms, but with Compart's architectural approach, businesses can handle it all with ease.
Process Automation in CCM:
DocBridge®
Are you ready to revolutionize your customer communication management? Look no further than the DocBridge® Gear platform, a central component of the powerful DocBridge® product family. With DocBridge® Gear, you can automate and streamline every aspect of your customer communication, from document creation and modification to dispatch on both analog and digital channels.
But that's not all - the platform's reusable "worklets" make it incredibly easy to customize and configure workflows to meet your specific needs, no matter how complex. And with its seamless integration with other systems, you can finally achieve the level of automation and digitization your company needs to stay ahead of the competition. Say goodbye to manual processes and hello to the future of Customer Communication Management with DocBridge® Gear.
Request a Demo
Schedule a demo with a Compart product expert
Event Driven Architecture
Effective Customer Communication Management (CCM) is crucial for businesses, public authorities, and organizations. One of the most significant aspects of CCM is ensuring that important documents and messages are delivered to their intended recipients, which can be a challenging task. Failure to ensure delivery can result in legal consequences or missed opportunities for the business.
To address these challenges, a CCM system needs to be able to automatically switch to alternative communication channels to ensure the message or document reaches the recipient. This should happen automatically, with the cheapest and fastest channel always being utilized first. For example, if an email cannot be delivered, the system should be able to send an SMS or a conventional letter, depending on the situation.
The key to creating such an event-driven CCM architecture is the use of web hooks. These are requests containing information about events that have occurred during a communication process. They provide important details such as the status code of an attempted email delivery and an ID that can identify the original transaction at any time. This technology allows different applications, such as mail servers and CCM systems, to interact with each other, triggering appropriate workflows for document delivery.
Solutions like DocBridge® Gear (replaced by DocBridge® Communication Suite) can be configured to intercept email bounces and trigger new transactions automatically. These advanced processing scenarios can also be implemented in the cloud, making them a fundamental requirement for a modern CCM.
In summary, effective CCM is essential for businesses, public authorities, and organizations, and ensuring document delivery is a central aspect of this process. A CCM system should be able to automatically switch to alternative communication channels using an event-driven architecture enabled by web hooks. With solutions such as DocBridge® Gear, businesses can efficiently manage their CCM workflows, ensuring that important documents and messages are always delivered to their intended recipients.
Glossary
Container
In traditional shipping, transport containers allow for the quick distribution of goods in a standardized "package," whether the mode of transportation is ship, plane, train, or truck.
In IT, containers operate similarly: They package an application and the files required to run it into one handy unit.
Along with managing and distributing server applications, containers also make it easier to install and operate them. They facilitate handling complex server applications and allow extensive automation of a data center’s rollout processes. That’s particularly important when deploying scalable, distributed applications within a cloud environment.
When rolling out new applications or releases, an application is dependent on certain elements of its environment, such as local settings or function libraries. It’s often the case that settings in the development environment are different than those in the application’s test and production environment. Because of this, an application can work differently or not at all in rollout.
Other factors can interfere with a smooth rollout, too, including the application's underlying operating system, its version and settings, any added packages and modules, or the network configuration. Deploying multiple applications across different platforms can be a challenge.
That’s where containers offer an immediate advantage. Developers package an application along with everything it needs, such as libraries and configuration files, into a container. The application, therefore, is not installed directly on the target system. The container’s package provides the application’s complete runtime environment.
That lets developers easily move applications back and forth between different environments—to test the application in one hardware environment, for instance, and run it in another. Or they can run an application first on a physical machine and then in a private, public, or hybrid cloud.
Containers make applications independent from the environment where they are executed. They act similarly to a virtual machine (VM). A difference is that while a VM contains applications complete with an operating system, several containers can share one operating system kernel. Each application is given its own user space, which is an entirely isolated environment.
Compared to VMs, therefore, which contain gigabytes, containers consume significantly fewer resources such as computing power and main memory. Containers only contain megabytes. Many more containers than virtual machines, therefore, can fit on a server. Containers are also up and running much faster. While VMs sometimes take several minutes to start, applications are available almost immediately.
Containers complement virtualization
Virtualization solutions, though, are not suitable for all application scenarios, so they are not superfluous and will not be completely replaced by containers.
Containers are well-suited for infrastructures with a large number of application instances that run in parallel. They are also ideal for applications subject to frequent updates and functional extensions. For applications made of different components based on a microservices architecture, containers are an efficient way to implement a new rollout without a large overhead.
Virtualization with hypervisors is still a better choice, though, for some types of applications. One example is the provision and operation of standard server services such as database servers, directory servers, or even web servers. Others are standardized applications subject to longer update cycles that third parties provide.
Containers are, therefore, a useful addition to virtualization rather than a replacement.
Docker
Docker is open-source software for isolating applications in containers. It simplifies distribution because containers can easily be transported and then installed as files with all their necessary packages. Containers ensure the separation and management of resources used on a machine. According to Docker’s developers, that includes code, runtime module, system tools, and libraries—everything that can be installed on a computer.
Docker uses Linux techniques such as Cgroups and namespaces to provide the isolated workspace that is a container. Initially, it used the LXC interface of the Linux kernel, but Docker developers have since developed their own programming interface called libcontainer, which is also available for other projects. Docker uses the overlay file system AuFS as storage backend, but as of version 0.8, the software also supports btrfs.
Docker is geared towards virtualization with Linux. However, it can also be used with Hyper-V or VirtualBox on Windows and VirtualBox on macOS. Since resource separation is not entirely secure with Docker techniques alone, Red Hat implemented support for the security-relevant kernel extension SELinux, which secures the containers further at the host system level.
Docker was released by the company dotCloud in March 2013. The company was renamed Docker in October 2013. The platform-as-a-service product, still called dotCloud, sold to Berlin-based cloudControl in August 2014 and became increasingly well-known and popular that year.
Docker has become a fixed component of Red Hat Enterprise Linux. It’s also included in Linux’s openSUSE distribution.
In Summer 2014, Docker, Microsoft, IBM, Red Hat, CoreOS, Saltstack, and Mesosphere joined the Kubernetes project. This project, initiated by Google, aims to deploy containers on all public, private, and hybrid cloud environments.
WebHooks
WebHooks refers to a non-standardized method of server communication used in the context of distributed computing or message-oriented middleware. In principle, a WebHook is nothing more than a message in the form of an http request (URL with content).
WebHooks inform a server software that a certain event has occurred in order to trigger a reaction. When an application informs about an event by means of a WebHook, other applications interested in this event do not have to poll in order to become aware of it. This reduces the amount of messaging between systems.
WebHooks are used as a simple callback procedure in data synchronization, external calculation and data validation. Technically, an http POST message is sent to a URL prepared for this purpose, which returns the requested data. In contrast to SOAP (Simple Object Access Control), WebHooks do not use an additional transport layer and, unlike the Atom Syndication Format, are not restricted to the XML format.
Apart from WebHooks, there are other technologies for the design and operation of Event Driven Architectures, for example Apache, Kafka. These do not use a REST API, but message queues.
Source: Wikipedia
