REJUMINE ONLINE PAYMENT

Customer Order History

We must create a HISTORY-CARD for each & every Customer Order No

(i.e., for each & every fresh online payment).

Conceivably, such HISTORY-CARD may look like follows:

CUSTOMER ORDER HISTORY-CARD

Customer No: (Should remain same after all activations / de-activations / re-activations)
Customer Name:
Chief of Personnel:
User ID:
Password:

Customer Order No:

Date:
Amount (₹/$) paid online:
Mode/Method of Payment:

Balance – Details (of current order):

Balance Amount (₹/$): [ ] as on Date.
Against Order No:
Date:

What else? We could always add more details based on client feedback.

Only Chief of Personnel should be able to see this HISTORY-CARD thru his ADMIN tool.

We may even create a “Customer Orders SUMMARY-SHEET” for viewing ALL orders placed

till date at one glance.

Customer Order Number (CON)

I could prove wrong, but, as of now, I feel each time a customer makes further “Online” payment,

a new/unique “Customer Order No (CON)” should get automatically generated – and get

automatically communicated to the client.

Of course, as on date of further payment, if any “balance” amount is lying to the credit of

the client, all transactions should continue to get “adjusted” against such “balance”

amount first,

till the balance stands reduced to ZERO (there will be some programming difficulty in

this logic – but we can resort to some “rounding-off”).

Only after the “balance” amount stands reduced to ZERO, should the new “account”

& new “CON” kick-in & take-over. This is because, somewhere earlier, I have said

that any PRICE / TARIFF REVISION that we may announce, at any point of time, should

become applicable “PROSPECTIVELY” only & should not cover the “existing/earlier” orders

of a client – especially since he has made “ADVANCE” payment & contracted for a

certain value/amount of service. We are bound/obliged to render such service at

the agreed-upon “tariff.”

In real world, if customers expect an imminent “RISE” in the price of a product,

they rush to the market & make purchases at the existing price / ruling price.

Why should “Web-Service” be any different?

If a Regional Personnel officer tries to access/view a particular “Module” for

which he is not authorized, a polite “message” should pop up!

We must also keep a log of how many times the CPO changed the Authorization

Chart/when & what changes he made (including addition/deletion of names).

CPO should be able to see/view this “History,” but cannot change the History!

We also need to decide whether UserID/Passwords (for every Authorized User Mgr)

should be computer generated or should this be done by CPO manually.

In any case, I presume CPO would need to manually enter the email ID of

each person he “authorizes.”

As far as possible, everything should be done ON-LINE (by the CPO or

the local recruitment manager). To the extent possible, we must NOT accept any

“instructions” from our subscriber, by email/fax or typed letter.

Besides increasing our work/our offline support staff, such “offline”

instructions may result into mistakes, making us “liable” for damages!

The main idea behind a webservice is SELF-SERVICE.

We should be able to run/manage our service with no more than

3 persons in our back-office.

Authorization

Even if a company wants to authorize all 10 of its HR managers to

“access/use” our web-service, it is possible that the Chief of

Personnel wants to restrict the “access/usage” of certain “Modules”

of our service to only certain HR managers.

The CPO (Chief Personnel Officer) should be able to create/alter the

Authorization as follows:

AUTHORIZATION - CHART

• Company Name:

• Customer No:

• CPO Name:

• CPO User ID: [____]

• CPO Password: [____]

Person Authorized	Resumine	ReSearch	Ad Compose	India Marketer	Population Profiler
Patel	✔
Venkat	✔
Suresh	✔	✔
Mhatre			✔
Karmik	✔			✔
---		✔			✔

When CPO modifies this chart anytime, our server will send out

appropriate email to each concerned person re: change.

Only CPO would be able to see the full chart.

Session-Log

Our webservice must have provision to create session-logs as follows:

Form:

Customer No:  
Name:  
Executive Logged-In (Name):  
User ID:  
Password:  
Date/Time Logged In:  
Logged Out:  
Duration (hrs/min/sec):  
No. of Transactions – Details  
-----------------------------------------
Type of Transaction     No. of Txns   Rs. Deduction  
1. Convert  
2. Search  
3. Email  
4. …  
5. …  
Total:  

If a subscriber company has authorised 10 HR managers to access webservice, 
then each of these 
managers would/should be able to see/view only his own 
Session-Logs” (chronologically arranged 
or searchable database).
Only the Chief Personnel Manager should be able to see/view:
Session-Log of anyone of the 10 HR mgrs.
Consolidated Session-Log of all 10 HR mgrs. (combined) for any day.
Cumulative No. of Transactions (of any type) carried…

