Friday, 17 January 2003

STATISTICS/ DATA ABOUT "WEB - SERVICE"

17 Jan 2003

STATISTICS/ DATA ABOUT "WEB - SERVICE"

       1. Amount paid/ Balance to the credit

2. Each type of "transactions" carried out (eg. "Convert"/ "Search" etc)

       - Daily/ weekly/ Monthly/ Yearly

       by any given subscriber
 
       3. Ditto - by ALL subscribers put together

        4. Transaction - Break up

 Not. of Resumes "Converted"

·     Industry wise

·     Function wise
  
·     Designation wise

·     City wise
  
·     Age wise

·     Edu. wise

·     Salary wise etc.

In nutshell, we should capture all info/ data about each & every "transaction/ resume" - except for Name & contact info. of the candidate. Such "Aggregated" data about ALL the resumes converted /extracted by any subscriber, can be plugged - back into the respective subscriber's "SEARCH" interface, enabling him to know precisely, at any point of time,. "WHAT IS THE BREAK - UP OF MY RESUME DATABASE?

5. The "data/ info" mentioned in (4) above should be "aggregated" for ALL subscribers on a continuous basis, for  viewing by 3P only.

6. On our web - server, we should aggregate all "searches" every carried out by a given subscriber. This (statistical analysis) will tell us.

       - Who (which corporate), is on look - out

       For

       - Whom (what kind of executive)

In essence we compile a comprehensive "searching History" (searching profile) of each & every subscriber of our  webserice. This (Statistics) is our MARKET RESEARCH. It will enable us to conduct PRO - ACTIVE MARKETING (of our won resumes / candidates) which sharply focused on each subscriber’s UNIQUE manpower needs. This is PIN - POINT marketing / Targeted marketing!

·     After a period of 2 years (by which time, a subscriber is so deeply "hooked" to our webservice, that he simply  cannot live without it), our webserver, will start "OFFERING", Candidates from our own Resume Database, every time, a Subscriber conducts a "Search" transaction.

7. A subscriber should (must?) see in a window, how many of his own managers are concurrently logged onto our webserivce. Can be, possible, see (in same window) "who" are these co - managers? In big companies, central HR dept. may like to keep track of this aspect.

If central HR dept. has given out log in/ Password to 5 "user" dept. managers, central HR dept. may also want to know, which dept (mgr) has used which webservice (convert/ search) & when & How much? - a kind of "Log".

Central HR  dept. would certainly like to know.

- Who is "converting" "How many" resumes & for what positions & why (i.e. to fill, what vacancies?).

Central HR dept. may even want a built - in SECURITY feature whereby, no dept. manager can conduct a search/ tabulate the "short - listed" candidates & simply e - mail it to someone outside the organization ! Data leakage !!

8. We will enter "Cheque payment" details in the server thru an ADMIN TOOL, in the "A/C No" of concerned subscriber & an auto email should go out to concerned subscriber re: his "A/c status". Of course, he too, should be able to "ACCESS" his own consolidated Payment History" & "Balance to Credit" at anytime, directly, on his own.

An auto email should also go out when a "balance left" in a subscriber's account reaches a certain minimum level.

3P Admin should also be able to see, at any time, a subscriber's "status"

What happens if we "raise" our tariff for any particular webservice?
Or even lower it? Lowering may not be a problem but "raising" will create one hello a problem!

I suppose, simple & moral rule to follow is that the "new, upward revised prices" will apply only after current balance in supplier's a/e gets exhausted.

       # 9

At any time, we at 3P should be able to check - out / find/ view instantly

·     How many subscribers do we have at this moment?  (If this becomes a respectable figure, we might, even want  ALL interested/ potential customers to be able to see this figure! we would even want such potential customers to even see the "Names" of all of our subscribers! A good / strong "Reference - List" is always our best selling point!

·     How much total "balance" is lying to all subscribers’ credit? (Tells us approx amount of "Service" remaining to be delivered)

·     How much "Subscription payment" received

·     Any particular day/ month/ quarter/ year

·     Graphical (Line graph for cumulative)

·     % Increases of

·     Subscriptions  &

·     Transactions

[day - by - day/ month - on - month/ Q - on - Q/ year - on - year]

·     Who is our "best / biggest" Client?

·     Who is our "Least/Smallest" Client?

(Ascending / Descending order analysis of

·     Payments of Amounts

·     No. of Transactions (per month/Q/Year)

·     Which 20% of our clients give us 80% of business (in no. of transactions - should suffice) ?

·     First time "CLIENT REGISTRATION FORM" should capture enough data about a client in terms of

·     Size (Turnover/ Current Employee Strength)

·     No. of factory locations (Names of Cities)

·     No. of office locations (Names of Cities)

·     Products / Services

·     Industry - Names (Drop down) etc.

·     Average Employee Turnover

       - Unionized category

       - Sup. & above.

We should give an "Exclusive Page" to each & every subscriber of our webservice, so that, whatever resumes arrive from our partner cybercafés (under project LOCK - IN), could be deposited in the exclusive EMAIL BOX of each subscriber.

·     Now, if we continuously, keep advising (thru auto email) each subscriber (every week?) that

·     You have so many email resumes lying in your exclusive email box. Would you not like to convert these into a structured database (- and thereby make these "Searchable"_, using - our

WEB SERVICE ?

·     This could very well become a "self - fulfilling prophesy" !

·     Our server makes money from partner cybercafes (for resume blasting) i the first place & then in second place, we make more money (from our webservice) by converting these resume !

HEMEN PAREKH

No comments:

Post a Comment