SUBSCRIPTION PAYMENT FORM (II)

SUBSCRIPTION PAYMENT FORM

Date: 19-09-03

To: Kartavya / Abhi

cc: Sanjeev

Subscription Payment Form (II)

Yesterday I sent you a draft form for your consideration.

Enclosed find a second draft.

You will notice that the extreme left-side column has been modified slightly.

It became obvious to me that if the same form has to be used both for FIRST-TIME Subscription as also for RENEWAL Subscription, then at the very outset (right at the beginning), the customer must tell us what case ours is.

Form should capture that info first, viz.:

☐ First Subscription

☐ Renewal Payment

Obvious because, in case of Renewal of payment, only Transaction Fees are to be considered.
There is no question of Activation Fee or of User License Fee.

Word “Renewal” is somewhat misleading.

Here, I am not talking of renewal of Annual User License.

(Incidentally, will that require a separate online payment form?)

What I had/have in mind is that I have received an email from RecruitGum server, telling me that:

“Of the Rs. 50,000/- Net Transaction Fees that you had paid

On (date) ___________

Vide (Cheque/DD) ___________

now, balance left is Rs. 4,394/- (i.e. less than 10% of original last payment).”

We are sure you have been happy using services of RecruitGum and would want to continue using it without interruption.
In that case, to enable us to continue serving you, we request you to deposit some further amount (towards Net Transaction Fees) by clicking here.

So, may be, we should change from

“Renewal” → “Additional Transaction Fee Payment.” ⭕

By clicking on this email I come to

“SUBSCRIPTION PAYMENT FORM”

where I click on

Additional Transaction Fee Payment ⭕

and next, enter my User ID / Password & click Submit.

The moment I Submit, two things should happen, viz.:

#1
My customer data appears in the left column

(→ picked up from Free Trial Registration / Customer Database).

I have an option to edit.

#2
The top portion of the right-hand column changes, as shown in enclosed (draft).

Draft II

Obviously, since client has chosen

Add. Transaction Fee Payment ⭕

mode, there is no need to show him/display:

• Activation Fee
• User Fee
• etc. etc.

So, this corner can conveniently display:

“Your Account Credit Balance (for Renewals)”

So that he gets to know:

→ What amount he had credited last time, and when (date).

(Net Transaction Value only)

→ How much of that he has used up till today?

→ How much is balance as of today?

Now, knowing that he used up Rs. 40,000/- in 4 weeks

(by way of Transaction Fees) —

{ or whatever }

He can decide whether to make a further deposit of

Rs. 10,000/- or Rs. 5 lakhs.

Thus, a better design of the right-hand top corner, in some clever way, our form/software should highlight the speed / rate at which he is using up his credit:

Rs/day or Rs/week → Your Average Usage (Transaction Fees)

This is much like looking at your fuel gauge and mentally computing that

“Now I have enough fuel left for just 5 km!”

And then (even better) —

When I fill up 40 litres of petrol, if the counter gets reset and shows me that “Now I can go 400 km!”

Here, in our case, we (i.e. software)…

…should announce:

“Thank you for your fresh deposit of Rs. 2 lakh!

At your current rate of usage, this amount should suffice for next 7.3 weeks.”

⊕ Current Usage = Rupee value of transaction-fee consumed during last 7 days (1 week).

I am myself not happy with the way I have re-designed right-hand top corner, but I am sure you can do a much better job.

(signature mark at bottom)

Kartavya / Abhi / Sanjeev

SriRam / Raju / Nimrit

Date: 16/09/03

Page 1/6

Web-Service Pricing

In our meeting 2 days ago, I pointed out important guidelines regarding pricing of our RecruitGum web service, viz.:

---

INDUSTRY-STANDARD

Our pricing strategy must enable us to become the de facto Industry Standard.
This means — any competitor who enters the venture into the area of Recruitment Web Services would need to follow the “practice set by us.”

This is because the market expects the following category of pricing standard, which can be easily compared with the structure already established by the leader/pioneer.

If the next provider of Recruitment Software wants to charge by hour/per month etc., he would have to satisfy Indian Corporates who have already got used to RecruitGum’s per-click model.

In essence, we, as pioneers, must set / establish the “RULES OF THE GAME”, by which this entire new industry must play the same!

DYNAMIC

Our pricing structure must be dynamic.

