COMMUNICATION PROCESS – pull/triggered communication
Pull/triggered communication means more relevant communication activities, where member behaviour (i.e. purchase of a certain product or lack of activity during a period of time, like post-purchase, abandon basket, rewards, recommendation models, regain communication etc.) triggers what to communicate and when. Therefore it is the most effective way to become more relevant for many different customers.
Pull/triggered communication has different dynamics from push campaigns, which are of a one-off character, happen in cyclical broadcasts. Pull/triggered communication is typical of programs—once launched, it is constant (ongoing) and is subject to continuous improvement. Deliveries are carried out automatically, based on customer activity, such as a purchase or an abandoned basket, or inactivity for a specific period of time. In this sense, the target audience criteria are stable and remain the same. People who meet the conditions are a part of it (as opposed to push/newsletter communication, for which target audiences are calculated separately for each campaign).
While push/newsletter communication falls within, in the vast majority, marketing domain, pull/triggered communication is a tool to support and achieve cross-department goals, as it focuses the dialogue with your customer, no matter where they are and what problems they have. Therefore it goes beyond marketing (i.e. CX with NPS service, e-commerce with ratings & reviews) and requires alignment and clear ownership in the organisation, as it should be performed by one source (the team who has the mandate to perform it in behalf the all departments).
The pull/triggered communication process is similar to the classical product discovery process you may find in digital, data-driven organisations, with the main principle: go to market and meet customers as fast as possible. Instead of developing the “dream, perfect solution” in Figma, you should focus on building the MVP (where “P” stands for prototype) as fast as possible and verify your assumptions and hypothesis with the real customers on a small scale.
For that reasons, you should secure, additional competencies:
- related to data architecture, to ensure proper data flow and to set automatic triggers,
- a UX designer for creating customer paths, especially for more advanced, multi-stage programs (such as NPS or ratings & reviews);
- subject matter expert; depending on the nature of the communication, most probably, this will be someone from CX (e.g. for NPS), eCommerce (rating & reviews), or another appropriate owner who will be involved in setting up the program, its evaluation and improvement.
The remaining activities are based on the same competencies as in push communication, which does not mean that they have to be performed by the same people. It is worth considering this process separately and building a dedicated team. In this type of communication, the communication team usually plays the role of a contractor (creation and implementation) of the commissioned programs, as well as of a manager (conducting evaluation and taking care of its development).
Stages of the process of creating pull/trigger programs:
1. ONGOING PLANNING
Planning is an ongoing, 24/7process that requires constant revisions and discussions. It contains actions like:
- The PM, together with the data team, identifies changes of performance of customers/members and highlights positive and negative trends. Values the business potential of shifting the negative trends or accelerating the positive ones (what are the customer problems we want to solve?);
- PM collects requirements and business needs from the organisation to identify the areas of improvement from the business side, such as briefs or ideas for subsequent programs (what are our performance problems we want to solve?);
- Based on requirements from business and results from data, the PM, together with the data team, prioritises the actions that represent the highest business potential. This can be evaluated based on sales figures or in “softer” metrics, like an uplift in customer experience or brand trust, etc.
As a result, the PM with the data team create a preliminary list of possible trigger programs, set the technical requirements and specify various triggers, and update this list frequently.
2. FEASIBILITY, VIABILITY AND VALUE ASSESSMENT
Based on the preliminary list the whole team runs feasibility, viability and value evaluation:
- What kind of data is required to build each trigger program?
- Do we have all competencies in place (do we know how to build it)?
- What are the technical requirements (do we have technical capabilities)?
- Do we have a solution for the customer’s problems or our performance problem (do we know what we want to say to the customers)?
- What is the expected outcome (what are the business benefits)?
- What is the development uplift vs. the expected benefit (is it worth investing)?
At this stage, the cooperation of the project manager with the technical & data team and the subject matter expert (CX, e-commerce, finance, etc.) is crucial. The cooperation results in negotiating priorities (what will be implemented in the near future) and planning the backlog (what will be implemented next).
One to one communication team should describe the background, the purpose and the objectives. To be more specific, describe the assignment itself, its prerequisites and constraints. The PM specifically should secure that all stakeholders understand the deadlines and challenges, what will be measured and followed-up on the project and specify what to do, how to do it, and what to deliver.
3. PRIORITY SETTING AND BACKLOG
The PM is the owner of both the priority list and the backlog. It is built in three stages:
One-year development calendar: what will be delivered during the year with special focus on:
A. Objectives (where we need to go?) that set the direction in an inspirational way (no metrics and no technical jargon):
● i.e. building emotional relationships with our customers beyond transactions (high-level)
● i.e. providing an excellent post-purchase experience for our customers (more practical).
B. Key results (how we will measure if getting there?) that describe the expected, measurable outcomes to achieve the objectives. You can describe them as metrics:
● i.e. increase customer interaction on x%;
● i.e. decrease the customer claims on y%.
C. Initiatives (what we will do?) that contain the list of all initiatives (trigger/pull programs) that will deliver to our key results metrics.
Objectives should stay stable for the full period and you should evaluate them at its end. Key results may change, depending on your performance (how fast you’re in achieving them) and be impacted by fast-changing reality. They should be revised frequently in the quarterly development plan.
A. Quarterly development plan: what will be delivered during the upcoming quarter with special focus on:
- Key results for this quarter: based on the previous period evaluation deciding where we are and what has to be prioritised to meet the metrics;
- Initiatives: what we will do this quarter and split them into the production cycles.
You can’t build everything at one time, so you need to prioritise. Different programmes require different work (digital development, new data flow, etc.) or different teams’ involvement (i.e. post-purchase require sales, while NPS require the CX team). Every initiative had its own dynamic, so the PM’s role is to plan the work to make all teams equally busy: what will happen in the upcoming production cycles, and what will be sent to the backlog for later.
A. Production cycles (2-4 weeks): what we will develop during the upcoming cycles to meet our goals and what will be sent to the backlog.
- i.e. development of the new pull/triggered programs;
- i.e. evaluation and improvements to the existing ones.
It never is a linear process. At one time, the data team can work on setting up the new data flow for one programme, while the creative team can work on assets for another one, and the technical team can implement tests for the third one. It is why it’s so important to have a long-term plan—it enables the project orchestration in the most efficient way.
4. PRODUCTION
Productions happen in cycles, where each team has full visibility on dependencies. Each team knows exactly the role in the production relay; they also know what is required as an outcome (quality and timing).
The ultimate principle is to deliver pull/triggered programmes to meet the customers as soon as possible, to work with real data, not assumptions. Thus, for the new programmes, your team should focus on MVP first, and deliver it to the customers to verify on a small scale before production of the scalable final solution starts.
a) setting up the new pull/triggered programme—building an MVP.
● UX and data team prepare a hypothesis to verify:
a. Which customer behaviour or purchase will start the communication process?
b. How the customer experience should look like, beyond the single email (including the landing pages, and other relevant touchpoints)?
c. What offers will be most relevant and activating for different target audiences?
d. What is the desired change in customer behaviour we want to trigger?
e. What sort of communication content will be the most relevant?
f. etc.
● The project manager creates the final solution brief, specifying the scope of the MVP (minimum viable prototype) that will be implemented for customers as an MVP Pilot. As a part of the brief PM prepares the test plan, which will be verified from data, creative or technical perspective during the pilot (different offers, creative solutions, communication, or channels to improve the effect).
● The data team defines data needs and sets up business rules, processes and queries, sets up a basic list of queries based on the communication objectives. Defines the target audience for test and control groups and makes sure these members are excluded from the communication. Both audience and control groups should be representative of a broader base and statistically significant to extrapolate the results to the entire customer base.
● The creative team works on the inventory of available materials, and, together with the UX designer, on the client’s paths. Mock-ups of both communication and landing pages are created for the entire expected customer path. Finally, the team creates graphical elements and copy for the entire program in all channels.
● The technical team, work on technical questions of implementing the solution (changes in the database, process automation, reporting, collecting feedback from the customer).
● Before launching the MVP, the team carries the end-to-end tests for the entire program, taking into account usability (whether the customer journey is clear and seamless for the customer), the correctness of data flow, and automation effectiveness.
● The technical team launches your project on a smaller scale before implementing it in a wider range according to the test plan from the brief. The data team measures and follows-up the results and the full team, if needed, improves the pilot activity based on insights and preliminary results.
● Data team measures and follows-up on the MVP (quantitative)
o Compare improvement on each segment.
o Compare with control groups.
o Follow up according to goals, queries and segments.
o Follow up on how the groups have moved within the member phases.
o Define ”dos + don’ts” for your activity (i.e. timing, relevance and frequency for each media and segment).
● The creative team follows-up on the MVP (qualitative)
o how the graphical assets work/how attractive they are
When the MVP Pilot results are positive (meet the Key Results) the team prioritises the development of a full-scale, automated programme and adds it to the business as usual.
b) scaling up and automating the push/triggered programme.
● optimising the programme can take some time and many different MVP interactions before you start to see the desired change in your customer’s behaviour and the impact on the metrics. Until that time it is better not to focus on writing the final code or automation, configuring all manually.
● Once the results are positive, the next step is to build the final, scalable and automated solution. In this process you should take into account:
○ the existing communication landscape: how this programme will impact the other programme? As you build the ecosystem, the new programme will always influence the existing ones (i.e. they are based on a similar trigger, like post-purchase cross-sale and NPS, or simply new programme will increase the number of emails that your subscriber will get),
○ the future potential development: how you plan to enhance this programme in the future? To avoid double work, it is good to secure flexibility in the solution for the future.
c) Business as usual – enhancing the existing programmes.
The communication team periodically evaluates the effectiveness of the program, collects consumer insights, and drafts development plans. Together with the business owner, the team decides whether to introduce changes or not. These are then transferred, in form of business cases, to the backlog managed by the project manager.
Very often, separate end-to-end product teams, consisting of a product owner (= project manager), UX designer, analyst, and digital developers, are responsible for individual trigger programs. Thanks to this, they have a lot of autonomy in the development of their program, the iterations and improvements are more frequent. I recommend such an organisational set-up for key programs that go beyond one department in the company (e.g. NPS, ratings and reviews).
