Customer spotlight: Capgemini is turning comms and conversations into AI-ready knowledge
As organizations invest in Microsoft 365 Copilot and AI, many are asking the same question: What knowledge will AI actually use? For Capgemini, the answer isn't buried in documents alone. It's found in leadership conversations, employee communities, company events, and knowledge shared every day across the organization. Through Viva Engage, Capgemini is creating a living knowledge layer that helps employees connect with leaders, learn from one another, and build the organizational context that makes AI more useful. Moving beyond broadcast communications Capgemini's goal is simple: meet employees where they already work. Rather than adding more destinations and channels, the company is focused on creating a connected experience across Teams, Viva Connections, and Viva Engage that makes it easier for employees to find information, participate in conversations, and learn from their peers. For Jeanette Vikbacka Castaing, Global Internal Communications at Capgemini, communities are ultimately about helping people connect, learn, and share expertise. Speaking at Microsoft 365 Community Conference, she described the value of bringing together people who are "passionate about engagement, communications, and products" and creating opportunities to learn, grow, and exchange ideas. Creating the signals Copilot needs One of the central themes of Microsoft's "Engage Everywhere" session was that AI adoption is not simply a technology challenge. It is a communications and knowledge challenge. Copilot relies on organizational context to generate grounded responses. That context comes from everyday interactions between employees, experts, and leaders. Communities capture peer learning. Leadership dialogue provides direction and context. Events create shared moments. Conversations preserve institutional knowledge. At Capgemini, these signals are being created at scale through several key use cases: Executive leadership communications Corporate events Employee challenges and campaigns AI-focused communities Ongoing employee conversations and knowledge sharing Making leaders visible—and discoverable Leadership visibility became one of Capgemini's key priorities over the past year. What began as an experiment encouraging leaders to post directly evolved into a measurable communications strategy. "We have really seen now an increase of the views every time a leader posts directly in our all staff community," Jeanette explained. "It's very clear that people want to hear from the leaders. We can see that in the data." Beyond reach, the goal is trust. By making leaders more approachable and accessible through conversation, Capgemini is creating stronger connections between leadership and employees. "When you're approachable, you also build trust," Jeanette shared. These leadership conversations become more than communications content. They become organizational knowledge that employees can discover later and that AI can reference when surfacing relevant information. Turning events into lasting knowledge Capgemini has also embraced events as a way to create connection and generate knowledge before, during, and after a live moment. Instead of treating events as standalone broadcasts, conversations continue around the event experience. Employees ask questions, share perspectives, and contribute ideas that remain available to the broader organization. Microsoft's vision for Engage events follows the same principle: event conversations create content that can remain discoverable and continue delivering value beyond the live session itself. The multiplier effect of conversation Perhaps the most compelling insight from Capgemini's story is what the team calls the “Multiplier Effect of Conversations” For example: A post creates a conversation. A conversation creates connections. Connections inspire action. Actions drive outcomes. For communicators, this represents a shift in how success is measured. The value of a post is no longer limited to impressions or views. The real value comes from the expertise surfaced, questions answered, relationships built, and knowledge created throughout the conversation lifecycle. As communications strategies evolve, measurement becomes increasingly important. Capgemini has seen this effect firsthand through employee challenges tied to company sponsorships such as the Ryder Cup, America's Cup, and Tour de France. Previously these campaigns relied heavily on email. Today they are powered by conversations in Viva Engage. According to Jeanette, the difference has been "night and day." Employees immediately start commenting, tagging colleagues, sharing excitement, and encouraging others to participate. "We really build momentum," she said. "It's kind of a snowball effect.” Perhaps most importantly, the conversations continue long after the original campaign. Past contest winners often return to encourage future participants, creating a self-sustaining cycle of engagement and peer advocacy. Capgemini's journey reflects a growing need among communicators to understand not only whether content was delivered, but whether it generated participation, engagement, and meaningful outcomes. The goal is helping communicators measure not just reach, but influence. Measuring More Than Reach Capgemini's approach to communications is increasingly data-driven. Whether evaluating leadership visibility, participation in AI communities, or employee engagement with company-wide campaigns, the team looks beyond simple message delivery. "People want to hear from the leaders. We can see that in the data," Jeanette explained when describing the growth of leadership communications. The same focus applies to Copilot communities. Capgemini tracks how employees engage, ask questions, and help one another. Jeanette noted that even large, open communities remain productive because employees arrive with a specific purpose: learn, ask questions, and share knowledge. "You ask a question, you get an answer," she said. "It's really peer-to-peer connection at its best." For communicators, these interactions represent something more valuable than traditional engagement metrics. They are signals of learning, expertise sharing, and organizational knowledge creation—the same signals that help employees today and help Copilot deliver more relevant answers tomorrow. Building an AI-ready culture The most important lesson from Capgemini's story is that successful AI adoption starts with people. Communities give employees a place to learn together. Experts can share knowledge. Leaders can provide clarity. Questions become answers. Conversations become institutional memory. Over time, those interactions create the organizational context that helps Copilot deliver more relevant, grounded responses. One of the fastest-growing examples is AI itself. Capgemini has built multiple communities dedicated to Copilot, including a broad Copilot Chat community, a community for licensed Copilot users, and a separate space for certified Copilot champions. According to Jeanette, each has a different purpose and audience, but all are performing well and generating strong participation. "The reach is just amazing. We measure, of course," she explained. Start, test and, and learn Asked what advice she would give communicators just beginning their journey, Jeanette's answer was straightforward: "Test, test and learn." There is no single formula for building communities or driving engagement. What works depends on the audience, culture, and goals. "Failure is also progress," she said. "Test and see what works and build from there." That mindset reflects Capgemini's broader approach to AI readiness. Create opportunities for people to connect. Encourage leaders to participate. Build communities where expertise can be shared openly. Measure what matters. Over time, every conversation contributes to something bigger: a living body of organizational knowledge that helps both employees and AI work smarter together. For communicators, the opportunity is clear: every conversation is more than a moment of engagement. It is a chance to create knowledge, build trust, and help the organization become more ready for AI. So, the question becomes: what conversations are you creating today that your employees, and AI, will need tomorrow?Multitude builds resilient banking platform with PostgreSQL and MySQL on Azure
Expanding into new markets is usually a sign that things are going well. For digital banking platforms, however, growth brings a different kind of challenge - more customers, more data, and stricter expectations around availability, security, and regulatory compliance. At Multitude, we operate across 17 countries and deliver digital banking, credit services, payment processing, and regulatory reporting through a platform composed of more than 400 microservices. Each service encapsulates a defined business capability, including onboarding, risk assessment, collections, and compliance workflows. Historically, our services relied on on-premises PostgreSQL and MySQL environments deployed within our own data centers, where capacity scaled vertically on shared compute and storage resources. This model created contention between unrelated workloads and limited their ability to scale independently. Expanding capacity required adding or upgrading physical hardware, which involved demand forecasting, procurement, delivery coordination, and installation within the data center. Over time, continued growth amplified these architectural constraints. The database engines themselves remained reliable, but the surrounding infrastructure limited elasticity and domain-level isolation. As a result, sustained growth began to expose structural limits in the underlying infrastructure. "In a regulated financial environment, those constraints carried broader implications. Frameworks such as DORA and GDPR require predictable availability, controlled recovery procedures, and governed access to sensitive data. As workload demands increased, sustaining both growth and compliance required structural changes at the database layer. We decided that redesigning our data architecture was necessary to improve workload isolation, scalability, and governance alignment. Rearchitecting data boundaries with Azure Databases We initiated our architectural redesign by migrating database workloads to Microsoft Azure and standardizing on Azure Database for PostgreSQL and Azure Database for MySQL for core application services. Central to this redesign was the adoption of bounded contexts. Each bounded context represents a logical business domain and encapsulates the services and schemas required to support that capability. Each domain is owned and managed by a single team, aligning technical boundaries with team responsibility and accountability. Rather than maintaining a small number of large, shared database instances, we provisioned dedicated database instances aligned to defined business domains, establishing domain-level isolation at the database layer. Today, approximately 35 database instances support more than 400 microservices across the platform. Each instance may host multiple schemas serving related services within the same domain, while cross-domain database dependencies are intentionally avoided. This structure limits the blast radius of configuration changes or workload spikes and allows scaling adjustments to be applied within clearly defined domain boundaries. While the bounded context model was a strategic architectural decision, leveraging managed database services helped us implement it by drastically reducing the operational overhead of provisioning, scaling, and maintaining independent instances across domains. Azure Database for PostgreSQL and Azure Database for MySQL provide the managed capabilities required to sustain this model. Instances are provisioned according to the performance and storage requirements of each domain and can be adjusted as workload characteristics evolve. Compute and storage resources are scaled at the instance level, allowing capacity changes to be applied to a specific bounded context without affecting unrelated domains. Altogether, these architectural decisions balance domain-level isolation with operational manageability. A database-per-microservice pattern would significantly increase provisioning, monitoring, and lifecycle overhead without materially improving data ownership boundaries. By grouping related services within bounded contexts, we maintain clear domain alignment while keeping the number of database instances practical to operate. As a result, data boundaries, scaling behavior, and operational controls remain consistent with business domain structures across the platform. Operationalizing high availability and backup strategy To support availability, we deploy Azure Database for PostgreSQL and Azure Database for MySQL with zone-redundant high availability, placing primary and standby replicas in separate availability zones within the same Azure region. Replication preserves transactional consistency, and zone separation reduces exposure to localized infrastructure failures. We periodically exercise failover procedures as part of operational validation to confirm recovery behavior under defined conditions. Availability controls are complemented by a layered backup strategy. Azure Database for PostgreSQL and Azure Database for MySQL provide automated backups with a retention window of up to 35 days and point-in-time restore capabilities. These features allow us to restore a database to a specific timestamp within the retention window, supporting recovery from application-level errors or unintended data modifications without custom snapshot orchestration. Together, operational backups and governed archival retention address both short-term recovery and long-term compliance obligations. Restore operations require documented justification and follow established approval workflows, ensuring that recovery actions remain controlled, traceable, and auditable. We also enforce consistency through lifecycle management. Azure’s managed service model standardizes engine patching and version updates across environments, reducing configuration drift and minimizing manual coordination. By operating within the managed service boundary, the database team can focus on workload analysis, performance tuning, and capacity planning. For migration and synchronization scenarios, we use Azure Data Migration Service to orchestrate controlled cutovers between database environments. Engineers validate configuration and readiness before initiating synchronization, after which Azure-managed replication then maintains data alignment until final switchover. Provisioning decisions and structural modifications remain subject to internal governance approvals to preserve change control and oversight. By combining zone-redundant availability, structured recovery workflows, governed retention policies, and standardized lifecycle management, we operate a database layer engineered for resilience, auditability, and regulatory alignment at scale. Compliance as an architectural property For us, governance is embedded directly into how the platform operates, beginning at the identity layer. Access to Azure Database for PostgreSQL and Azure Database for MySQL integrates with Microsoft Entra ID, aligning database authentication with centrally managed corporate identities. Role-based access control is enforced through enterprise identity policies, providing centralized visibility into access assignments and authentication events across environments. These controls extend into production access management. Privileged access is approval-based and time-bound, and administrative roles are not permanently assigned. Access requests follow defined workflows, and all privileged actions are logged for review under established oversight procedures, ensuring traceability of operational interventions. Database isolation reinforces these identity controls. By aligning database instances with bounded contexts, each business domain maintains a discrete data boundary at the database layer. This structure limits lateral access across domains and confines sensitive data to clearly defined ownership scopes, simplifying monitoring and audit review. In a regulated financial environment, these architectural controls also support compliance requirements under frameworks such as DORA and GDPR. By embedding identity integration, domain isolation, and lifecycle controls directly into the platform architecture, governance becomes an operational property of the system rather than a separate procedural layer. The simplicity of this architecture is a strong driver for both auditability and security of the whole platform. Measurable impact across engineering teams and business outcomes Beyond improved stability, our ability to respond to growth has changed significantly since moving to Azure. In the past, expanding database capacity meant procuring hardware and planning installation in the data center. Now, capacity adjustments happen directly within Azure and can be applied to individual databases instances, allowing us to scale in near real time as workload demands change. Maintenance effort has also decreased. Managed patching, version alignment, and automated backups have reduced the need for manual coordination and reactive capacity management. Infrastructure-level tasks that once required continuous oversight are now handled within the managed service boundary. Our DBAs are now focused on improving performance and stability. We spend far less time maintaining the basics. Resilience by design The structural changes behind these results reflect a deliberate long-term strategy. Our database architecture now aligns with the operating model we expect to sustain over the next five years and beyond. Bounded contexts define discrete data domains, while Azure Database for PostgreSQL and Azure Database for MySQL provide managed high availability, scaling controls, and standardized lifecycle management across those domains. Identity integration and governed recovery procedures operate consistently across environments. With this architecture in place, Multitude scales responsibly in regulated markets while maintaining strict governance and availability standards. Expanding into new markets still means more customers and more data - but now our platform is designed to handle that success.