We should be in a position to change it over a period of time — and as frequently as deemed necessary.

We should be able to make this “change” online (through Admin) so that automatic email announcements go out to:

• Existing Clients
• Potential Clients

Whereas for potential clients, the new structure becomes applicable (thus revised tariff chart) instantly,
for existing clients, it will become applicable when their current credit balance becomes NIL / ZERO.

They (the existing clients) must not be in a position to “cheat” us by depositing another cheque for Rs. 5 lakhs the moment they hear that the per-transaction prices are going up!

(If the new prices announced are reductions, i.e., going down — I have some solution, and Sanjeev must come out with his proposals.)

MASS-CUSTOMIZATION

Our pricing-structure must enable us to “customize” price for each & every (paid) mouse-click, for any given customer.
So, if there are 2000 customers, theoretically we can have 2000 different prices for (say) “EXTRACT” button!

So, if we have 5 paid-for (not free) buttons, we would have 2000 × 5 = 10 000 prices!

We (Sanjeev) must use this (fantastic) mass-customization feature to extract maximum money out of each customer — all the while giving the customer a feeling of being served uniquely / special treatment.

And for extracting more money out of each client, Sanjeev will every month closely examine the CUSTOMER-WISE USAGE / REVENUE / SERVER-LOAD graphs shown in Annex-I. This study will tell us

• In which customer click patterns →
• In which mouse-clicks we are losing out money ( mouse-click = cost + price – profit ).
• Analysis as shown in “CUMUL GRAPHS.”
• Which mouse-clicks are loading our server most.

 

LOCK-IN

One — perhaps the most important feature of any pricing structure — is to “Lock-In” the Customer & then make him pay for the rest of his life.

This is why drug-peddlers offer free drugs in the beginning — once you get addicted, the extortion process sets in!

This is exactly what Reliance has done by offering mobile handsets for mere Rs. 501, and then make you pay Rs. 200 p.m. for 36 months. If you want to quit halfway, you’re forced to refund Rs. 8000 / 5000 / 3000 ( i.e. 2 / 1 ½ year ).

Of course, a subtle and unseen way of locking a customer is the “Non-portability” of your mobile no. If you’ve given out this no. to hundreds of friends / relatives and most worse, to your customers, friends — you are locked for life! The cost of shifting over to another service provider is so much higher that however excellent it will be in technology — you won’t budge!

This is why we should price our “extraction / conversion button” at no more than Rs. 5 ( or even Rs. 2 !) — so that, having converted 1 lakh / 5 lakh resumes, customer has no choice but to remain Locked-In!

The actual “cost of conversion” is irrelevant to our pricing strategy, which must remain geared to our “locking-in” strategy.

Remember that we have to make money overall from each customer.

This would require some buttons / some mouse-clicks getting “subsidized” by some better-paying / better-yielding mouse-clicks!

So what is far more important is to clearly figure out → and then improve ARPU (Average Revenue Per User / per month of usage!)

Customer Base : 432 (as on 16 Sep 03)

(hand-drawn graph)

Monthly ARPU = Rs. _____

The diagram shows:

• Bad Model: peaked early, low ARPU.
• Good Model: higher-value users sustain revenue.

Below it, the same curve is re-plotted as:

Cumulative Monthly Revenue (CMR) versus Cumulative No. of Customers — showing that as more customers come in, total revenue flattens out if pricing isn’t optimized.

At a glance, such a monthly graph would tell Sanjeev:

→ Which (few) customers are MOST VALUABLE and deserve maximum personal attention (CAKE)
→ Which (large no.) customers are GOOD VALUE and deserve regular email communication to encourage them to stay on or increase their usage (BREAD)

→ Which (few) customers are VALUE-LESS and deserve to be politely got rid of (The CRUMBS!)

---

And — more so — a web-service enables us to carry out real FINE TUNING of our pricing dynamically over a period of time, in respect of each customer so that, someday, our ARPU graph looks like this:

(hand-drawn symmetric “bell” curve labelled “Possible – if we are clever!”)

16 / 09 / 03

(signature mark)

 SOME ISSUES

9 Sep 2003

Kartavya/Abhi/Sanjeev

SOME ISSUES

·     Speed of Extraction :

You mentioned that currently this is around 500 resumes / hour, and that, it will gradually improve as more & more resumes get processed & we remove the bugs.

