Archive for November, 2008

What’s the Right Price for Service?

If you’re buying, or managing, a contract service, this is the big question.

Yet it feels more like a riddle than a question.

And like a riddle, the answer is simple and complex at the same time.

The Simple/Complex Answer

“The right price for service is paying for what you’ll get.”

I know, it’s a very disappointing answer. Overly simple. But complex too.

Let’s break it down into smaller parts to wrestle with its simple complexity. Here goes:

#1 Price is a Beginning Number
#2 Selecting the Right Price Before Service Delivery
#3 Value is What You Get

#1 Price is a Beginning Number

Price, agreed to at contract award, doesn’t include the additional costs of ownership. The invisible ones that always show up over time.

If you asked a time and motion consultant, they’d quantify the time you and your staff invest, and then translate that into dollars.

These hard-to-see costs are from the time you’ll spend on:

  • Contract compliance
  • Performance management
  • Vendor communication & coordination
  • Accounts Payable
  • Correcting service deficiencies and/or disruptions
  • Mitigating impacts of sub-par service on end-users

These soft costs are added to the price to become the Total Cost of Ownership.

ACTION ITEM when determining the right price for a service

The first step is to quantify the soft costs that increase the Total Cost of Ownership. Identify those soft costs that would be constant for whichever contractor you’d choose. Then determine how that baseline may vary for each contractor. And they can vary significantly from one service contractor to another.

#2 Selecting the Right Price Before Service Delivery

When buying a service you’re making the purchase decision before you know what you’ll receive. Service is delivered over the life of the contract.

But you have to choose how much you’re going to spend before service starts.

You’re buying on good faith. You’re selecting a contractor in the belief they’ll:

  • Comply with contract requirements
  • Meet your service specifications
  • Deliver as promised

ACTION ITEM when determining the right price for a service

The next step is to assess the contractor’s mechanisms for delivering, ensuring, improving and reporting service.

In particular, how contractors would do that for your specific site(s). Not a general explanation, but a specific proposed solution.

#3 Value is What You Get

Hopefully the value received from service will be equal to, or more than, your investment, which is your Total Cost of Ownership.

This is “getting what you paid for”.

But it’s difficult to nail down the value received from a service.

We’re not talking about completing specifications or contract requirements. This is about “how did this service contribute to your company’s business success”?

Sometimes you can’t even tell if a service had been performed, much less if you’ve benefited from it.

And making the connection between a support service and its contribution to your company’s success is not easy. It’s not a 1-to-1 cause and effect.

Intuitively we know service contributes to a firm’s success. But there are always other factors, other contributions.

For example, one can’t state absolutely that exceptional janitorial service directly increased the customer company’s revenue or expanded the customer’s market share.

ACTION ITEM when determining the right price for a service

Challenge contractors to articulate how their service will have a positive impact on your business results. Get explicit descriptions of value.

Not just how well the service is performing as seen in Key Performance Indicators (KPIs). But ask them to make the connection to your firm’s success. Then create KPIs to track those as well as the service KPIs.

How do you determine the right price for the service you’re buying?

Chris Arlen
President, Service Performance

Technorati: total cost of ownership, contract services, KPIs, service pricing

Image by Gilbert

Add comment November 20th, 2008

Software is NOT a Service – It’s a Tool

Software is not a serviceA client of mine recently signed up for Salesforce.com. Actually, a number of clients are using it already, or are considering it.

Salesforce.com is a Customer Relationship Management (CRM) solution. It calls itself a Saas (Software as a service, typically pronounced ’sass’).

However, software is not a service.

Signing up for it doesn’t make anything happen.

Until the user uses it. And that means users have to first know what they’re supposed to be doing. The business process part of it. The part that enables one human to interact with another. Whether it’s a salesperson with a prospect, or a support tech with a customer.

And that’s what got me thinking.

After 21 years of working with facility services, it’s abundantly clear that software isn’t a service. It’s a tool. A powerful one, but just a tool all the same. It lacks the liveliness of engagement.

Why does it matter that Software isn’t a Service?

Calling software a service determines how a company thinks about services in general. And that influences how services are purchased or managed.

And if you’re an outsourced service provider, that can be a huge problem.

Your customer’s expectations may default to those of software, which may include some variation of:

  • Utilizing its full capabilities – how many service employees would be considered Power-users in delivery?
  • 99.99999997% quality – an unrealistic expectation for services
  • Robotic levels of consistency – wishful thinking from a human delivery system
  • Absolutely 100% defect free – which is possible in a perfect world, but not ours

When customers have service expectations associated with software, trouble is close at hand.

The Nature of Service is….

#1 Intangible

You can’t see it when it’s delivered. It’s just there.

#2 Heterogeneous

It varies each time it’s delivered. It physically can’t be deliverd exactly the same way from one instance to the next. Time itself makes that impossible. Aren’t you a second older now than you were a second ago?

#3 Produced in front of the customer

It’s not a product that’s manufactured in a plant, QC’d to perfection, and then shipped to the customer. It all happens right there, in front of them. Customers get to see service production 1,000s of times a day.

