pricing on websites
-
@dashrender said in pricing on websites:
But really, should an O365 migration be a project price and not hourly? You'd have to make the project price significantly more than the anticipated hourly to cover your bases in case there are issues.
Customers want what customers want. Project pricing is essentially always bad, but customers demand it.
-
@mike-davis said in pricing on websites:
The second reason is you can't put a price on a project like an Office 365 migration. At least I can't afford to without knowing a lot of details about the environment.
But you can put a price on the time.
-
@scottalanmiller said in pricing on websites:
@dashrender said in pricing on websites:
But really, should an O365 migration be a project price and not hourly? You'd have to make the project price significantly more than the anticipated hourly to cover your bases in case there are issues.
Customers want what customers want. Project pricing is essentially always bad, but customers demand it.
@scottalanmiller said in pricing on websites:
@mike-davis said in pricing on websites:
The second reason is you can't put a price on a project like an Office 365 migration. At least I can't afford to without knowing a lot of details about the environment.
But you can put a price on the time.
This is why, as @Dashrender suggested, make the project price high enough to cover your time for problems that will arise.
-
I agree. Nothing more frustrating than having to schedule a meeting a week out, sit through a boring demo, only to find (just as you suspected) it was way overpriced to begin with.
If the concern is that the buyer needs to be shown all that value, handle it be making a better website that explains whatever that extra value is.
I have sat through meetings where I did discover things that changed my mind about the higher price, but it could easily have been placed on the website.
-
@dashrender said in pricing on websites:
But really, should an O365 migration be a project price and not hourly? You'd have to make the project price significantly more than the anticipated hourly to cover your bases in case there are issues.
As @dafyre said, customers demand it - and for good reason. They have to make a business case for the project. They would rather have a set fee than roll the dice that everything works the way it should and it might cost them a little less.
-
@mike-davis said in pricing on websites:
@dashrender said in pricing on websites:
But really, should an O365 migration be a project price and not hourly? You'd have to make the project price significantly more than the anticipated hourly to cover your bases in case there are issues.
As @dafyre said, customers demand it - and for good reason. They have to make a business case for the project. They would rather have a set fee than roll the dice that everything works the way it should and it might cost them a little less.
That's fine - post an hourly rate on the website, and if they don't think you're outragous, they'll call asking for a project quote - if they think your hourly is to high, they'll move. As @JaredBusch said - you don't want those that move on anyway.
-
@mike-davis said in pricing on websites:
@dashrender said in pricing on websites:
But really, should an O365 migration be a project price and not hourly? You'd have to make the project price significantly more than the anticipated hourly to cover your bases in case there are issues.
As @dafyre said, customers demand it - and for good reason. They have to make a business case for the project. They would rather have a set fee than roll the dice that everything works the way it should and it might cost them a little less.
How is it rolling the dice, though? You have to roll the dice in the other case, and therefore must charge them enough to cover for that. Plus you have to charge them for figuring that stuff all out (scoping.)
It doesn't protect them, it pretty much just guarantees the worst case scenario.
-
@scottalanmiller said in pricing on websites:
@mike-davis said in pricing on websites:
@dashrender said in pricing on websites:
But really, should an O365 migration be a project price and not hourly? You'd have to make the project price significantly more than the anticipated hourly to cover your bases in case there are issues.
As @dafyre said, customers demand it - and for good reason. They have to make a business case for the project. They would rather have a set fee than roll the dice that everything works the way it should and it might cost them a little less.
How is it rolling the dice, though? You have to roll the dice in the other case, and therefore must charge them enough to cover for that. Plus you have to charge them for figuring that stuff all out (scoping.)
It doesn't protect them, it pretty much just guarantees the worst case scenario.
The reality is that many MSPs don't charge enough to really cover their potential losses (and then end up eating it when it happens) and aren't charging enough to show that it's really just like that hourly will be more cost effective.
-
@scottalanmiller said in pricing on websites:
How is it rolling the dice, though? You have to roll the dice in the other case, and therefore must charge them enough to cover for that. Plus you have to charge them for figuring that stuff all out (scoping.)
It doesn't protect them, it pretty much just guarantees the worst case scenario.I guess it changes who is rolling the dice.
-
@scottalanmiller said in pricing on websites:
It doesn't protect them, it pretty much just guarantees the worst case scenario.
I wouldn't say that. I'm sure some of you have done enough of one thing that you get better than others at it. You quote the customer a better price than others can, but you still make out well because you have become really efficient at it.
Consider a wifi proposal from someone that is not using Ubiquiti vs one of us that has a controller already built.
-
@mike-davis said in pricing on websites:
@scottalanmiller said in pricing on websites:
How is it rolling the dice, though? You have to roll the dice in the other case, and therefore must charge them enough to cover for that. Plus you have to charge them for figuring that stuff all out (scoping.)
It doesn't protect them, it pretty much just guarantees the worst case scenario.I guess it changes who is rolling the dice.
Right, so it doesn't eliminate the risk, it only shifts it. And so your pricing has to be based on covering both your AND their risks - which forces you to pass more risk cost on to them. In the end, they have to lose.
-
@mike-davis said in pricing on websites:
@scottalanmiller said in pricing on websites:
It doesn't protect them, it pretty much just guarantees the worst case scenario.
I wouldn't say that. I'm sure some of you have done enough of one thing that you get better than others at it. You quote the customer a better price than others can, but you still make out well because you have become really efficient at it.
Consider a wifi proposal from someone that is not using Ubiquiti vs one of us that has a controller already built.
No matter how good I get at doing this, it doesn't change that the worst case is what gets passed on to the customer. As I improve my ability to scope, the customer wins regardless of which one of us is left "holding the dice." If the customer holds the dice, they only have to pay what it actually costs. If I'm left holding the dice, the customer has to pay for the worst outcome of the dice PLUS the cost of determining that worst outcome.
No matter how you look at it, scoping and project pricing either results in the vendor losing money by absorbing costs that are not their fault, or the customer losing because they have to pay a premium for not taking on their own risk.
Think of it like insurance. Who wins from warranties and insurance? The insurance companies. Who loses? The customers.
-
@scottalanmiller said in pricing on websites:
No matter how good I get at doing this, it doesn't change that the worst case is what gets passed on to the customer. As I improve my ability to scope, the customer wins regardless of which one of us is left "holding the dice." If the customer holds the dice, they only have to pay what it actually costs. If I'm left holding the dice, the customer has to pay for the worst outcome of the dice PLUS the cost of determining that worst outcome.
No matter how you look at it, scoping and project pricing either results in the vendor losing money by absorbing costs that are not their fault, or the customer losing because they have to pay a premium for not taking on their own risk.
Think of it like insurance. Who wins from warranties and insurance? The insurance companies. Who loses? The customers.Isn't selling bocks of hours up front pretty much bad for the customer as well?
-
@mike-davis said in pricing on websites:
@scottalanmiller said in pricing on websites:
No matter how good I get at doing this, it doesn't change that the worst case is what gets passed on to the customer. As I improve my ability to scope, the customer wins regardless of which one of us is left "holding the dice." If the customer holds the dice, they only have to pay what it actually costs. If I'm left holding the dice, the customer has to pay for the worst outcome of the dice PLUS the cost of determining that worst outcome.
No matter how you look at it, scoping and project pricing either results in the vendor losing money by absorbing costs that are not their fault, or the customer losing because they have to pay a premium for not taking on their own risk.
Think of it like insurance. Who wins from warranties and insurance? The insurance companies. Who loses? The customers.Isn't selling bocks of hours up front pretty much bad for the customer as well?
Why would that be, unless the hours they buy expire.
-
@mike-davis said in pricing on websites:
@scottalanmiller said in pricing on websites:
No matter how good I get at doing this, it doesn't change that the worst case is what gets passed on to the customer. As I improve my ability to scope, the customer wins regardless of which one of us is left "holding the dice." If the customer holds the dice, they only have to pay what it actually costs. If I'm left holding the dice, the customer has to pay for the worst outcome of the dice PLUS the cost of determining that worst outcome.
No matter how you look at it, scoping and project pricing either results in the vendor losing money by absorbing costs that are not their fault, or the customer losing because they have to pay a premium for not taking on their own risk.
Think of it like insurance. Who wins from warranties and insurance? The insurance companies. Who loses? The customers.Isn't selling bocks of hours up front pretty much bad for the customer as well?
He also never said anything about buy blocks of hours up front unless I missed it.
-
If it’s a canned cloud service, software, licenses, or anything that is close to a commodity, it just makes sense to post your options, pricing and features.
I wouldn’t post hourly or MSP pricing.
The value of MSP is that you take on a well defined set of IT responsibilities and deliver a guaranteed result. Per anything pricing is the wrong approach. Has to be a meeting, every customer is different.
Hourly consulting is the same, price is irrelevant in almost every situation.
-
@mike-davis said in pricing on websites:
@scottalanmiller said in pricing on websites:
No matter how good I get at doing this, it doesn't change that the worst case is what gets passed on to the customer. As I improve my ability to scope, the customer wins regardless of which one of us is left "holding the dice." If the customer holds the dice, they only have to pay what it actually costs. If I'm left holding the dice, the customer has to pay for the worst outcome of the dice PLUS the cost of determining that worst outcome.
No matter how you look at it, scoping and project pricing either results in the vendor losing money by absorbing costs that are not their fault, or the customer losing because they have to pay a premium for not taking on their own risk.
Think of it like insurance. Who wins from warranties and insurance? The insurance companies. Who loses? The customers.Isn't selling bocks of hours up front pretty much bad for the customer as well?
Nope, it's the best possible thing for them. Let's them determine their needs, get the best pricing, and not get burned by bad estimates or scope changes. From a customer side, it's literally the best thing I could imagine. Without it, they'd be stuck either paying as they go (which would force everyone into higher prices) or into the scoping disaster. It's the best form of customer protection we could think of.
-
@scottalanmiller said in pricing on websites:
Nope, it's the best possible thing for them. Let's them determine their needs, get the best pricing, and not get burned by bad estimates or scope changes. From a customer side, it's literally the best thing I could imagine. Without it, they'd be stuck either paying as they go (which would force everyone into higher prices) or into the scoping disaster. It's the best form of customer protection we could think of.
Don't you have to estimate the hours to figure out how many hours they need to buy?
Why does paying as you go force higher prices?
-
@mike-davis said in pricing on websites:
@scottalanmiller said in pricing on websites:
Nope, it's the best possible thing for them. Let's them determine their needs, get the best pricing, and not get burned by bad estimates or scope changes. From a customer side, it's literally the best thing I could imagine. Without it, they'd be stuck either paying as they go (which would force everyone into higher prices) or into the scoping disaster. It's the best form of customer protection we could think of.
Don't you have to estimate the hours to figure out how many hours they need to buy?
Not at all. We CAN do that if they want, but they don't have to buy as many as estimated. They can buy what they want and buy more later. It doesn't limit them in any way, just gives them more choices.
-
@mike-davis said in pricing on websites:
Why does paying as you go force higher prices?
Because you have to assume that they are going to just work for an hour, and deal with continuous billing as you go, it creates a lot of overhead and friction and you have to bill with the assumption that you are context switching on and off. It costs more to provide, it costs more to consume.