Earlier, I had sent to you a note where & I had suggested hosting a “Extraction accuracy Index” graphically.

On same line, we can have a “Extraction speed Index” also.

·     Free Trial Period :

Although we are starting with 30 days, as time goes-and especially if we get a very good response- we may want to decrease this period to 15 days & may be at a later date, to even 7 days.

So, there can be periods when there is an “overlap”, with some corporate having a 30 day period & some corporate having a 30 days period & some having 15 days. Our software should allow for this and terminate the services (i.e. free services) accordingly, unless of course, a corporate has chosen to become a REGULAR PAID subscriber, before the end of his free trial period.

5/7 days before the “end-date” of each corporate Free Trial period, an automatic email should go out to that subscriber, using him to become a regular/paid subscriber. I believe, I have already sent a draft to sanjeev-if not he can draft one. This reminder should be part of software.

·     Email Marketing :

As of yesterday, deepa has compiled a mailing list of 31171 corporate (names of co/email ID) from various sources. This list will keep growing as we  keep extracting co-Names from 3000/4000 job-advts. Which we are downloading daily. In course of time we will also get manes (but not email ID’s) of many companies from extracted resumes also (only resumes submitted directly on Recruitguru.

As far as resumes which a subscriber uploads for extracting is concerned, we have promised, not to compile this info)

I have already drafted some 9/10 letters for emailing to these 31171 companies, to promote/introduce Recruitguru.

My plan is to send first email, then wait for 8/10 days & send second mail, then wait again for 10/15 days before sending third and so on.

Obviously before sending out each mail, sanjeev will ensure to remove from the mailing-list, names of those companies, who have in the meantime, registered for free trial.

We do not want to annoy them!

But the best way to entice more & more corporate (to register for free trial), is to give them some “statistics” with each round of email, as shown in Annex.

The emotion that we want to play upon is

“keeping up with the Joneses”

People are curious by nature. If they see a small crowd on the road, soon it becomes a large crowd.

It is no different with corporate! They too have a “ herd” mentality!

This (statistics) would be all the more powerful, if the names of

·     Free Trial wallas

·     Regular Subscribers

Contain some large/reputed companies (early adopters). The effect rules on.

I am sure you have already planned to compile all the figures mentioned in Annex. It is merely a question of making these available to sanjeev, at whatever frequency he wants. In any case, I would like to see these on my PC screen DAILY (for previous day & cumulative) besides weekly/monthly.

ANNEX :

Hemen Parekh

GURUSEARCH SCREEN

4 Sep 2003

GURUSEARCH SCREEN

Abhi/Inder/Sanjeev/Raju/Sriram,

Present UI is not very intuitive. It is a bit cluttered and looks quite like other jobsites.

We want recruitguru to “differentiate” from all other jobsites-in as many respects as possible so that corporate do not confuse us with other jobsites! We have to be in a class of our own.

Enclosed find & alternatives of search screen.

No. 1 – Only a little more “rational” grouping

No. 2 – Brings focus to “Function” & “Percentile” which is our USP & this is where we would, ideally, want a corporate to start/being his search.

Perfectly, only after he gets to see the “results” based on col#1, he should move right – to col#2 -#3

No. 3 – Here col#1 is same as in option #2 some interchange is made in middle & extreme right column.

No. 4 – This vertical flow alternative –with explanatory notes on the right hand side, is I feel, the best alternative. It provides the “rationale” behind the correct/ideal

It is like leading a child with finger! Step-by step, in the right direction & in correct “Order”/with least confusion/without having to “back-track”-in case you get into wrong lane/dead-end street.

Please consider implications with your team then let us decide.

Date: 18-09-03

To: Kartavya / Abhi

cc: Sanjeev

Subscription Payment Form

Enclosed find my suggestion/proposal.

Points to be noted / considered:

• I am presuming that a customer would have first filled up FREE TRIAL registration form before wanting to fill up this form.
• That means:
• He has already given us his company details.
• We have issued him:
• → User ID
• → Password
• → Customer No.
• I am again presuming that before coming to this form, the customer has already logged-in first, so we know who he is.
• That would enable software to pick up data from his FREE TRIAL form and automatically display it in the left-hand portion —
• “Subscription Payment Form.”

 

  Extreme right portion of the form is designed to be used by customer, as a kind of

WORK-SHEET (Rough Calculations).

