Notes: STATISTICS FLIGHT DECK

Kartavya

Abhi

Inder

18-01-03

Webservice / Flight Deck

Enclosed find some “Requirements / Features” that we should incorporate in Webservice.

This is not a comprehensive list. I suggest three of you sit together and debate this list. Maybe you will come up with some fresh ideas.

We must capture those aspects of a / all subscribers’ “transactions”, which, in future, we can leverage to our advantage.

Statistics / Data about "Web-Service"

📅 17-01-03

S.No.	Description	Can be Viewed by
		Concerned Subscriber Only

Amount Paid / Balance to the credit
✔️
Each type of “transactions” carried-out (e.g. “Convert” / “Search” etc)
- Daily / Weekly / Monthly / Yearly
by any given subscriber
✔️
- Ditto – by ALL subscribers put together
  ✔️
Transaction – BreakUp
No. 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.

Each “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 BREAKUP OF MY RESUME DATABASE?”

Here is the transcribed content from the scanned note Page 7/7 of the handwritten document titled:

Statistics / Data about “Web-Service”

No.	Description	Concerned Subscriber Only	All Subscribers	3P Only
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” ever carried out by a given subscriber. This (statistical analysis) will tell us: – Who (which corporate) is on lookout for – Whom (what kind of executives).		✔️	✔️

In essence, we compile a comprehensive “Searching History” (“Searching Profile”) of each & every subscriber of our Webservice.

This (statistics) is our MARKET RESEARCH.

It will enable us to conduct PRO-ACTIVE MARKETING (of our own resumes/candidates) which is 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.

Let me know if you'd like a compiled and formatted Word document of all 7 pages.

Statistics / Data about “Webservice”

A subscriber should (must?) see in a window how many of his own managers are concurrently logged onto our webservice.

Can he, possibly, 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

– Who is conducting how many searches

– And for what positions and 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 shortlisted candidates and simply email it to someone outside the organisation!

→ Data leakage!!

We will enter “cheque/payment” details in the server through 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 any time, 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 hell of a problem!

I suppose, simple & moral rule to follow is that the “new upward revised prices” will apply only after current balance in subscriber’s a/c gets exhausted.

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

on any particular day / month / quarter / year
graphical (line graph for cumulative year, for days of months, graphs for months of year)

🔹 % increases (day-on-day / month-on-month / Q-on-Q / year-on-year)

of:

subscriptions
transactions

Key Metrics & First-Time Client Registration Form

🔹 Client Performance Analysis

Who is our “best / biggest” client?
Who is our “least / smallest” client?

➡️ Perform Ascending / Descending Order Analysis of:

Payment Amounts
Number of Transactions (per month / quarter / year)

🔹 Pareto Analysis (80/20 Rule)

Which 20% of our clients give us 80% of the business (in terms of number of transactions)?
(Note: Number of transactions should suffice)

➡️ A graph must be plotted for any given period:

perl
     ^
     |        80%
 No. |        _____
of  |       /
Tran|      /sac |     /
tions|___/________________>          20%      No. of clients

🔹 First-time “CLIENT REGISTRATION FORM”

Should capture enough data about a client in terms of:

Size (Turnover / Current Employee Strength)
Number of factory locations (Names of Cities)
Number of offices (Names)
Products / Services
Industry Names (Dropdown)
Average Employee Turnover

Unskilled Category
Supervisory & Above

Exclusive Page for Subscribers — A Self-Fulfilling Strategy

We should give an "Exclusive Page" to each & every subscriber of our webservice,

so that, whatever resumes arrive from our partner cybercafes (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) in the first place,

& then in the second place we make more money (from our webservice)

by converting these resumes!

🖊️ Signed

📅 17/01/03

Would you like me to now assemble a final Word document compiling all 7 pages (6/7, 7/7, etc.) into a cohesive business concept note — complete with:

A cover title
Section headers
Cleaned-up formatting
Highlighted monetization model
Supporting infographic summarizing:

Resume inflow
Lock-in funnel
Webservice conversion
Revenue dual-stream

This image outlines a data tracking system for subscribers using the resume conversion web service. It presents two visual tables:

✅ 1. Subscriber History Sheet

Sl. No.	Order No. (Auto Generated)	Order Date (Reverse Chrono)	Amt Paid (₹)	Instrument Details (Cheque/DD No., Date)	Total Transactions Carried Out	No. of Extracts	No. of Searches	Transaction Close Amt (Auto Reset to Zero)
1	Auto Generated	—	—	—	—	—	—	—
2	Auto Generated	—	—	—	—	—	—	—

🔐 Includes:

User ID & Password (linked to Subscriber Name)
Visible only to subscriber and 3P admin
Enables full transparency of order history + payment + service usage

✅ 2. Subscriber Current Order Data Sheet

Subscriber Name & No.	Order No.	Order Date	No. of Transactions Carried Out	Extracts	Searches	Total Current Balance
—	—	—	—	—	—	—

🧾 Purpose:

Helps track ongoing usage of extract and search services
Highlights real-time balance
Keeps 3P and user in sync

📌 Annotation at the Bottom:

These will be visible to both the concerned subscriber and to 3P.

Would you like me to now:

Digitally recreate these tables into the Word doc as editable table layouts?
Add this visual section into the compiled final document for the Resume Data Extraction System?

Let me proceed accordingly.