Resumine: Online Payment
Dated: 10/03/03
Online Payment
Vishesh suggested that we should have a provision whereby foreign companies wishing to subscribe to our Resumine should be in a position to make online payment using credit-cards.
All over the world, the name of the game is SPEED / FAST. No company in USA/UK would have time or patience to write out a cheque & then send it to us through courier – and then wait for 15 days to use the service!
On internet, everyone wants things to happen instantly. So, we must make provision for credit-card payment (any credit card).
For this, I believe we do not have to separately tie-up with a dozen “credit card” companies. I believe we need to tie-up with just one “exchange” company – which, in turn, deals with all credit card Cos.
Pl get the name of such an “Exchange” company from Nimit / Raju / SriRam and start a dialogue to understand their “commission” terms.
For “online” subscription payments, we must offer as many options as possible.

Process-related issues / Webservice
It is necessary to anticipate – and provide solutions for – process-related issues.
Some, which I could anticipate at this stage are:
Online Registration (as a Subscriber) & automatic “Activation”
Although we will give lots of demos on the ground, I presume a subscriber would need to register ONLINE only, where/when he would be allotted a UNIQUE Customer No. (Online).
Since we do not at present envisage online payment mechanism, all that a customer can enter in the online Regi. Form is:
Cheque No / DD No / Wire Transfer No & date
His bank details
Our bank details (downloaded)
Amount [options → Indian Rupees / chosen → U.S. Dollars]

We may decide to “activate” the account as soon as – and as long as – above-mentioned details of payment are mentioned, without waiting for confirmation from our bankers.
If we do not receive the confirmation from our banker within 10 days of activation, we could always “de-activate” the account with an intimation to the client.
An automatic email would need to go out to our banker as soon as an account / customer no. is allotted online. This email would contain payment-details mentioned above, asking our banker to confirm within 7 days. This would work in case of “Wire Transfer”.
In those cases, where a client sends cheque / DD directly to us thru counter, we have to deposit ourselves in the bank.
If we do not receive the cheque / DD within 7 days, we should send an email to the client (in addition to phoning) saying we are deactivating the account and that we will reactivate it as soon as we receive the cheque / DD.
Of course, anyone can use our webservice for 1 month (or 500) without entering payment details when he clicks on “DEMO” Version (after filling rest of the Registration Form).

Payment Options & Transaction Tariff
We shall permit a client to make payment in Indian Rupees or in US $, by clicking on appropriate “option” button in Registration Form. Depending upon option selected, corresponding “Tariff Table” will get displayed, so that he knows how much he would be paying for “each” transaction, in Rupees or in Dollars.
US $ payment option will enable us to keep track of “Foreign Exchange” earned by our webservice, at any point of time, for any given period, from any given country. Our ADMIN TOOL / STATISTICS TOOL shall keep track of these (—and of course display whenever we wish to see).
These statistics will be a very useful info/data for a future IPO / strategic investor / VC funding / foreign listing / even claiming Income Tax exemption (currently 100% of revenue) by saying that this (service) is a “SERVICE EXPORT” very much like deputing software engineers abroad AND that this SERVICE was actual rendered beyond the shores of India (in case server was located abroad?).
Database residing on Client’s Server
We have decided to offer this option to those clients who so decide. But even in this case, the basic revenue model shall remain the same, viz:
Prepaid Service


Pay-per-Use
There should be no exception to this, because we simply will not have the manpower to raise invoices & then chase clients for “outstandings”! We would end up with huge outstanding collection and go bust! We would rather forgo such business—no matter how big the client. If our product/service is “Extraordinary” & vastly improves client’s productivity/profitability, then “Prepaid” condition will not pose any problem.
That means, technologically, you will need to figure out a solution that is not only completely “transparent” but also “acceptable” to the client, which does not compromise the integrity of his database.

Commission / Brokerage

Provision would need to be made for payment of commission/brokerage, to any no. of companies/agents. Again such ( % - percentage ) commission will differ from Agent-to-Agent.

I can anticipate following scenarios:

---

# Worldwide “Marketing Rights”

If companies like Microsoft / Oracle / BAAN / SAP / PEOPLESOFT, get interested in

→ marketing our webservice as a standalone service

OR

→ integrating our service as an integral part of their own “product-offering”

From our point of view, this would be an ideal solution – as far as marketing is concerned, which is, in anycase, not our “core-competence.”

# Regional “Marketing Rights”

This would be a subset of earlier proposition. Eg: MonsterIndia may want to market our “service” within India, since 600 corporates already “advertise” their vacancies regularly on their website and, therefore, receive thousands of email resumes daily. These 600 are already their existing clients & it would be easy for Monster to promote RESUMINE/RESEARCH as one more “Value-Added” service, to these existing clients.

MonsterIndia may even think/believe that, by offering such “Value-Added” service, they could expand their client-base to 6000 companies!

The big 600 clients may have some or other conversion/extraction/search software but there are thousands others, who do NOT. By offering our service, Monster could entice them to become clients.

Tie-ups with Trade Bodies / Professional Bodies

Trade Bodies

• CII / FICCI / ASSOCHAM / NASSCOM / MAIT etc.

Professional Bodies

• National HRD Network / NIPM / Inst. of Engineers etc.

