What's the Best Way to Sell SDP?

Here I go again, solidifying LinkedIn answers to my question about SDP.

At first the question seems simple. But once you start thinking about it, it becomes not so easy…

Let’s see what people say…

I feel that you cannot sell the SDP until you have a strong business case and until you understand the operator pain points. Through SDP, you need to talk about all possible business models ..wholesale, retail and advertising etc and “show him the money’. Rather than talking boxes, you should talk about how money can be made using SDP. I also feel that since SDP is an investment, and until you have applicaitons on the top, you cannot make money on it, therefore it is better if you can bundle your offering with some killer applications. Moreover, never talk about a full fledged SDP at the beginning, show the customer a phased approach and how money can be made in each phase. Show him how to “start small” yet “thinking big”. Create a strong roadmap. SDP’s are typical SI solutions which take long time to implement, and therefore operators are at times apprehensive hence it is better to start with a productified soluiton yet having essential features and then slowly build on top of it.

I really like this answer. It was the first one, but it smells of experience (and Neeraj, in his words, been selling SDP’s, being in SDP Presales, and has “just deployed a very big SDP in an Indian Govenrment Operator”).

One of the main points worth looking at is the bundling with applications and “showing the money”.

Lucia Gradinariu

Principal Owner at LGG Solutions, LLC

Business case is the right approach although the market is not limited to telecoms. SaaS Providers, Content Providers and Service Aggregators also use architectural elements of an SDP. Take a look at Microsoft’s Azure Environment, Jamcraker’s Service Delivery Network, Jamba or even Google platform.

Indeed, some elements of, say, our SDP can well be sold to providers and aggregators — things like XML Service Creation.

Tom Nolle

President of CIMI Corp and Chief Strategist at ExperiaSphere

My experience is that most SDP deals are associated with some specific service-layer project or deployment, which in turn is associated with a specific service goal/revenue goal. It’s usually easier to tap into an existing project which has an approved business case than to try to launch something on your own, though the latter will often work with smaller service providers.Tapping into an existing business case often means having some relationship with equipment vendors who might also be involved, if for no other reason than that you find out about the opportunities more easily.

Having a good standards background is useful in all cases, since SDPs have to integrate into both the OSS/BSS and NMS part of the operator’s management framework, and these are standard interfaces.

Tom is giving a good hint suggesting to work with existing projects and to build a relationship with equipment vendors.

Later, Tom has also added:

Let’s then leave aside the issue of engagement and look purely at value proposition. An SDP is a platform on which service features are built. That means that effective sales would involve two things. First, you have to present a service feature ecosystem that supports a flexible model for adding services, managing their lifecycle, etc. This ecosystem model is what will have to differentiate your SDP offering from others. Second, you have to present an application that both showcases your capabilities and offers some near-term revenue justification for the buy.There are a lot of SDP stories out there, but most of them are really just underpinnings to a specific application story. That sells applications, but not SDPs. Think ecosystem if you want to have a good SDP story.

Good point (again) about bundling but Tom suggests to use it for the short term. Long term should show how this application (and many more from other service providers) can be managed throughout the lifecycle:

that is -

• Be born
• Be configured
• Be launched
• Be managed
• Be expanded
• Be taken down

1) Understand the customer’s current setup, services and customer base
2) understand what services they want to offer. Can SDP help them launch these services faster and cheaper? Unfortunately you may have to have a 1 year trial period to prove the profitibility before the sale can happen. Maybe the customer pays for the trial based on certain milestones?
3) 3rd party applications. You have to have a solid relationship and trust/contracts with your third party partners that buy into the SDP framework that you are selling. My experience has been that most 3rd parties lose interest if the sales cycle extends beyond 3 months for one customer unless they are getting paid to support the trial or pre-sales phase.
4) End to end story should be solid. OSS and BSS interfaces have to be testd well before you pitch to the customer. Provisioning, billing, Fault Managment, Performance management, scability etc are very important.
Devices testing should be performed and advertised well in advance.
5) Performance and High Availibility with clustering is a key need for production networks. This is specially needed for SDP applications if video and streaming is being used.

We build everything (except for some simple services like CallMeBack) with clustering and in HA (Point 5). This is thoroughly understood.

Interfaces can never be perfect because there are a lot of proprietary stuff despite the plead (also from Tom) for standardization. Sad but true.

1 and 2 are obvious but can be difficult to do…

3 — is a good point. Third parties can help because SDP helps them too.

Ivan
I think that at first you need to define what do you mean by SDP? This 3 letter acronym covers a whole multitude of connectivity. One can have a very simple SDP, and yes they can be simple, or one can take the whole concept of SOA to every part of “delivery” in a carrier network. I do feel that Neeraj has gone a long way of explaining the barriers you have to overcome in a carrier sell. I do disagree with him about “Killer Apps” there is never one; in my view the SDP is there so that there is a raft of Killer Apps for different groups both internally as well as externally. Neeraj has also helped you a lot by saying that “the idea of build it and they will come” will not work. There are a lot of implemented SDP’s out in the field without a single Application running on them. Also each country and carrier has a unique set of requirements be prepared to learn about each country and each carrier needs.

VP AePONA — worth listening to. His points are very well made, especially about “unique requirements specific to the country and operator (carrier).” Those can be a MF to learn (meaning investment/relationships needed).

Another point. SDP is not well defined. Duh. It’s not. So it can be small and cheap or big and expensive. I think piece-by-piece approach is a good one — that one was given by Neeraj.

BTW, AePONA + Nokia-Siemens and some others = SDP Alliance.

I don’t believe you _can_ sell an SDP, at least not enough copies to be profitable. You have two options (which actually represent the ends of a continuum): either:
1) Sell an application or set of applications which happen to bundle an SDP, or
2) Sell services and support for an SDP.

I like this point. I was very glad to learn about Open Source SDP from Transverse too. (It was from a presentation by Jeff Cotrupe)

I have also tried to see what is the competition out there, or what are the existing materials. Here is what I have found:

Jeff Cotrupe

Founder & CEO: MarketPOWER, LLC

Ivan, I was recently invited to do a webcast by TechTarget and the topic I chose was SDPs; you can find this and my other TechTarget webcasts, podcasts and workshops here http://searchtelecom.techtarget.com/search/1,293876,sid103,00.html?query=Cotrupe# , and I have written on the topic of SDPs at the B/OSS Insider blog http://www.billingworld.com/blogs/insider/blogdefault.aspx

Eric Montaut

NGN Solution Architect at HP Intel Solution Center – Altran Team leader

last moriana guide on SDP 2.0 : http://www.morianagroup.com/index.php?option=com_content&view=article&id=148&Itemid=97
You will fine a complete study and the description of the actors in the market at the end of the document with operators case studies.

And, somehow only two companies were mentioned… worth studying, I guess.

I have exposure to eservglobal Inteligent Network products and those are generally good. You may also want to look at jNetX SDP platform for their exhaustive support for all network protocols (IN, IMS,…..). Their service creation tool is pretty cool.

Open Source SDP

While researching SDPs, I saw an open source SDP that made me think (everybody around me said, oh, this is a wrong direction for open source!). Is it so?

Did you hear about open source SMS/USSD center? I had a long discussion with a founder of a company from Uruguay which offers an open source and free USSD center. He likes it that way. I had doubts.

Is it really taking a Telco off the needle or is it adding trouble?

Does open source add value?

Service Delivery Platform Taxonomy: The Who, What and How of SDPs

Useful scheme of SDP structure and components. See attached file.

service-delivery-platform-taxonomy.doc

SDP Alliance

Good source on SDPs

Next Page »