He can keep changing the figures that he enters into the second column from right.
As soon as he enters any figure in this column, software computes & displays value in the last column.
This helps him arrive at the overall amount that he will need to remit.

Of course, somewhere (Tool-Tip), we must make it amply clear that:

“Individual Estimated Monthly Usage figures and values appearing in last column do NOT bind/restrict him from using any one transaction more than any other transaction less than the figures indicated by him.
Provision for individual numbers/values is only for his guidance — to arrive at overall remittance figure.”

  I also wish to plant an idea into the mind of the customer that he need not figure out estimate of only monthly usage figs of transactions.

Date: 18-09-03

This is a very important (subliminal selling!).

We do NOT wish to frighten him with ANNUAL figures which may add up to Lakhs of rupees!
Then he will run away!

We want to purposely “play down” the remittance amount (in the first instance) so that it looks quite small!
It must look insignificant in comparison with what Monster / Naukri / JobsAhead etc. charge at one go, right in the beginning of the year.

---

• Can the same form be used for repeat subscriptions (maybe once every month)?
  Somehow we must ensure this usage (repeat usage).
• Sanjeev should check out this form’s usage (both first-time + repeat) with a few HR Managers besides asking Ashutosh (3P as a subscriber) to test it.

(signature mark at bottom)

18/09/03

To:
Nirmit
Sanjeev
Raju
Kartavya / Abhi

SriRam

Date: 11-09-03

---

Pricing of our Web Services

Enclosed find yesterday’s news cutting which says:

Apple have succeeded in “selling” (i.e. permitting online downloading from iTunes)

→ 10 million songs in 4 months (16 weeks).

In my earlier notes on Napster / Apple comparison, dated May 15–16, I had pointed out that Apple had sold

→ 2 million songs in first 2 weeks of launch

@ 99 cents/song

So downloads have since slowed down, but it is still quite impressive!

→ $9.9 million in 4 months.

How did Apple manage to pull this off?

Possibly because,

• Apple tied up with Recording Companies & offered a legal download — avoiding anger/enmity of recording companies.
• Apple made them its partners (by paying a certain percentage of what it earned) rather than competitors.

Record companies had the “Content”.

Apple had the “Technology”.

A marriage of both resulted in a win–win situation for both.

---

• Music-lovers were downloading “legal” versions without feeling guilty — a big psychological motivator to users!

---

• Apple priced each song so low (99¢) that it removed the incentive from users’ minds to become “dishonest thieves engaging in pirating.”

Apple apparently succeeded in figuring out the price (for songs) at which “pirates” would turn into responsible, law-abiding citizens.

Apple correctly identified the size of the potential market and the exact price point at which…

…it can “swing” the market in its favour.

Apple episode has some useful lessons for us, as far as our web-service pricing strategy is concerned.

Keeping our initial – and ongoing – “development costs” (salary + investment in fixed + running expenses / overheads) out for a moment,

let us figure out

---

COST OF WEBSERVER

Item	Per Year
Rental (for 3 servers)	Rs. 3,20,000
Depreciation (@ 50%) on capital cost of 3 servers	Rs. 1,25,000
Interest (@ 10%) on capital cost of Rs. 2.5 L	Rs. 25,000
Bandwidth usage	Rs. 1,00,000
Cost of proprietary software licenses (written off in first year itself)	Rs. 1,00,000
Total	Rs. 6,70,000

---

We have 24 × 365 hours in a year

(Since server is on 24 hours and can schedule extraction batches around the clock)

= 8,760 hours

Therefore,

(A) → Hourly Cost = 6,70,000 ÷ 8,760 = Rs. 76.5 / hour

Now, let us add “development costs” as well:

Item	Annual Cost
Salaries	Rs. 24 lakh / yr
Interest on Rs. 20 L capital cost of head office (@ 10%)	Rs. 2 L
Depreciation on computers & other hardware (@ 10% on Rs. 20 L)	Rs. 2 L
Other overhead expenses (marketing / travelling)	Rs. 5 L
Total =	Rs. 33 Lakh / yr

So, hourly cost / server-hour (for development costs) =

Rs. 33 L ÷ 8,760 = Rs. 376.5 / hour → (B)

Therefore, total hourly cost = A + B = 76.5 + 376.5 = Rs. 444 / hour.

Let us round off to Rs. 500 / hour.

---