Service can be defined as…

An interaction between humans for the exchange of value. It’s the interaction that counts, as far as services are concerned.

Software tools help manage information, improve communication connections, and create informational objects. Great uses of tools.

But customers seek the human connection. That’s the service part. Even if going through email or Live Chat.

Think email and Live Chat make a case for software as a service? As an online support service?

Think again. They’re tools that can be part of a support service, but are tools only. By themselves they don’t accomplish anything.

But when support techs respond, then service takes place. And that’s the valued interaction – cool tools or not.

Calling Saas as I see ‘em

If service providers believe Saas and strive to make their services more like software, they’re doomed to fail.

And they’re missing out on the truly valued customer opportunity that services present: that of making a connection between one human to another.

That’s the part technology can never replace, even as software becomes more sophisticated and intelligent.

Recognize what service truly is and rejoice in it. And make that your competitive advantage. You’re human after all, and that’s really what other humans want to connect with.

How do you think about services?

~~~~~~

Chris Arlen
President, Service Performance

Technorati: CRM, Saas, Salesforce.com, Software as a service

Image by hobvias sudoneighm

Add comment November 11th, 2008

More about Scenario-based RFPs

Scenario-based RFPsOur recent monthly Revenue-IQ article, Time to Change the RFP Game?, struck home with a number of service contractors and customers.

Both sides of service contracts recognized the Request for Proposal (RFP) process is broken. It brings pain, frustration, and lesser value – for customers and contractors.

Contractors definitely felt RFP pain. One contractor mentioned they’d just participated in an online auction and wouldn’t be repeating that train wreck again.

Another contractor noted the additional work customers would have to take on in a Scenario-based RFP and he wasn’t sure they would.

It’s clear a better RFP process is welcomed. The comments above (and more noodling) have prompted today’s post. Here are a few more points about Scenario-based RFPs to consider:

  • RFIs (Request for Information) Are More Than An Exercise
  • Evaluating Contractors’ Proposed Solutions
  • Where’s Pricing in Scenario-based RFPs?
  • Piloting a Scenario-based RFP

RFIs Are More Than An Exercise

The RFI becomes a required part of Scenario-based RFPs. RFIs weed out unqualified contractors, and end up with a short-list of approved ones. This makes it much easier for customers to select the best value from qualified contractors.

The effort customers will put into RFIs will be made up from easier and more effective Scenario-based RFPs.

Evaluating Contractors’ Proposed Solutions

RFP evaluations would change. The focus would shift to selecting the best value.

Customers wouldn’t have to determine if the contractors were qualified to deliver the solution. Only contractors who’ve been RFI approved are allowed to propose solutions.

Scenario-based RFPS would require customers’ business owners to:

#1 Determine the practicality of the proposed solutions.

#2 Judge how great an impact the solutions have on the customer’s business results.

#3 Assess contractors pricing relative to #1 & #2 above

#4 Select the contractor with the best value for the spend

Where’s Pricing in Scenario-based RFPs?

Pricing would only be calculated into the evaluation AFTER assessing contractors’ solutions. Pricing could follow the typical weighting and rating evaluation exercise.

Yes, it’s the real world, so pricing will likely have a higher weighting than other evaluation categories. But in the Scenario-based RFP, pricing is the LAST variable for consideration, not the first.

Hypothetical Example

Imagine a customer’s decision makers sitting around the conference room table. They’re discussing the most compelling solution proposed. It’s obvious which one it is, they’re all in agreement.

And that contractor’s pricing is in the middle of the pack, say 3rd lowest out of 5 contractors.

Those customers would have to decide whether they

a) Select the most compelling solution as is – but get the most value, or

b) Negotiate with that contractor for lower pricing – possibly jeopardizing best value, or

c) Select a lower priced contractor

In any case, customers will be making decisions with their eyes wide open.

They’ll be able to clearly justify their decision. It’ll be based on expected contributions to business results. This justification, should it ever be needed, will be concrete if communicated higher up the food chain. This is rock solid CYA.

Piloting a Scenario-based RFP

As with any new initiative, it’s best to test it away from the spotlight. You’ll want elbow room to maneuver and course correct if needed.

An ideal customer candidate might be a small service contract. One with a progressive customer business owner and a handful of willing contractors.

The primary purpose of the pilot program is to learn how to make the process better. After completing the pilot Scenario-based RFP hold a formal post-mortem and figure out:

i) What worked?
ii) What didn’t work?
iii) What could be better next time?

Including the customer’s business owner, procurement and selected contractor will provide the insight to improve the next Scenario-based RFP.

That’s Not All

Obviously there’s more to be developed for Scenario-based RFPs before they’re viable. But in the absence of better RFP alternatives, it may be worth pursuing.

~~~~~~
Chris Arlen
President, Service Performance

Technorati: best contractor value, RFI, RFP

Image by gutter

Add comment November 5th, 2008


Calendar

November 2008
M T W T F S S
« Oct   Dec »
 12
3456789
10111213141516
17181920212223
24252627282930

Posts by Month

Posts by Category