CRM Tendering Tips, Part 1: It’s a Tender not Tinder
I’ve been delivering CRM solutions since 2000, I initially started as a developer, moving on to an architect / consultant role and am now focussed on the sales side of things rather than the implementation. Without a doubt, my least favourite activity is responding to tenders. In my view the standard tender process, dictated by procurement, is the antithesis of how you want to successfully implement CRM within your organisation. It removes the aspects of collaboration and discovery which are vital to uncovering the people, processes and pains within an organisation. Instead you end up with a dry Request for Tender (RFT) document usually from a single person’s viewpoint, lacking context on organisational culture, risks, business readiness and other factors which make a transformational CRM project a success or not.
That said, for public sector and enterprise organisations, tendering is a fact of life and highlighting the drawbacks of a mandatory process is of little value to anyone. Instead, over four parts, I would like to proffer my suggestions on how to make the tendering process for CRM as successful as possible.
Part 1 - It’s a Tender not Tinder
Part 2 - You get the price you ask for and you get the solution you pay for
Part 3 - If everyone is special then nobody is
Part 4 – Make sure everyone is a winner, especially you
Part 1 - It’s a Tender not Tinder
It's probably ironic that tender and tinder differ only by a single vowel. A tender is defined by Wikipedia as “a structured invitation to vendors for the supply of goods or services” and Tinder is defined as a “social discovery application which allows you to connect with mutually interested users”. On the surface they may seem similar - both are formalised methods of connecting with people - but whereas with Tinder you paint yourself in the best possible light and state your basic requirements, if you do this with a CRM RFT you risk getting responses which are hard to decipher and a partner who won’t understand the real organisational need or expectation.
So, when preparing your tender requirements remember the following:
It’s not you, it’s me
Spend a lot of time in your tender document describing the requirements in terms of:
People and Groups: Outline all the stakeholders involved - internal / external / partner including their roles, responsibilities, objectives or desired outcomes from the proposed CRM system.
Processes: Describe the inputs and outcomes of processes of interest. Where you expect CRM to optimise or alter this state and why you need it to do this in terms of process pain points or waste.
Technology: What systems does the organisation currently have, what is their use and are there any end of life or strategic changes to note? It is also important to describe the users hardware as this often causes issues late in a project as silos of users are found with non-standard or legacy devices adding additional cost and delay to projects.
In documenting your requirements, avoid prescribing the design of the CRM solution. If there is an expectation of how something should be done, based on what has been done already, or what has been seen elsewhere, suggest this but do so cautiously and with caveats. You are seeking an implementation partner who lives and breathes CRM (hopefully) and who has delivered successes both in your industry and other industries. You want them to leverage all of that experience to deliver your CRM solution. As you wouldn’t tell a painter the brushes, ladders etc to use to paint your house, you instead need to define the inputs (paint colours) and outcome (painted house) you require.
Demonstrate your commitment
One of the big challenges in writing a CRM tender is that CRM is a long term commitment. When writing a tender however, you must define a clear scope in order to receive any confidence in the respondents’ costs or schedule. As a result, you will tend to stay tightly focussed on the specifics of the project for tender rather than the long-term outlook.
My advice therefore is to share the big picture! In an appendix, describe your long-term strategy or programme for the desired CRM, even if it is aspirational and without budget at this point. Doing this will show a respondent where this project fits into an overall programme. Knowledge of future work packages will influence the response to the tender request in two ways:
- Any proposed solution can take into account IF and WHEN key areas of the business might be brought into scope, or where business changes are likely expected. This can materially impact the design and costs in a tender. For example, if a request for tender is to cater for B2B customers but the future strategy is to pull in B2C customers via a call centre, a good RFT will state this, simplifying any future B2C take-on.
- It will ensure pricing is not estimated as an isolated standalone but with a longer term engagement in mind.
CRM is a consultative, long term engagement so let a potential partner know your commitment to CRM as a strategy. HOWEVER, proceed on this basis with caution. Sharing the big picture needs to include an acknowledgement in your request for tender that the picture is today’s best guess and business drivers and conditions may change this view.
Also, ensure you call out that there is no expectation to price or implement the items described in the big picture, instead ask that the response indicate a proposed solution which aligns or unlocks future big picture plans.
State your baseline requirements
CRM is a malleable and somewhat nebulous thing. It fits into the gaps between rigid systems like finance and ERP and bridges stakeholder groups both internal and external. In practice this means that any set of CRM requirements, despite how well you describe them above, will be met with responses that will potentially vary significantly in terms of:
- CRM’s level of optimisation and automation to deliver the requirements – some will be light touch others highly tailored
- Proposed solution approach and features – CRM has at least two or three ways to implement any requirement and unfortunately not all factors are available via the tendering process to understand which way is preferable
- Use of Assumptions – Any response will have a varying list of assumptions that the potential partner will use to state how they have interpreted your requirements or conditions they need to get you to sign up to. This is necessary to ensure that they can estimate with confidence.
- Proposed Schedule – Any reasonable sized solution will lead to variations around proposed phasing and sequencing of elements of the requirements.
So with variations of interpretation, approach and assumptions, you will likely end up having to try to compare apples, oranges and pears. You won’t avoid having to do this, but I suggest when you are preparing the RFT, it is at this time you also ask for a costing and approach to a baseline set of requirements. This baseline set of requirements shouldn’t be simplistic or abstract, but instead limited in scope to a single process or functional area where requirements are concrete and not dependent on third parties or timelines. Ask for a description of the approach and costing used, as well as confirmation that this approach aligns to the full set of requirements.
Stay tuned for part 2 of my CRM Tendering Tips, ‘You get the price you ask for and you get the solution you pay for’.