Why Salespeople Win or Lose a Sale, According to the Harvard Business Review

I didn’t get into Harvard. Actually, I didn’t even apply, because I definitely wouldn’t have gotten in. I went to a state school for 4 years, and after graduating went right into sales. However, Harvard can still help salespeople who didn’t attend reach the top of our game with their well-researched articles on sales, sales management, and the science behind selling.

In a recent article, the Harvard Business Review tries to identify the reasons why salesperson lose a sale. According to the research, “in the majority of interviews buyers rank all the feature sets of the competing products as being roughly equal. This suggests that other factors separate the winner from the losers.”

Here are the main takeaways from the article, and some advice on what it means for salespeople.

Different customers prefer different selling styles 

There isn’t one selling style that works best. According to the article:

The survey shows 40% of study participants prefer a salesperson who listens, understands, and then matches their solution to solve a specific problem. Another 30% prefer a salesperson who earns their trust by making them feel comfortable, because they will take care of the customer’s long-term needs. Another 30% want a salesperson who challenges their thoughts and perceptions and then prescribes a solution that they may not have known about.

What this means for you:

Always try to read the customer and adapt your sales presentation to their personality. A pushy, confrontational customer is more likely to respond to a challenge, whereas a reserved customer will be more responsive to a salesperson who listens and makes them feel comfortable.

There’s always a top dog 

Another surprising finding of the study was that despite all of the internal politics involved in a company’s buying process, nearly 90% of respondents said that there is always one member of the decision-making committee who “tries to influence and bully the decision their way.” What’s even more surprising is that the person usually succeeds in getting their way 89% of the time.

What this means for you:

Find out who the pushy alpha-dog is. If you can sell them, you’ll almost certainly close the deal.

Learn how to be a more persuasive salesperson with our free guide.

Not everyone cares about price

Salespeople tend to dread the price conversation, but perhaps we shouldn’t. The study showed that decision-makers have different tiers of price sensitivity, and some barely care about the price at all.

…the importance of price falls into three categories. For “price conscious” buyers, product price is a top decision-making factor. For “price sensitive” buyers, product price is secondary to other decision-making factors such as functionality and vendor capability. For “price immune” buyers, price becomes an issue only when the solution they want is priced far more than the others being considered.

What this means for you:

Identify your buyer’s level of price sensitivity by asking the right questions up front. Many customers will indicate whether price is a critical factor or not. Also be conscious of the industry you’re doing business in, as the study shows that different industries tend to have their own levels of price sensitivity.

Charisma helps, but not always

While most of us think that the likable salesperson will get the deal every time, Martin’s study shows that’s not necessarily true. Given the choice of the following three types of salespeople:

A professional salesperson who knows their product inside and out but is not necessarily someone you would consider befriending

A friendly salesperson who is likable and proficient in explaining their product

A charismatic salesperson who you truly enjoyed being with but is not the most knowledgeable about their product

Most people said that they would rather do business with the friendly salesperson. However, this varied depending on industry, with the healthcare and manufacturing industries choosing the “professional salesperson” more than most, and the media and fashion industries opting for the “charismatic salesperson.”

What this means for you:

Being a friendly salesperson who understands their product is always a safe bet, but depending on your industry, you might want to either study your product even further, or work on your charisma if you want to increase your effectiveness.

•   ANDROID
  TRY SPIRO FOR FREE
  You Deserve a Sales Assistant
  Spiro is proven to help salespeople close more deals and make more money.
  
• https://spiro.ai/salespeople-win-lose-sale-according-harvard-business-review/

• 

An essential guide to the serverless ecosystem

Serverless computing is gaining momentum in the IT industry, and for good reason. Despite being a relatively new capability, it has captured the imagination of many technologists with the promise of delivering such benefits as shortened time to market, improved operational and security practices, and a revolutionary economic model based on pay-as-you-go pricing.

You may already understand the essentials of serverless architecture. But what does the overall serverless ecosystem look like, and what options do you have? In this guide I map it all out for you. I'll start with function as a service (FaaS), the linchpin of serverless computing, and expand into the cloud services used for building serverless architectures across major public and private cloud providers. From there I'll review the frameworks and tools you can use when building systems using a serverless stack. Finally, I'll draw the boundaries around "serverlessland" and show you where it lives in the overall world of cloud services.

The essential guide to serverless technologies and architectures

See guide

It all started with FaaS

Despite vendor claims that serverless computing was born long ago, it actually started with the arrival of FaaS. The preview release of AWS Lambda, announced in November 2014, put FaaS firmly on the cloud computing map. (Amazon promoted Lambda to general availability status in April 2015.)

