First, to be clear, my focus is B2B (at least initially). Assume a use case for a medium-sized manufacturer with an account-based sales process.
Pre-internet – if an existing customer wanted information, they asked for it. Alternatively, the sales team pushed it their way if they thought it might be of interest. Awareness (prospects) was created using advertising, PR, events and sales outreach.
Then the internet:
Stage 1 – Businesses loaded the information they thought existing customers might need online.
Stage 2 – Businesses loaded information they thought prospects might use – information to progress the sales process – and tried to drive traffic to that information.
Then social media came along, closely followed by Google’s drive for quality (whatever that means) content and the concept of inbound.
For reasons too involved to go into here, I exclude large businesses from the following argument. I also exclude those start-ups able to generate (offline) buzz.
For medium-sized B2B businesses, I suggest online marketing has been delivering poor ROI for five years or more. I suggest if they persist with established online tactics, the returns will only get worse.
A proportion have flipped back to using many pre-internet marketing tactics, but information delivery is inefficient. It remains true that existing customers and prospects would rather pull the information they need.
The problem they have is finding that information. For existing customers searching a supplier’s website is not a great experience. For prospects, the chances of finding the information a manufacturer may want to push out online is low.
SOLUTION – EXISTING CUSTOMERS
What if the manufacturer puts all their existing online material, datasheets, qualification reports, company reports – everything a customer’s engineering and decision-making teams might need – into a knowledgebase (for want of a better term). The customer interrogates that information using a chat interface.
As with the online inbound concept, this approach gives the sales team some problems, but I will gloss over that for now.
The obvious advantage of this approach is the customer can access the information they need, when they need it, but there’s more. If it’s possible to restrict access, it’s possible to create scarcity – always a good thing. If the customer feels they have access to something different – something scarce – it drives retention.
SOLUTION – PROSPECTS
Assuming a business can build awareness (offline?) and find a way to drive those triggered and in market to a Chat interface website then it’s back to the concept of inbound – on steroids.
BUT, again there has to be a restriction on what prospects can/cannot access. They have to be a customer to get a higher level of access and a key customer to get further still.
ADVANTAGE – COMPETITORS
A short story from a bygone (pre-internet) age to illustrate the point.
A salesperson rocks up to see one of his engineering contacts in a key customer. As a good salesperson, they have a strong personal relationship with the contact.
The engineer states that a competitor has designed in a component on another project that he would like to use on one of his new designs. For various reasons, he doesn’t like the competitor so could the salesperson determine if it’s possible to supply an equivalent?
Sure, says the salesperson, but what’s the spec. Off wanders our engineer into another office and then onto the photocopier. Here’s the competitor data sheet he says, but to be clear you did not get it from me.
My point is in the pre-internet days, it was possible to make it hard for a competitor. Sure (as described) there were ways around it – if you had a relationship – but it was not as trivial as downloading a datasheet from a competitor’s site.
If a website is simply a Chat type interface to a knowledgebase and if it is possible to restrict access in some way to that knowledgebase then competitors are (to an extent) locked out.
I want to find a way to have a knowledgebase accessed via a Chat interface. BUT I want to grant levels of access to that knowledgebase.
Multiple knowledgebases are one way, but that’s resource-intensive and difficult to manage. Another way would be to tag information in the knowledgebase to determine access level, but again I am not sure that would work.
There has to be a way of identifying who is trying to access the Chat interface. Passwords would be one way, but that does not work for prospects.
So I am struggling. So far, I have sketched out a first pass of how it might all work, but it is far from ideal.