What CIOs really want is somebody to step in and make it all work. As a result, you’ll find that most value propositions around the cloud begin with "let me do it for you."
Enterprises can be more agile if they don't own the equipment. And they can use an OPEX-oriented business model instead of dealing with CAPEX and depreciation. Plus, they don’t have to worry about warranties, maintenance, obsolescence, day-to-day operations, nor capacity planning.
Dan: How do you adapt your Lego-style model to meet the enterprise’s unique requirements?
Joe: Dan, the enterprise wants to see an integrated design, but it’s our job to ensure the design is flexible enough to accommodate changes.
For instance, today our Unified Communications (UC) offer, Sprint Complete Collaboration, rides on a Cisco HCS (hosted collaboration solution) platform and supports up to 10 clients per seat. Now some would say using a template with 10 clients per seat is overkill because if the user has a laptop, tablet, smartphone, and personal device, 5 clients should be enough, but we don’t want to limit the customer’s flexibility and choose to include this capacity.
But being an efficient solutions provider means having a good starting point, while recognizing you will need to modify your templates to meet the client’s special needs. So by designing up to 10 clients per seat we can adapt more quickly to varying customer needs over time!
The important thing to remember is that when you collect the customer requirements you are designing to win the business, not designing to provision quite yet.
It’s no different than hiring an architect to design your vacation home. On the first visit the architect shows you some house designs based on an initial conversation.
The architect expects to gather your specific requirements, like a two–car garage, an extra bathroom, and a big deck for BBQs. So the architect will then go back to their studio to adapt the generic house plan to suit your needs and budget.
The same is true for enterprise cloud. You start with a generic design, but recognize that collecting additional requirements is not only necessary; it actually demonstrates competence and wins the enterprise client’s trust, and then the order.
At Sprint we understand clearly that business is won or lost in the proposal phase. Automation is crucial since it allows us to efficiently create winning proposals with lots of design flexibility. You can’t do that if you’re creating proposals via spreadsheets and Visio. There are too many design considerations to track and cost out.
A collaborative tool is critical because so many people are involved in the process. At Sprint, our sales people are responsible for everything we sell. By necessity, we collaborate within our account teams, including multiple solutioning functions, implementation personnel, and multiple provisioning organizations from inception and then repeated throughout the customer lifecycle. At Sprint, using the collaborative design tool is a requirement.
Because everyone benefits from the tool and its embedded rules, configurations, and vendor information, we don’t have design inaccuracies or downstream provisioning errors. I’m being honest when I say the error fallout is minimal – customers love the result.
Dan: Thanks for these fine insights, Joe.