Yes, it was possible to run applications without directly managing servers before FaaS, using Google App Engine, Heroku, AWS Elastic Beanstalk, and others. But those compute services never offered a function-oriented execution model or per-invocation billing. Instead, they usually provided elastic scalability for server- or application-oriented workloads.

After AWS arrived, the other big public cloud providers began working on their own FaaS platforms. Azure Functions was released in preview in March 2016 and became generally available the following November. The preview release of Google Functions was released in February 2016 and promoted to beta on March 2017. The date of general availability is still unknown. There are many other FaaS platforms out there as well. 

Why functions are not enough

While FaaS provides a way to execute arbitrary business logic using the function as a deployment and execution unit, by itself it’s not particularly powerful. The power of a serverless platform is only realized when you can integrate functions with many other services to build complete architectures.

Many people use the terms FaaS and serverless interchangeably, but there's an important distinction between the two concepts.

• FaaS is a compute service that uses functions as the primary abstraction for deployment, scalability, execution, and billing. 
• Serverless is a form of platform as a service (PaaS) that's ideal for event-driven, potentially volatile workloads. It combines FaaS with other cloud services to build complicated systems, while offering scalability, operability, integrated security, and pay-per-use billing.

Serverless platforms: The options

At the moment the most effective way to build serverless architectures is to pick one of the many serverless platforms on offer and take full advantage of all of its capabilities. Here are your choices:

Amazon Web Services

Amazon was the first major cloud provider to roll out FaaS capability, in the form of AWS Lambda.

The power of a serverless platform is determined to a substantial degree by the number and quality of capabilities you can leverage within it. On AWS, functions can be triggered by an increasing number of other services. These include notifications from S3 buckets, HTTP requests from API Gateway, record changes in DynamoDB tables, messages arriving on SNS topics, and Kinesis streams. Lately, AWS has placed more emphasis on FaaS as the primary, or even sole, compute service that integrates with many of the new services.

You can use AWS Lambda functions to power IoT back ends, Alexa skills, conversational bots using Lex, and workflows with step functions. And the FaaS compute approach is being pushed into other execution environments, such as when using functions to augment the behavior of CloudFront, Amazon’s content delivery network, and even into IoT devices, with AWS Greengrass.

As with any other distributed system, building serverless architectures requires excellent support from IT operations. AWS Lambda integrates seamlessly with CloudWatch, the monitoring and logging service. Besides providing out-of-the-box log aggregation and metric collection, AWS CloudWatch lets you use Lambda functions to customize the operational capabilities of the platform.

Functions can be triggered by CloudWatch events (which can support scheduled function execution) and by CloudWatch log streams, and can react to CloudWatch metric alarms via a social network service.

Recently, X-Ray, a distributed tracing service, started supporting AWS Lambda (preview release) so that you can monitor and trace complex data flows. And AWS IAM, the identity and access control service, provides an integrated and fine-grained security model for function execution.

Microsoft Azure

Despite joining the serverless race quite a while after AWS, Azure is making steady progress toward becoming a competitive platform. At this point, Azure Functions can be triggered by Azure Storage blob notifications, HTTP (REST or webhook) requests, events from Azure Event Hubs, or messages from storage queues or service bus queues or topics, or the triggers can be based on a schedule.

Azure adopts a more structured configuration model for its functions. It allows input and output bindings to be attached to the function, greatly simplifying—or completely removing—the code required to integrate with other services from within the function itself. Contrast this with AWS, where the SDK must be used for any form of integration. Similarly, Azure enables a few external integrations out of the box. For example, you can send text messages via Twillio or email messages using SendGrid.

When it comes to operational support for the serverless platform, however, Azure falls a bit short of AWS. Monitoring metrics are only available when using the App Service plan, which requires running a function on virtual machines managed by the cloud tenant. Is that really serverless?

And if functions are executed on the provider-managed compute, no monitoring information is available. Instead, Azure provides a set of guidelines. Also, it defines security policies for functions implicitly, based on input and output bindings, rather than explicitly configuring them using a dedicated service, as with AWS.

Google Cloud Platform

Google has yet to make its Google Cloud Platform (GCP) FaaS capability generally available, but it already provides some of the same core integration capabilities as AWS and Azure. You can trigger Google Functions by Cloud Storage bucket notifications, HTTP requests, Cloud Pub/Sub events, and a few types of Firebase events (Firebase is Google’s mobile-back-end-as-a-service platform).

