Payments Cross-Sell Strategy
Sage AAMEA
The purpose of this paper is to document a South African group-wide strategy for the refinement of
payments cross-sell into the core application-base.
The singular objective of this strategy is to drive payments cross-sell aggressively, to increase
cross-sell revenue, and, to leverage the installed-base as primary revenue driver.
After extensive interactions, through several forums, over the past three years, including but not
limited to:
1. Interviews with:
a. Andrew Wilson, Chris Wade, Paul Harrison and other members of the Sage Group
Executive,
b. Simon Black and the Sage Pay (UK) team, and,
c. Greg Hammermaster and the Sage Payments (USA) team,
2. Extensive debates with the Netcash team,
3. Branding and marketing discussions,
4. Experiences at Sage Pastel Payroll, including:
a. A free trial period,
b. Payments as a service, and,
c. A modular approach,
5. Internal meetings, including:
a. Sales interactions,
b. Support deliberations,
c. Executive discussions, and,
d. Operational debates;
…..we have come to the conclusion that in order to fast-track Payments cross-sell in South Africa, it
is critically important that we do the following as a matter of priority:
1. Ensure Executive Support for a single South African group-wide financial services strategy,
2. Rebrand the Netcash business to Sage Pay (RSA),
3. Focus on the immediate payments-integration of all product lines, including the legacy suite
i.e.:
a. Sage Pastel MyBusiness,
Agreed & Confirmed
Page 1 of 5
b. Sage Pastel Accounting,
c. Sage Pastel Evolution,
d. Sage Pastel Payroll,
e. Sage VIP Liquid,
f.
Sage VIP Essentials, Classic and Premier,
g. Sage VIP People,
4. Clarify the revenue-sharing and “for-bonus” revenue-recognition models, and,
5. Create a single owner of both the payments cross-sell strategy as well as the payments
cross-sell KPI’s i.e. Sage Pay (RSA).
The Sage Pay (RSA) team has consistently advocated such an approach.
Based on group-wide best practice-sharing, it has become clear that this is the only approach which
has yielded any significant results in the Sage Group worldwide, with both the US and UK operations
having tried as many, if not more permutations than have we in South Africa, with a single
conclusion: the steps outlined, above, are critical to the overall success of payments cross-sell into
the core installed-base.
In order to give effect to group best-practice and to expedite and drive payments cross-sell into the
core application user-base, the following strategy is recommended:
1. Change the name of Sage Netcash to Sage Pay (RSA),
2. Adopt a dual revenue-recognition approach for Sage Pay (RSA) and individual OpCo’s in the
region,
a. 100% of Financial Services revenue is recognised in Sage Pay (RSA), not the OpCo,
b. OpCo’s may not design, implement or sell individual derivatives of the financial
connected services, nor, may they design and promote modules including
components of financial connected services,
c. Revenue is recognised both in the OpCo and in Sage Pay (RSA) for bonus and reward
purposes,
3. Refine and build a Single Marketing Approach with both Group- and OpCo-lead elements
which are closely aligned,
a. A single Sage Pay (RSA) product is designed and offered to the customers of ALL
OpCo’s which is consistent and priced in precisely the same way,
b. Sage Pay (RSA) product design and deployment is not an OpCo strategy but a single,
coherent, Sage Pay (RSA) group-driven offering,
c. “Commercial Modules” for verifications and validations will no longer be supported
by Sage Pay (RSA) and these modules will have to be discontinued with immediate
effect by the OpCo’s who have already introduced the concept,
Agreed & Confirmed
Page 2 of 5
d. The only exception to 3.c (above) is that OpCo’s will be permitted to include
unlimited free bundled validations and verifications on both Bank Accounts and
Identity Numbers, as well as unlimited free bundled Driver’s License verifications,
when these services are included as part of the OpCo’s Subscription Billing bundled
offering; OpCo’s will bear the direct cost associated with each related transaction at
cost-price to Sage Pay (RSA),
e. Sage Pay (RSA) will be responsible for all billing, sending a single customer statement
for all financial connected services provided to a customer, irrespective of whether
these services are provisioned through in-product integration, via the Sage Pay (RSA)
web interface or in-product iFrame technology.
f.
Messaging to all clients of all OpCo’s is aligned with the Sage Pay (RSA) messaging
and is consistent across the RSA region i.e. there is a single group-sponsored
marketing approach,
g. OpCo’s will however have some flexibility in terms of in-product service-delivery and
marketing messaging which is appropriate for the OpCo in question,
h. Selling Sage Pay (RSA) services is in no way contingent on in-product integration and
can take place either with- or without tight in-product integration, this means that
no sales initiatives will be placed on hold pending in-product integrations,
i.
In-product integrations and changes to in-product services will be co-ordinated well
in advance with the relevant OpCo R&D Director / Manager and releases of Sage Pay
(RSA) functionality will be carefully co-ordinated, planned and exposed to coincide
with the normal release-plans of the various OpCo product lines,
j.
OpCo’s will provide their customer databases to Sage Pay (RSA) for data mining and
sales initiatives,
k. Sage Pay (RSA) will not be permitted to conduct installed-base marketing initiatives
of any nature including but not limited to: email, telephonically or online, without
campaign review accompanied by the express approval of the Marketing Director /
Manager of the targeted OpCo,
l.
Sage Pay (RSA) service keys uniquely identify a customer with a Sage Pay (RSA)
service and the “owning” OpCo,
m. The value proposition for a client is:
i. A single Sage Pay (RSA) account,
ii. Capable of using all the Sage Pay (RSA) services, not just those integrated
into the various line-of-business applications,
iii. Integration touch-points will vary by line-of-business and domain e.g.
Accounting, Payroll or CRM, but will provide a key differentiator in terms of
tight-integration services and streamlining of workflows.
4. Build a central Sales Team capacity, under the line responsibility of Sage Pay (RSA), to
augment and support OpCo sales initiatives,
Agreed & Confirmed
Page 3 of 5
a. Sage Pay (RSA) personnel will be directly responsible for selling the Sage Pay (RSA)
Services to the clients of the OpCo,
b. The OpCo will provide database information to facilitate this sales initiative,
c. Sales personnel will be based, in the fullness of time, in the Sales Team of the
various OpCo’s,
d. These sales personnel will have line responsibility to:
i. Sage Pay (RSA) for:
1. Hiring and appointment (correct skills and capabilities),
2. Skills and training,
3. Target allocation,
4. Development of personnel KPI’s,
5. Performance management,
6. Results,
ii. The OpCo for:
1. Hiring and appointment (suitable fit),
2. Day-to-day management,
3. Attendance,
4. Team integration,
5. Adjust and refine the in-application offering to align application-based services with this
strategy, through the:
a. Integration of a maximum of two Sage Pay (RSA) iFrames for communication and
connection with Sage Pay (RSA) will be included in the application in an unobtrusive
and customer-enabling manner so as not to impact performance or customerexperience of the core application, to be determined by OpCo product management,
b. Until a successful iFrame proof-of-concept testing suite has been conducted and
signed off by OpCo MD’s and Product Managers, iFrames will not replace existing
core product tight integration services including: payments, verifications,
validations, credit checks and CIPRO checks. Should iFrames prove to be a
practicable and workable solution for the client, this decision could be revisited.
c. Promotion of the current suit of in-product enabled integrations including:
validations, verifications, credit checks, Cipro checks and payments; with a clear
focus on driving payments cross-sell as an immediate priority,
d. Integration of “Pay Now” functionality into all core applications in the region,
e. Any reasonable additional integration requirement, within the product roadmap of
the OpCo, as agreed with OpCo Product Management.
Agreed & Confirmed
Page 4 of 5
f.
In-application iFrame calls must provide parameters for vendor and product
identification for revenue recognition purposes.
Agreed and confirmed on Wednesday, 07 August 2013, by: Charles Pittaway, Grant Lloyd, Steven
Cohen, Anton van Heerden, Jeremy Waterman, Ivan Epstein, Hazel Otte and Fanie Jansen.
Document Statistics: 5 / 1350 / 85 / 152
<<DOCUMENT ENDS>>
Agreed & Confirmed
Page 5 of 5