5 Top Tips to consider when building your Marketing Solution

Prior to the start of any project a key pre-requisite is an understanding of your goals, objectives and requirements, with phases of discovery and definition required to identify your needs and to deliver a solution which meets your goals.

This is a well understood and accepted fact, but with current pressures on time and cost, can often be overlooked in the desire to achieve quick results.

With this in mind I have detailed below 5 key items to consider when building your Marketing Solution:

1) Understand your goal and objectives
Before asking questions about how to get there or commencing on a journey, a clear idea of where you want to go is required. This holds true for the delivery of a Marketing solution, where having clear business goals and objectives will aid in delivering a solution that is fit for purpose and provides ROI. So before delving into the design and delivery ensure you consider the following:

• A clear link to the business goals should be the starting point of any marketing objectives. For example, ‘To grow UK sales by 10% and European sales by 20% in the next financial year’.
• Consider operational, social and management goals as these will impact objectives of the Marketing Solution. For example, ‘To enable the performance of marketing activities to be measured, evaluated and refined’.
• Ensure your objectives are business led and not solution led. An objective is the benefit the business should receive as part of the solution, not something delivered as part of the solution. For example, the creation of a single customer view (SCV) is not an objective, but the ability to understand and identify your customers is.

2) Understand your customer and their interactions with you
A key element to delivering any solution is to have a clear understanding of the scope, as this will undoubtedly flex during the solution delivery. To help understand this look at the customer journey, to understand the interactions and each unique touch point a customer has with you. For example the following retail touch point model highlights potential interactions a customer may initiate or receive: 

Using this approach will help provide a holistic view of the key solution deliverables, with a clear set of channels (communication & purchase) and potential data sources identified.

3) Define the required solution from scenarios not from specific elements
In order to ensure a solution is fit for purpose it needs to be able to deliver the on-going day to day needs of the marketing team, providing answers to questions on Campaign Effectiveness, Retention Analysis, Cross Sell Analysis, etc. These scenarios should be defined to ensure the capability to provide and expand is built into the solution and not the delivery of specific elements.

A good way to look at this is to consider the design and fitting of a new kitchen, where an approach could be to ensure each element (kitchen drawers, cupboards, oven, fridge, etc) is provided. This would ensure all the required pieces are provided, but does not ensure the kitchen is fit for purpose, where looking at an actual scenario such as baking a cake or preparing a meal would ensure the solution meets the day-to-day needs, as well as ensuring individual items are delivered as part of the scenario.

The specific elements can then be defined in detail to support the identified scenario and to validate that the data required to support these elements is available.

4) Do not forget the non-functional requirements
As well as looking at the functional elements (a requirement that the solution must do), a key aspect is the non-functional elements (a requirement that defines how a solution must behave and can often be classed as a constraint on the system), such as the deployment model for the solution. Remember to consider:

• When and how a solution will be delivered, covering:
  • Solution deployment (In-House, Shared, Outsourced).
  • Data availability and accessibility (Dependencies, frequency of supply and access requirements from the marketing team both physically & by time zone).
  • Capacity (What is the project growth of the solution data?).
  • User community (Who, which products, which functionality and which data).
• Performance and availability:
  • Performance needs (Response time, refresh timescales, campaign execution timescales, etc).
  • Recovery (Understand allowable amount of downtime and recovery timescales required in the event of a critical failure).
  • Auditability.
  • Support levels (Understand and define the support service levels for different levels of incident)

5) Plan the User Acceptance Test (UAT)
As with any part of a project, planning is everything, so the key areas to consider in planning a UAT are:

• Timeframe – When will the UAT be completed and how long will it run for? How many phases will be required to validate the delivery and on-going supply of data?
• UAT Users – Who will be involved in the UAT activity? What is their availability and will they require any training prior to beginning the UAT? Are there enough individuals or enough time to complete the defined tests?
• Data Availability – To ensure a UAT can be completed in a controlled environment, with any inconsistences easily identified, the delivery and availability of the data for use in the UAT will need to be considered.
• Sign off Criteria – Before starting a UAT, understanding how success will be measured is critical and will help focus the mind on must haves and nice to haves during the UAT phase. To complete this any defect found should be classified to a specific severity level, with a pre-agreed tolerance level set for each severity level.
• UAT Test Document – A UAT Test Document should be created prior to the start of the UAT to ensure the UAT does not become an internet browsing event with some areas looked at in detail, some not touched and time wasted on blind alleys.
• UAT Defect Log – A mechanism for capturing, reporting and managing defects found during a UAT should be agreed and implemented to ensure defects are responded to, based on their impact and importance.

When creating the UAT Tests remember that a UAT is specifically aimed at ensuring the solution meets the identified requirements in the real world, and should hence be based on the defined solution requirements and not the functional design. So when creating the UAT Tests ensure they cover the requirements and not how the solution has been put together, for example in an earlier posting on Analysis (What analysis will I require?) a specific analysis metric requirement was identified for the “Number of quotes by individual in first 6 months”. To test this, a UAT Test should be devised to cover this piece of analysis and not to test how the actual item was implemented in the design phase as the definition could be the incorrect element.

If you have any further questions or would like support in ensuring ROI and maximising the potential value of your customer data, please contact me through the BlacklerRoberts Ltd “Contact Us” page and I will be happy to discuss your needs. Alternatively please follow @BlacklerRoberts on twitter for further insights.