Now, if we assume that all of these 8,760 hours the server is just doing one thing viz.:

Extracting / Converting Resumes…

—and nothing else.

And if the server manages to extract 500 resumes per hour, then our cost per resume extracted works out to:

Rs. 500 ÷ 500 = Rs. 1 / resume.

So even if we charge Rs. 2 / resume extraction, we are OK!

Only hitch is that this would mean we must get for processing, in one year:

8,760 × 500 = 4,380,000 (≈ 44 lakh resumes)

or,
12,000 resumes each day (365 days).

---

Question:
Can we really manage to get that many resumes to convert daily?

If you may recollect, we had originally thought of charging Rs. 10 / resume extraction.

What (if any) is the Price / Demand elasticity for this service?

(hand-drawn graph)

Y-axis: Demand (lakh resumes)

X-axis: Price / resume (Rs.)

The curve slopes downward — high demand at ₹1–2 per resume, tapering off beyond ₹5.

---

Will corporates process/convert many more resumes if price is ₹2 instead of ₹10?

We don’t know.

I don’t think anyone knows!

There are no comparable products in the market which we can “benchmark” for our own pricing.

There is even temptation that — since there are no comparable products — let us fix a high price (since the buyer/user has no means to compare in any case) to start with.

If the corporate subscribers discover, through usage, that they are getting VALUE FOR THEIR MONEY,

Even at our “High” price, the demand will pick up gradually.

On the other hand, if we find in 3/6 months that the demand is not picking up as targeted, then we can always stimulate the demand by dropping prices — nothing stops us.

Does this argument have a familiar ring?

Such as: most cellphone companies started out 4 years ago at Rs. 16 per minute.

Then (as more and more competitors got attracted — because of this lucrative price!), capacity got multiplied rapidly, & the prices kept falling/falling/falling — to how many now? Rs. 0.40 / minute!

And the bottom is still not in sight!

But when Reliance set up close with a huge installed capacity, their goal was very simple:

Forget what the competitors are charging.

(I don’t think Reliance ever used competitors’ prices as benchmark.)

Simply, declare that price at which 90 % of installed capacity gets utilized.

The rationale was quite simple.

When you are in a commodity business, you are in a process industry; you are in the business of delivering

“DIGITAL SERVICE” (Internet / Wireless)

All of your costs are fixed costs!

Hardly any cost varies with volumes.

Your breakeven volumes are, therefore, very high.

(hand-drawn graph)

• X-axis: Volume → (Capacity Utilization)
• Y-axis: Revenue / Cost

Lines shown:

• Revenue rising steadily
• Variable Cost rising slowly
• Fixed Cost constant near top

Annotation:

You make money only after you exceed 90 % capacity utilization.

And, from page 3/4, it is quite clear that our total costs of Rs. 40 lakhs (approx.) per year are almost FIXED!

So, we must ensure that our webserver is working every hour of those 8,760 hours!

Not just ready to serve — but actually serving.

And we must reach this capacity utilization within 3 months of launch — gradual ramping up just won’t do! There is just too much at stake!

This (achieving 100% capacity usage) is Sanjeev’s job.

The only way for Sanjeev to look at his job is — he is not selling a product or a service,

he is simply selling our webserver’s INSTALLED CAPACITY!

As simple as that.

It is only through 100% utilization of this huge investment that we have made — in people, building, hardware, software — that we can recover our FIXED COSTS (which is all of our costs).

Now, at this stage, it may be legitimate to ask:

If our hourly total cost of server is

Rs. 500/hour (i.e., Rs. 40 lakh ÷ 8,760 hours),

then why not simply “sell” this processing capacity at Rs. 1,000/hour?

– irrespective of what subscriber uses it for?

– which applications he runs?

– what he uploads/downloads?

But if we did that, in a year we would earn only:

Rs. 1,000/hour × 8,760 hours = Rs. 87,60,000!!

i.e., approx. TWICE our fixed costs.

That seems ridiculously / absurdly low!

We might have succeeded in filling up the capacity (8,760 hours) but priced ourselves so low that in a whole year, we end up earning so little!

Can we think of pricing/selling one “server-hour” for, say, Rs. 5,000?

That would help us earn

8,760 hrs × Rs. 5,000 = Rs. 4.38 crores.

That looks more reasonable / respectable / acceptable (from our point of view).

But the question is:

Who will buy a webserver processing hour at Rs. 5,000/hour, even with GumMine / GumSearch applications thrown in?

If Microsoft were to offer even their best software at Rs. 5,000/hour (i.e., Rs. 40,000 for 8-hour staff), how many corporates would buy how many such processing hours?

I doubt if any would.

If we were to make such an hourly-charge proposal to our subscribers, we would kill the business even before it’s born!

People would simply laugh at us.

So, we have to stick to “mouse-click based tariff structure.”

In this structure, each tariff amount looks so small / so insignificant that you literally ignore it!

When you see a tariff chart, your mind does not start multiplying & adding!

It is quite like an “À la Carte” menu containing 40 food items, each priced at Rs. 40 / 50 / 20 / 10 etc.

vs.

A “Lunch / Dinner Thali” priced at Rs. 400/- (even with unlimited consumption!).

The high figure puts you off.

Very often, you also think that in any case, you will be unable to consume every food item in the thali!
Then why pay for it?

Why not pay for only what you want to consume — even if it adds up to more than Rs. 400?

---

You pay because you are able to establish a “Correspondence”, a one-to-one relation between the Price and the Value.

In a Thali or Parbhojan scenario, you are not sure whether you will manage…

…to derive the Value for the money point.

This is why cellphone tariffs are also “pay-per-use.”

And to entice you to use more & more, service providers are daily coming out with ever-newer “uses” and additional tariffs for each use.

It is the same principle of pay-per-use, in:

• Electricity → Units consumed
• Gas → Caloric metres (city)
• Water → Units used
• Travel → Km travelled & class of travel
• Freight →
• Volume used (cubic feet) or
• Weight loaded (tons) (again, per km taken).

---

“Per unit of consumption / usage, the amounts look insignificant / small.”

And this attracts both small users & big users.

They know that their damage / risk / commitment / cash outflow, etc., is something they themselves are going to control.

At any time, they can speed up or slow down.

They are in control at all times.

And especially, if you are not “watching” the meter continuously, you are not too much perturbed!

A classic example is that of a self-service supermarket.

Goods are arranged very attractively, tempting you to pick up & add to the shopping cart.

Although you do look up the price when picking up, you are not carrying a calculator or adding up as you move along the aisles — quietly picking up even those things which you have no immediate need for!

Quite often, it is only as you are passing an especially attractive display that you realize you need this item or that it would make a nice addition to your bedroom / drawing room / kitchen / wardrobe, etc.

It was not even on your shopping list when you left home!

But now you want it — just because it is there in front of your eyes!

Shopping malls first CREATE a need — then fulfill it!

Quite often, it is a question of

“Pride of Possession”

and has nothing to do with any real or even perceived need!

Digressing a bit—

Once its capacity utilization (of its network) exceeds 80%, Reliance & all others will slowly raise their prices once customers have got hooked (no portability of numbers!).

And their price rises will be of small but frequent (2–3 times/year) increases — so that users won’t even notice that their monthly bills are quietly creeping up, month after month!

After all, as a consumer, you know that costs/prices of all goods & services are rising by 8–10% each year.
So you don’t get agitated as long as annual price rise is within these limits — your system is able to absorb/digest such increases.

This equally applies to individuals as to corporates.

Hence, our pricing strategy shall consist of:

• A wide variety of “products” (buttons).
• Each priced low / insignificant in order to make it readily acceptable to users without letting them bat an eye.
• Continuously watching the response (daily number of transactions for each type of transaction) to forecast:
• → Which transactions (products) are popular / in great demand / and with whom.
  → Rate of growth of each.

This must be watched “subscriber-wise” and “overall.”

• Based on such daily watch, periodically increase the tariff just so slightly that customer does not even feel the difference (except maybe on a year-to-year basis).
• Do not show to a customer the meters (transaction-wise or overall) except when they log in by Admin only.
• (Not part of pricing): Arrange products (buttons) very invitingly / very suggestively, tempting him to click!

“Need” must not be a criterion for clicking!

As Mallory said,

“I climb Mount Everest because it is there!”

• Keep adding NEW BUTTONS (new services) and announce these additions on the homepage (which is our storefront).
• Create a buzz alert:

“You will be left out of a GREAT! GREAT! experience if you do not subscribe (‘Keep up with the Joneses’ syndrome).
You are in great company when you do.”