Operationally, GCP provides well-integrated support for the functions in Google's Stackdriver monitoring service. As with AWS, logs emitted from Google Functions are automatically stored, in this case by Stackdriver. Logging and metrics are recorded by Stackdriver Monitoring, and GCP offers a Stackdriver Debugger that you can use to investigate the behavior of function’s code. That's quite helpful when troubleshooting. GCP’s security model is somewhat different from that of AWS, however, and it doesn't yet provide support for fine-grained security policies.

IBM Bluemix/OpenWhisk

IBM Bluemix is a PaaS offering that includes Apache OpenWhisk, an open-source FaaS/serverless platform with capabilities similar to offerings from the big three public cloud providers. Because OpenWhisk is an open-source project, you have complete visibility into the workings of the FaaS platform, and it's extensible and customizable. When running Bluemix, you can run OpenWhisk on your own infrastructure on-premises, in the cloud, or as a fully managed platform.

Functions (called "actions "in OpenWhisk) can be triggered by HTTP requests, messages from Apache Kafka or Message Hub topics, changes in Cloudant noSQL DB tables, scheduled events, or virtually any type of external system, provided an integration has been created for it.

From an IT operations point of view, OpenWhisk focuses mostly on the visual presentation of activities associated with function execution but also allows command-line interface-based polling for activity logs. Sadly, metrics, logging collection, and storage are not yet available, and the security model is not very well defined or documented. Developers may need to manage it explicitly, without a great deal of support from the platform.

Other FaaS platform choices

Many other products and projects are competing for a place in the serverless space. Some only offer FaaS capabilities (optionally with HTTP access to functions), while others provide a few other services, such as messaging or storage. Most started as BaaS providers and have rebranded themselves as serverless products. A few of note include: 

• Iron.io, one of the most complete platforms in this group. It offers a FaaS product called IronWorker, as well as a distributed queue service (IronMQ) and cache service (IronCache).
• PubNub, which allows for arbitrary code, called blocks, to execute within real-time messaging flows while it takes care of managing scalability of the compute stack.
• Webtask.io, a mobile BaaS platform that you can use for running arbitrary code. It's packaged as "webtasks" and offers good support for creating Slack bots.
• Hook.io, a similar product that offers its own key-value data store, as well as integrations with many cloud storage services.
• You'll also find many open-source projects that provide FaaS abstraction on top of container schedulers. These include Funktion, Fission, Kubeless, Funcatron, and FaaS.

Frameworks and tools

While serverless platforms sounds great, they don't always offer the best developer experience. That's why it makes sense to create or use frameworks and tools. In fact, the serverless space is experiencing something like the Cambrian Explosion when it comes to available tool options. New offerings are emerging rapidly, and you have many choices.

The Serverless Framework (formerly JAWS), which offers integrations with all major platform providers, is the most popular option today. Others you might consider include Chalice (Python, AWS), Zappa (Python, AWS), ClaudiaJS (Node, AWS), Dawson (Node, AWS), Shep (Node, AWS), Sparta (Go, AWS), and Lambada Framework (Java, AWS).

Besides frameworks, you can find many tools that can help you build and deploy functions or serverless architectures. For example, you can use HashiCorp Terraform as an alternative to your provider's own infrastructure-provisioning capabilities (such as AWS CloudFormation). Other popular tools include Apex, Gordon, and Kappa.

Where serverless fits in the cloud computing landscape

Many technologies and products provided PaaS and BaaS capabilities before either FaaS or serverless became popular. You had lots of SaaS products offering anything that could possibly be consumed either as an end-user functionality or a third-party product that could be integrated into an application or a system.

These categories are still relevant now, even with FaaS and serverless entering the cloud computing landscape. To recap:

• FaaS is a high-abstraction compute service where the service provider takes full control over managing compute resources, including the runtime process executing the code.
• Serverless describes a specialized PaaS that combines FaaS for compute with other managed cloud services in order to create scalable architectures that are cost-effective to operate.
• BaaS offers back-end capabilities to browsers or mobile apps. It can be delivered on top of the serverless stack, as well as on a container-as-a-service (CaaS), infrastructure-as-a-service (IaaS), or other technology stack.
• SaaS just means any software-based system offered without the need to run it on your own infrastructure. SaaS systems can be built on any technology stack; what matters is how users consume it.

No doubt, the word serverless will be used to describe all of these other services, and that may confuse many people. But that’s okay, as long as in the end the IT industry experiences even greater innovation. Your businesses will certainly benefit from the increased business agility that comes from adopting serverless computing.

https://techbeacon.com/essential-guide-serverless-ecosystem?utm_source=DevOpsLinks&utm_campaign=4b90804336-DevOpsLinks_62&utm_medium=email&utm_term=0_90ee2dcd56-4b90804336-292776361&ct=t(DevOpsLinks_62)