Portbase sends a customer satisfaction survey after a service is requested to understand how the process performs and where to improve. The campaign targeted the person registered as the main administrator because that was the only contact available through the existing integration. In practice, the person who requests a service is often someone else. That gap meant the survey frequently went to a stakeholder who did not experience the request journey. Feedback lacked context, insights became less reliable, and follow-up actions risked addressing the wrong issues. Teams had limited options. They could keep using the main administrator as a proxy, or try to infer the requester from other data already in the marketing platform. Neither option created a consistent, service-level link to the actual requester. As volumes grew, the issue started to affect the credibility of the survey program, slow learning cycles, and add noise to performance reporting. It also raised governance questions. If the requester role is not explicitly captured, what is the right approach to retention and deletion? We needed a clear way to identify the true requester, target them consistently, and give that role a defined place in both survey execution and data governance.<\/p>","button":""},{"acf_fc_layout":"layout_textblock_full","background":"none","title":"Solution","text":"
We extended the existing custom integration to retrieve, store, and maintain the requester for each service. In practice, the system of record (AFAS CRM) provides the requester at service level. The integration syncs this person into Adobe Marketo Engage and links them to the relevant service so the survey program can address the right individual. Campaign logic now checks for a valid requester with permission to email. If present, the survey invitation is sent to that person through the existing survey tooling. If the requester is missing or not emailable, a defined fallback applies, rather than an arbitrary selection. In parallel, we brought the requester into the data governance model. We reviewed retention needs, deletion triggers, and alignment with legal and commercial requirements. The result is a clear lifecycle: acquisition through the integration, controlled use for a specific purpose, and time-bound retention and deletion. We documented the logic, edge cases, and fallbacks. We added monitoring to surface missing requester data to operational teams. We also ensured the approach can be reused for new services with limited additional work. We chose this approach over continuing to target the main administrator or inferring the requester from existing marketing data. Those options could not reliably connect the survey to the person who initiated the service. Extending the integration was the most credible and scalable option because it uses the system of record and removes ambiguity in both campaign execution and data handling.<\/p>","button":""},{"acf_fc_layout":"layout_textblock_full","background":"none","title":"Impact","text":"
Business value: more relevant post-service surveys and more trustworthy feedback, supporting faster and better-targeted service improvements. Operational value: fewer exceptions and manual lookups, clearer campaign logic, and a repeatable pattern as services expand. Data quality value: the requester is now a defined role, distinct from the main administrator, improving targeting accuracy and reporting clarity. Governance value: requester data follows explicit retention and deletion rules, reducing risk and uncertainty in data handling. Productivity value: less rework, fewer incorrect sends, and reduced platform waste by focusing outreach on the right person at the right time. For Portbase, this strengthens marketing automation capability while keeping control of data flow from acquisition through retention and deletion.<\/p>","button":""},{"acf_fc_layout":"layout_form","image":null,"title":"More great resources like this? Subscribe!","form":"