Hi Friends,

Even as I launch this today ( my 80th Birthday ), I realize that there is yet so much to say and do. There is just no time to look back, no time to wonder,"Will anyone read these pages?"

With regards,
Hemen Parekh
27 June 2013

Now as I approach my 90th birthday ( 27 June 2023 ) , I invite you to visit my Digital Avatar ( www.hemenparekh.ai ) – and continue chatting with me , even when I am no more here physically

Tuesday, 22 April 2003

BUSINESS MODEL FOR GLOBAL RECRUITER WEB SERVICE

Kartavya
cc: Abhi
cc: Nimit

22/04/03

Business Model for "Global Recruiter" Webservice.

So far, I was of the opinion that we should offer our webservices as follows:

First   → Corporates (10,000)
Second  → Placement Agencies (1,000)
Third   → Jobsites (100)

But more I think, more I realize that this is not the correct approach,
for the reasons that

→ It is a very slow approach  
→ Will take a long time to reach a break-even!  
→ Will demand a lot of time/money/effort to ramp-up.

I feel we cannot afford this luxury.  
We must turn the model upside down and see if there is any merit.

This is what I have tried to do in enclosed pages.

Based on this, I feel the fastest way to ramp-up our webservice and generate quick/long revenues is to

→ "License" our webservice to jobsites first.

→ Create an additional Revenue-Model for them (which all of them
   are desperately seeking — for fear of winding up!)

→ Not compete with them but "collaborate" with them.

→ "Network" with them (each new jobsite will improve the value of our network).

→ Leverage their existing customer-base (built-up at crores of rupees!)

→ Quickly establish our service as THE INDUSTRY-STANDARD, once
   hundreds of corporate-subscribers of these jobsites, start using it.

→ Build a strong "platform" in India, to launch Global Recruiter,
   all over the world.

I feel, my proposal may have important implications on Webservice Architecture —
so let us conclude quickly.

“NON-COMPETE” WITH LICENSEE JOBSITES

Once we start competing with our licensee job sites (our distribution channels) by enrolling corporate subscribers directly, then there is a conflict of interest.

Websites (jobsites) will think we are “bypassing” them and taking away “their” clients. We are encroaching on “their” territories. Then they will have poor loyalty to us.

IBM / Compaq / Cisco / GM etc. tried to sell directly (thru their own websites). They would book orders directly on their websites – and then ask the dealer/stockist who is nearest to the customer, to
→ Deliver the product physically
→ Look after “After-Sales-Service”.

They have met with a lot of resistance from their distribution-channel-partners. So they are going very slow & throwing in more “incentives”.

Only company which has succeeded in direct-selling is DELL – because it sold directly (in those days, over phone) from Day ONE!
They never built a distribution network – even though they are selling “physical” product.

You may say,
“But our webservice is a pure digital service – which needs no physical handling and therefore no distribution channel. And the service can be delivered over wires (and soon wireless) directly to millions of corporates! Then why do we need JOBSITES as licensees / as intermediaries?”

Pure & Simple

  • If we can get the same results/revenue, by dealing with 100 jobsites, then why should we complicate life by dealing with 10,000 corporates directly?

  • If 100 jobsites have, after long/hard struggle, established personal equation/relationship with 10,000 corporates, then why not “leverage” those already existing relationships to our advantage rather than trying to establish ourselves directly with them?

Left to myself, I would go so far as to say,
“We will NOT accept direct enrollment/subscription from ANY corporate client. If someone approaches us, we would encourage him to subscribe to one…”…but this may not always work. Suppose WIPRO or INFOSYS or HLL were to approach us directly for enrollment – could we say, “Sorry, NO! Go to XYZ jobsite!”

So, we will have to keep a “provision” in our webservice architecture, for such “exceptions”.

By and large, our approach (vis-à-vis a jobsite licensee) would be as follows:

  • Please give me a list of your existing corporate clients.

  • OK, I give you 3 months’ time to enroll these corporates for our webservice. During this period, I will NOT approach them directly on my own. Even if any of them do approach me directly, I will redirect him to you (cc: to you – so that you can follow-up).

These clients are your “Territory” and I do not wish to trespass on your territory.

BUT

  • Those (from the list) that you fail to enroll, I will feel free to approach them directly, once 3-month period expires.


This is like a “Royalty or Commission” model.

For each transaction, we will stipulate a “Minimum/Floor” price. But there will be no (max) MRP / no ceiling! A licensee jobsite would be free to fix any transaction-fee, as long as it is more than the MRP (Minimum Retail Price).
Principle: any jobsite will use its “charge what market can bear”.

Tariff can be different for different clients.
BUT – whatever unique tariff table that a jobsite creates for any given client, will also get reflected/mirrored in our webserver. Our server, in any case, is keeping track of how many transactions a given client conducts – and which type. By multiplying the two, our server can/will figure out how much revenue this licensee generated from this client.

Then, we debit licensee’s prepaid account with 10% (or whatever % we decide) of the revenue he generated (using our webservice) from each client. This is a “commission” he pays us!
He gets to keep 90%! That is his gain. But, for getting this advantage, he is forced to “reveal” his revenue to us. This option has a powerful incentive.

I suppose webservice architecture can accommodate both options, with a “changeover” possibility.

Kartavya
Abhi
Nagwekar
Inder

GLOBAL RECRUITER

Enclosed find a folder containing notes:

  • A By-Product & Employment Exchanges

  • CFC – Customise For Convenience (I & II)

  • The Beauty Index

  • Interview Mgmt. Module – Func Specs

Earlier also, I have sent to you several notes. I suggest you keep all of these together, in your ONE respective folders for easy access/reference. Flaps make it easy to locate a note.

If you are hard-pressed for time to read these notes during office hours, pls. feel free to take these home over weekend. Early reading is advisable, in case, some item impacts the Architecture/Database design now, even if the feature is meant for introduction after 6/12 months, in later versions.

Regs.
[Signature]



















No comments:

Post a Comment