-
-
-
First off I agree that the ICE service should not be free, but for it to be worth while from a business standpoint, and at $20 per month paid to Adobe, the "web shop" would need to charge at least $10 per month to each client to use the service. It's a given that most clients won't want to pay more than $10 a month for the ICE service unless their web site is a large one. So if Adobe needs $20 a month for 5 domains in the current price proposal, the web shop would need to have 2 clients using it right away just to break even and acquire 3 clients just to start making a profit. The proposed pricing model puts much more "pressure" on the web shop's side to sign people up on the service as fast as possible starting out. The situation becomes even more evident if the web shop has 6 clients and is now paying $40 a month to Adobe for two base accounts. With 5 clients and one base account the web shop profits $50-($20 to Adobe)=$30 total per month. With 6 clients and two base accounts the web shop profit takes a dip with $60-($40 to Adobe)=$20 total profit per month. So the current pricing model becomes a kind of stair-stepping profit and loss situation for the web shop when they don't have each base account "loaded up" per say.
A MUCH better pricing strategy for both Adobe and web shop owners would be for Adobe to create an initial 3 domain base account for $10 a month and then "throttle the price" for each additional domain. This would lower the initial profit risk for the web shop greatly. Let me illustrate... Let's say Adobe charges a base price of $10 a month for a 3 domain base account to start with. Then for every NEW domain there is an additional $5 a month charge. Ok, so let's say the web shop has 5 client domains... now we have a a base price of $10 (3 domains in the base) + 2 NEW domains and that's a total of a $20 total per month paid to Adobe. Now for 5 domains Adobe is STILL making the $20 a month it needs. At this point though, the web shop has 5 committed ICE clients and is charging a minimum of $10 per domain so they receive $50 per month minus the $20 paid back to Adobe for a total profit of $30 per month. If the web shop has 6 client domains then the total profit is $25 to Adobe rather than having to pay $40 per month with the current proposed pricing model. Now we must look at how this pricing strategy "benefits" Adobe, because at 6 domains Adobe was previously getting $40 for two base accounts with 5 domains in each. BUT if they go with a throttled pricing model those same 10 domains now would mean $45 per month ($10 base + 7 new domains at $5 each for $35) instead of the previous $40 per month for Adobe. Ok, wait a second (I can hear most of you saying it now) why would we now pay Adobe an extra $5 per month for 10 domains? The answer is simple, because previously they would be getting $40 a month for say 6 domains whereas now they would only get (($10 + 3 new domains x $5 each = $15)) = a total of $25 per month for 6 domains. This is very fair because Adobe now takes on a lower rate per month as the domain counts ramp up, but now at the 10 domain mark they would be getting $45 per month instead of $40.
Overall this strategy eliminates the starting risk for the web shop, ensures the web shop's profit right away, and in the long run Adobe profits a little bit more for higher domains counts. Both sides get a much better deal with a throttled pricing model!
And as a last note of "profitable hope" for the web shop readers, you could also base your ICE monthly service price on the size of each client's web site. For example: 20 pages or less = $10 per month, 21- 50 pages = $15 per month and for large web sites above 50 pages you could go with $20 per month. This is actually still fair, because if you think about it you still have to provide ICE code support for each page should something go wrong and provide support for ICE user e-mail questions, training, etc. So the more page support you have to deal with code-wise, e-mail-wise, or even phone-wise the more it should justify a higher monthly cost back to your client for having a larger web site to maintain overall.
| -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Whoa, haven't been here a while - let me try to get a handle on this whole thread
.First off, thanks for being a PageLime champion here Russ, and I don't think it was fair that people suggested you were somehow involved with us. We speak out for ourselves
.So - here's my take. PageLime is a more feature rich app than InContext hands down. I don't want to get into a feature thread, so I'll focus a bit on some implicit benefits: The two guys who started PageLime, Emil (me) and Tom, are two guys with an email address (emil[at]pagelime.com and tom[at]pagelime.com). You can reach us any time to get PageLime support issues fixed, get ideas, ask questions, or just share links (we like cool youtube videos too). Heck we even pop up in people's gmail chat. Sure, you can post in our forum or on our feature suggestion system too - but the way we feel is that if your client has an urgent issue, you should be able to email or call us. On that note - our roadmap is for the most part public (pagelime.uservoice.com) - it's whatever people want. Ultimately, we like to directly communicate with our users and we're honest about our product.
Ok, touchy feely stuff out of the way - Captain Slocum brings up two points: he had trouble signing up, and he didn't feel like our WYSIWYG is as good as InContext. I sent him a personal note and I want to make sure we address both of these.
I personally get both direct feedback messages whenever there's a bug, and a detailed automated log with the last action the user took, and a full description of the problem. As with any product (this isn't my first rodeo) I get quite a few of these every day (most are various FTP and firewall issues for different hosts), and I really try to reply to every user who has a problem. I open up an email, and ask if there's any way I can help. (I'm sure I get flagged as SPAM by default by most email providers by now
).As for the WYSIWG point he brought up, I'm on the fence here. Here's why: InContext has true inline editing, while we have open up a little overlay where you type in your changes, and then click OK and those get rendered into the page in real time. I agree that it's better to have true inline editing, but InContext is so early in the product cycle that they haven't had to deal with some of the things we have: SIFR, Cufon, Javascript animated slideshows, etc. And all of these don't play nice with true inline editing. We're working on a prototype that does, but even if it is ready for release in Q2 2010 we can't guarantee that the 1000s of PageLime users will want it this way.
Short story: Product Management isn't a super easy job - and I don't envy Adobe's position in this whole story at all. The more specifics they commit to, the less flexibility they'll have in the future to change their product without upsetting their user base. I just feel that the difference is that PageLime's going to be honest and transparent about this process. That's a promise.
Definitely reply or reach out with with any feedback.
| -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
![[S]up](/people/%5BS%5Dup/avatar/30.png?a=1002){kind=small}
- 10 points awarded for Correct Answers
- 5 points awarded for
-
10,000+ points
-
1,001-10,000 points
-
501-1,000 points
-
5-500 points
-
