pricing on websites
-
@mike-davis said in pricing on websites:
@dashrender said in pricing on websites:
@mike-davis said in pricing on websites:
@dashrender said in pricing on websites:
Why and to what end?
I don't have my hourly rate on there. The reason for that is I have a different hourly rate for different clients.
So you list the highest rate on the site, and if you get a new customer, you can offer a discount based upon a contract, etc.
and then you run the risk of scaring people off...
You don't want those people anyway.
Note: Not on our website either, but not my call.
-
@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.
That is a project, not an hourly rate. projects are based on hours, but hours cannot be determined until they are analyzed.
-
IT Services rates are not broadly standardized like other professional services yet. It is coming, but it is not there yet.
Mostly this is do to the extremely low barrier of entry caused by the idiots that sort of know something about a computer and the common person being so dreadfully fucking stupid.
-
@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.
I'm not sure you need to price something specific like that.
You might list something like
Cisco firewall support $200/hr
Windows desktop support $100/hr
Unifi hardware support $150/hr
etc
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. -
@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.