If these “bodies” are impressed with our service, they could consider promoting it amongst their “member-companies”, in return for a “commission”.

Of course, in each such case, the ultimate member/client will have to be a “COMPANY” and not an individual.

Tie-up with Consultants (KPMG / PwC / McKinsey etc.)

Tie-up with Associations such as “PENHRYNE”

There are “RECRUITER / PLACEMENT FIRMS / EXECUTIVE-SEARCH FIRMS” Associations in many countries.

These associations-of-firms represent thousands of recruiting companies.

It is quite possible that recruitment-firms around the world eventually become our biggest “market-segment”. Such associations may demand a commission to promote our services amongst their “member-firms”.

Tie-up with Jobsites

Is it thinkable that Naukri / JobsAhead / JobStreet / JobsDB / Sampoornam etc. could also get interested in some “arrangement” with us? How would they stand to gain (read: “make money”) by promoting our service?

If we can find a way by which jobsites can make lots of money by offering our RESUMINE / RESEARCH services, then they would certainly “bite the bait”!

We must remember that there are maybe 30,000 job sites in the world.

They may not even ask for a “commission” (from our revenues) if offering our “service” through their websites can push up their other revenues.

E.g.: As I said, in case of MonsterIndia, could offering our service help them “rope-in” more Corporate Clients, who would opt to advertise on that particular website which offers “RESUMINE / RESEARCH” in preference to those websites which do not?

For the websites (jobsites), ability to offer such a “service”, could prove to be an important COMPETITIVE ADVANTAGE.

Since, as of now, I cannot see someone like Microsoft/SAP taking up our worldwide marketing "rights", we must pursue the strategy of "Viral Marketing" thru a series of alliances of the kinds mentioned above.

Therefore, we will not exclude:

• Competing "Jobsites" (Naukri/JobsAhead/Monster)

• Competing "Associations" (like Penrhyn/Foster Partners)

• Competing "Trade Bodies" (CII/NASSCOM/ASSOCHAM)

• Competing "Prof. Bodies" (NIPM/National HRD Network) etc. etc.

All that we will do is to provide a "field" in our REGISTRATION FORM, where a subscriber-company will enter as follows:

---

We decided to subscribe to this service based on recommendation/promotion by:

• NIPM ⭕

• ASSOCHAM ⭘

• PENRHYNE ⭘

• FOSTER PARTNER ⭘

• Naukri ⭘

• Jobs Ahead ⭘

• None of the above ⭘

(Check any one) (Must click one)

{ These names will be added by us thru our ADMIN tool, as & when we sign AGREEMENT with each party. }

---

Based on this, we will pay "commission" to that party/ALLY, for all revenues received from this company.

Such an arrangement (of self-declaration by the subscriber himself) is absolutely essential, because it is very likely that:

• A given company is a member of both ASSOCHAM & CII, NIPM & National HRD Network etc. etc.

• It may receive "promotional letters" from both.

We cannot "assume" that the company acted upon based upon advice/recommendation of X association or Y association! Once a company itself "declares", there is no dispute.

We become completely transparent and we can permit each ALLY-ASSOCIATION/BODY to view the list of all those companies which ticked ⭕ "their" name.

Going further (on transparency issue), we can/should allow each such ALLY to view:

• All payments made to 3P by those companies who ticked ⭕ on their name.

• All "transactions" values of each of these companies.

To encourage such TRADE BODIES / ASSOCIATIONS / JOBSITES / ALLIES, to aggressively market our services, we may agree to pay them their "commission-cheque" as soon as we receive our PRE-PAID service-fees (– not "Activation Fees"). Commission will be a % of Service-Fees only.

Since we are getting paid (by the Subscriber) in "advance", let us also pay our "Agents" in advance!

This means, even though the Subscriber uses our service over a period of 6 months (based on PREPAID amount), our "Agent" gets paid right up front!

This would encourage our AGENT to:

• aggressively promote our service amongst his members

• ensure that every "member" firm clicks ☉ against his (Agent’s) name in the registration-form.

This is because of our PRINCIPLES of:

• First come, first served (self-declaration)

• Once a Subscriber Company has clicked ☉ against the name of a given "AGENT", it cannot change/alter this later – as long as it retains the same unique CUSTOMER NO.
  (but it can discontinue/re-register/get a new NO.!)

I suppose, Reji / Deepa could be asked to develop the Registration Forms and its related software/databases. Deepa can start from Feb. 21st as soon as her present assignment gets over.

By end of this week, I will also give you, designs of:

• "Statistics" pages (separate for a Subscriber / 3P etc.)

• Admin Tools

• Webservice homepage

• Write-up for PowerPoint slides

After that, I will take-up:

• Introduction email

• "Service-Contract"

• FAQ

• Schedule of Series of DEMOS to select companies

• Draft of "Agency-Agreements" (for ALLIES)

If anybody is (even) likely to fall behind his/her target/schedule, I would appreciate being informed beforehand – not after the deadline has passed!