Staffing and Recruitment in the Blockchain World – Process Improvements and Efficiencies

Staffing and Recruitment in the Blockchain World – Process Improvements and Efficiencies

2019-01-16T21:10:48+00:00 January 16th, 2019|Articles, Editor's Picks, Latest Posts, Tools and Apps|0 Comments

What is Blockchain?

The objective of this whitepaper is not to explain Blockchain in depth, since the scope of that is enormous and it has been done in much greater detail elsewhere. Rather, what we want to cover in this document is the practical application of Blockchain to a specific set of business processes relevant to the staffing and recruitment industry.

That said, at a very high level, Blockchain allows us to have a shared, distributed, and encrypted ledger of transactions – that everyone in a business process accepts as the “truth”. Each of these terms requires some explanation:

  • Shared – all players in the process have access to the ledger and all transactions in the ledger.
  • Distributed – the data is distributed across thousands of computers. This ensures that hacking/changing data on one computer will not impact the overall truth. As long as 50%+ of the nodes are unhacked, the truth is secure.
  • Encrypted – the data is encrypted and secured by a sequence of private and public keys, ensuring that players outside the chain cannot view the data. Blockchain is the core technology behind bitcoin and other cryptocurrencies. However, the use of the technology can revolutionize processes beyond the financial transactions that cryptocurrencies support.

General Projected Benefits of a Blockchain Ecosystem

As a result of the inherent technology, Blockchain is projected to bring significant improvements to business processes across multiple industries. At its core, the primary benefit that blockchain introduces into business processes is trust between all the parties. This trust is enforced by the blockchain – essentially all parties in the process believe (or should believe) that transactions in the blockchain are the absolute truth. They are immutable, secure and unhackable. Based on that essential premise, blockchain technology promises the following benefits:

  1. Transparency – by its very nature blockchain transactions are transparent. That is, every player in the process has full visibility into the transactions that are occurring. A point to emphasize here is that not all key data will be exposed to everyone, but everyone will know when a transaction has occurred based on a contract between two or more parties.
  2. Speed – Transaction speeds are near-instantaneous. If contractual conditions are fulfilled, then transactions are managed by the blockchain and initiated automatically. There need not be approval processes or gateways to cause any delays. To be clear – this refers to process speed and not system speed. Business processes become faster, as opposed to the actual system transaction, which by the very nature of the blockchain, are slower.
  3. Reduced Transaction Costs – third parties in the process can either be eliminated entirely or their role can be severely curtailed, leading to reduced transaction costs.

We will now apply this knowledge to an exercise to bring efficiencies to the Staffing and Recruitment process.

Staffing and Recruiting Today – Processes and Issues

Step 1: Finding and Submitting Candidates for Jobs

The staffing and recruitment process for temporary labor is currently rife with inefficiencies, and this is caused mainly because of a lack of trust between the parties. This is a process that is optimally suited for blockchain disruption.

Staffing and recruitment for temporary workers is a very fragmented market, with a small number of large companies and a very large number (tens of thousands) of small companies – many of them sole proprietorships. Most large organizations – or End Clients – work with a select group of Prime Vendors. Each Prime Vendor works with their own groups of Sub Vendors. Sub Vendors are not uniquely associated with a Prime Vendor – that is, each Sub Vendor may be working with more than one Prime Vendor servicing the same End Client.

A Sub Vendor for End Client A could be a Prime Vendor for End Client B and vice versa. Sub Vendors may have their own Sub Vendors in a chain with n links. These relationships can be represented as in Figure 1.

In Figure 1, solid arrows represent Prime Vendor relationships and dotted arrows represent Sub Vendor relationships. So, End Client A has Prime Vendors ABC and DEF. ABC has Sub Vendors PQR and GHI, who both have a common Sub Vendor MNO. JKL is a Prime Vendor to End Client B but a Sub Vendor to DEF, which is a Prime Vendor for End Client A.

This is a simple example with 2 End Clients and 6 Vendors. In reality, the complexity of the map is much greater – with thousands of End Clients and tens of thousands of Vendors.

End Client Objectives

In the entire temporary staffing process, the End Clients’ objectives can be summarized as:

  1. Find the most qualified and cost effective temporary worker available in the market for the open position.
  2. Pay the least possible amount of markup on the temporary workers’ direct wages.
  3. Ensure all contractual obligations are clearly defined and met across the Vendor supply chain, so there is no liability.
  4. Ensure fairness in the recruitment process, so there is no long term loss of goodwill.

Competing objectives are at play in the process. In order to maximize the chances of fulfilling objective 1, the End Client should distribute the job requirement to as large a network as possible – thereby increasing the pool of recruiters looking for the right candidate. However, a larger network chain also leads to a higher total markup (working against objective 2), and higher oversight and process costs to meet objectives 3 and 4.

The current decision problem that most End Clients are faced with is: “How can the outreach for potential candidates be maximized, while limiting markup and oversight/process management costs?”

 

Current Process for Finding and Submitting Candidates – Issues

Any of the Vendors in the chain could theoretically find one or more candidates for the job. They will then submit the candidate up a tier the chain. As it exists, the submission process is completely sequential. That is, a Sub Vendor can only submit the candidate one tier up the chain.

When a Prime Vendor receives the candidate profile, they can decide to submit it to the End Client. The End Client will then decide which candidates to call for an interview.

The major problems in the process can be identified here:

Issue 1: Since a Sub Vendor can receive the same requirement from more than one Vendor “higher” in the chain, submitting a candidate up the chain is not deterministic. As an example, consider NOP Co. They are receiving the same requirement by the route ABC-GHI-YZA-NOP, the route DEF-JKL-YZA-NOP, the route ABC-MNO-VWX-NOP and the route ABC-MNO-BCD-NOP. So which of the Vendors higher up the chain should OPQ submit the candidate to? In most cases, the path chosen will be sub-optimal from End Client A’s perspective, since NOP will choose the higher tier vendor based on the greatest markup offered. So at each step, the greatest markup is chosen by the lower tier vendor.

Issue 2: The candidate now has to be screened or vetted through every step of the chain. This is fine if the Prime Vendor finds the candidate. However, if say, NOP finds the candidate, he or she will be vetted by 4 Vendors before reaching the End Client. Each step of the vetting process is entirely repetitive.

Issue 3: The End Client has no control over the markup applied on each candidate’s wages. The markup will vary depending on the length of the chain, since each link in the chain will apply its own, arbitrary, markup. The End Client can control the markup by arbitrarily shortening the chain – for example, by limiting candidates to only Prime Vendors’ direct employees. However, this drastically reduces the pool of available recruiters and candidates – making the task of finding the right candidate at the right price (the primary objective of the End Client) all the more difficult.

Issue 4: Once a candidate is submitted up the chain by a Vendor, the Vendor loses all visibility into the rest of the process. Continuing the earlier example, let us say NOP submits the candidate up the chain to YZA and then YZA submits to GHI. At that point NOPs link to the process is broken. They have no visibility into whether GHI will submit the candidate further up the chain or not.

Issue 5: There is a major issue of trust in this process. Essentially, Vendors lower down in the chain do not fully trust that the higher tier Vendors will not “poach” the candidate, or claim that they found the candidate and cut out the lower tier Vendor(s) entirely. In our example, if GHI claims to the higher tier that the candidate was sourced by them, NOP will, in most cases, never find out about the poaching.

 

Step 2: Contracting After Candidate Selection

Once the End Client interviews and approves a candidate for the open position, the parties in the chain have to enter into contracts. Depending on the length of the chain, a number of different contracts have to be entered into, with varying degrees of uncertainty for each. In our example, End Client A has to sign a work order with Prime Vendor ABC. Similarly, ABC and GHI, GHI and YZA, YZA and NOP, and NOP and Candidate have to agree on and sign individual work orders.

Issue 6: Signing multiple work orders and contracts before the commencement of the assignment invariably adds time and uncertainty to the process. Any step in the process can be a point of delays or failure.

 

Step 3: Post-Contractual Processes

Once the contracts have been signed, the candidate can start working on the assignment. After the candidate (now consultant) starts the assignment, his or her work can be quantified by timesheets. Timesheets are submitted periodically by the consultant to the End Client’s representative (usually the consultant’s immediate supervisor). Once a timesheet is approved, it sets off a chain of events:

  1. Consultant sends the approved timesheet to the different links in the contract chain (i.e. NOP, YZA, GHI, ABC).
  2. NOP invoices YZA, YZA invoices GHI, GHI invoices ABC, and ABC invoices End Client A based on the timesheet.
  3. End Client A pays ABC in accordance with the bill rate.
  4. Sequentially, ABC pays GHI, GHI pays YZA, YZA pays NOP, and NOP pays the Consultant.

The following issues are prominent in this process:

Issue 7: The Consultant who performs the work is the last entity in the process to get paid. This causes ongoing stress in the process, since in many cases the Consultant is an individual who can least afford to wait for his or her payment.

Issue 8: There is no transparency in the process, so it is easy for one of the links in the chain to delay the entire process. In our example, if say, GHI informs YZA that they have not been paid for a specific timesheet, there is no way for YZA (or NOP further down the chain) to validate that that is indeed the case. GHI could easily introduce days or weeks of delay in the process unilaterally to mitigate their own cash flow issues.

 

Recommended Changes to Existing Processes Based on a Blockchain Ecosystem

In order to mitigate the 8 issues identified above, we recommend the following Blockchain-based process for the industry. This will, of course, be a significant change to existing job roles, but we believe it will bring a level of efficiency and transparency that can only be beneficial for all parties involved.

Our recommended solution consists of six parts:

  1. Distribute a fixed markup between different nodes in the process chain.
  2. Allow different companies to set automatic bids on markups paid to downstream vendors.
  3. Publish and track the Job Requirement and Submissions.
  4. Use Smart Contracts to generate work orders between parties automatically.
  5. Publish timesheets as work transactions.
  6. Make split payments simultaneously to all parties in the process and publish transaction history.

 

Part 1: Distribute a fixed markup between different nodes in the process chain

One of the major objectives of the End Client is to pay a low, deterministic markup on the direct wages of the temporary worker. This is impossible to achieve with the current process unless the End Client limits submissions to 1 level (only Prime Vendors). Unfortunately, this also severely jeopardizes the End Clients’ first objective – which is to find the most suitable candidates – by limiting the pool of recruiters looking for candidates.

We recommend that the End Clients publish a fixed markup for each job. This markup will be distributed to each link in the chain, thereby keeping the total markup fixed for the End Client.

As an example, the End Client could set a fixed markup of 25% for a job. So if the direct wages paid to the consultant are, say, $100 per hour, the End Client will always pay $125 per hour irrespective of how many Vendors are in the chain. The $25 markup will be distributed to the Vendors in the chain based on our recommendations in Part 2 of this section.

Benefit 1: End Client pays a fixed deterministic markup for each job.
Note: This solves for Issue 3.

Part 2: Allow different companies to set automatic bids on markups paid to downstream vendors

This part deals with how the fixed markup will be distributed between the multiple Vendors in the chain. We want to achieve two goals here:

  1. Requirements/submissions/contracts should only follow one fixed path. There should be no confusion about, say, which Prime Vendor a Sub Vendor is working with on a particular job requirement.
  2. Decisions on which path to choose should be deterministic, so as to eliminate the possibility of personal biases.

As such, we propose that:

  1. Each Vendor in the chain publishes a Maximum commission rate (to pay) and a Minimum commission rate (to receive) for each job requirement. The Sub Vendor in the next tier of the chain automatically picks the Vendor with the highest pay commission rate, as long as this is greater than their receive commission rate.
  2. Vendor assignment is done through an automated bidding system, so the process respects the economic leverage each party in the transaction has. If a Sub Vendor receives a specific requirement from only 1 higher tier vendor, then it has no leverage in the bidding – it can only pick the 1 higher tier vendor. However, if the Sub Vendor receives the requirement from 2 or more higher tier vendors, then the Sub Vendor has greater leverage and the higher tier vendors have to bid for it’s services.

Here is a full example to demonstrate both Parts 1 and 2.

  1. End Client A publishes a job with a maximum markup of 25%.
  2. Prime Vendor ABC gets the job and passes it on to their Sub Vendors with a maximum pay commission rate of 50%. This means that 50% of ABC’s share of the overall markup will go to the Sub Vendor.
  3. Prime Vendor DEF also gets the same job and passes it to their Sub Vendors with a maximum pay commission rate of 60%.
  4. Vendor PQR is a Sub Vendor for both ABC and DEF, and has set a minimum receive commission rate of 25%.
  5. Since both ABC and DEF are offering more than the minimum rate, the system will automatically bid and assign PQR to Prime Vendor DEF, with a commission rate of 51% (or 50.1%, or the minimum incremental amount as set in the system).
  6. This assignment is only valid for that one job. The same process will be repeated for every job.
  7. Now lets say, PQR finds a candidate with a direct wage rate of $100. This candidate is selected by End Client A and starts on the project.
  8. End Client A will pay $125 per hour ($100 + 25% markup).
  9. Of this, PQR will receive 51% of $25 = $12.75. DEF will receive $12.25.

Here is another example, where the Prime Vendor has the leverage.

  1. End Client A publishes a job with a maximum markup of 25%.
  2. Prime Vendor ABC gets the job and passes it on to their Sub Vendors with a maximum pay commission rate of 50%.
  3. Vendor PQR is a Sub Vendor for ABC, and has set a minimum receive commission rate of 25%.
  4. Since PQR has only received the job from ABC, no auto-bidding is required. The system will set the commission rate for PQR at 25%.
  5. Now lets say, PQR finds a candidate with a direct wage rate of $100. This candidate is selected by End Client A and starts on the project.
  6. End Client A will pay $125 per hour ($100 + 25% markup).
  7. Of this, PQR will receive 25% of $25 = $6.25. ABC will receive $18.75.

The same process will be followed n links down the chain. When a Vendor submits a candidate there will always be only one pre-determined path to the End Client for the submissions and eventual contracts.

What makes this workable is that this data is available to all the Vendors in the process – so everyone knows who they are working with and how much money they stand to make for finding the selected candidate.

Benefit 2: Vendors continue to be incentivized to share jobs with Sub Vendors, because if any link in the chain succeeds in the given task (of finding the candidate) all links above it in the chain benefit.

Note: This maximizes coverage of the requirement and helps satisfy the End Client’s primary objective.

Benefit 3: There is never any confusion about the path followed for submissions. The path is determined even before a Vendor starts looking for candidates, and it is published to everyone.Note: This solves for Issue 1.

 

Part 3: Publish and track the Job Requirement and Submissions

When an End Client publishes a new job requirement, we propose it be published openly to the group of Vendors working on it. This group is expandable based on the distribution of the job by Prime and Sub Vendors.

The process will work in the following manner:

  1. End Client publishes a new job requirement, shares it with Prime Vendors.
  2. Prime Vendors set maximum commission rates and share it with their Sub Vendors.
  3. Sub Vendors can choose to accept the job. If they do, they are allocated to a Prime Vendor based on the process described in Part 2.
  4. By accepting the job Sub Vendor gets full access to all job details in the group, including submissions.
  5. Sub Vendors can further share job with their own Sub Vendors. Each Sub Vendor that accepts the job will be included in the group.
  6. Any Sub Vendor that finds a suitable candidate can submit his or her profile directly to the group. There is no need to go through the full chain since the payment/contract hierarchy is already established.
  7. If a candidate has already been submitted through a different Vendor/Prime the system will not allow a second submission.
  8. Submitted candidates will also be part of this group, and can track that their profile has been submitted by the company that they have contracted with.

A major assumption here is that the screening process for different Sub Vendors and Prime Vendors is qualitatively similar. This may not be true initially, but our contention is that eventually the screening and vetting will also be automated to a degree that this will become the case. The system will also self-regulate bad Vendors (indiscriminate submissions of poorly qualified candidates) since their submission history will be visible to everyone.

Benefit 4: Irrespective of the number of links in the staffing chain, candidates only need to be screened and submitted by a single company.

Note: This solves for Issue 2.

Benefit 5: Introduces trust in the process, because all parties know which candidates were submitted by which companies, what the contract path is, and what everyone’s share in the process is. There is no possibility of poaching, or of cutting out one of the links. There is full visibility and transparency throughout the process.

Note: This solves for Issues 4 and 5.

 

Part 4: Use Smart Contracts to generate work orders between parties automatically

Once a candidate is interviewed and selected by the End Client, the only party that needs to accept the assignment is the candidate himself/herself. All the intermediary Vendors have already implicitly accepted the assignment by agreeing to work on the job requirement. Also, the financial terms of each contract have already been set through Parts 1 and 2. As such, we propose that immediately on the candidate’s acceptance of the assignment, the system creates automated Smart Contracts between all the parties in the chain.

Benefit 6: Eliminates any delays in the process while multiple parties agree on contract terms. Contract terms are set when the Vendor agrees to work on the job requirement. The smart contract triggers the same terms.

Note: This solves for Issue 6.

Benefit 7: Negotiations after the fact can be handled entirely between only two parties, the End Client and the Consultant. If these two parties agree on a negotiated amendment to the wage rate, all other contracts will get adjusted accordingly.

Note: This solves for Issue 6.

Part 5: Publish timesheets as work transactions

Timesheets generated by the consultant and approved by their supervisors at the End Client are considered proof of work in the temporary staffing industry. We recommend continuing with that system, with one significant change.

All timesheets and their approval statuses should be published and available to all parties in the Vendor chain. This allows everyone in the process to plan and react to any changes.

Benefit 8: Timesheets as proof of work will be available to all parties. Any approval delays can be tracked and resolved with the End Client.

Note: This solves for Issue 7.

 

Part 6: Make split payments simultaneously to all parties in the process and publish transaction history

Payments will be initiated based on timesheet approval. Since approval of a timesheet is contractually taken as proof of work done, there is no need for further payment approval.

We recommend a significant change to the payment process itself. The current process is that of sequential payments – the End Client pays the entire billable amount to the Prime Vendor, then the Prime Vendor pays a contracted amount to the Sub Vendor, and so on until the Consultant gets paid.

We recommend that each party in the contract chain get paid their respective share of the total billable amount simultaneously.

As an example, say the Consultant’s direct wage rate is $100 per hour, the share for the Sub Vendor is $12.50 and the share for the Prime vendor is $12.50 for total markup of $25. On approval of a timesheet, End Client will pay $125, the Consultant will receive $100, and the two Vendors will receive $12.50 each. There is no need for sequential payments.

All the transactions are published in the public ledger for the job, without the actual dollar amounts. This way all parties know exactly when payments were made and to whom.

Benefit 9: All parties get paid instantaneously once End Client approves work. No Vendor can hold or delay payments to lower layers.

Note: This solves for Issues 7 and 8.

 

Technical Implementation

We will not delve deeply into the technical implementation details of the solution in this document. Given the newness of the concept and technology, there are multiple evolving ways of implementing the recommendations presented here – for example, Ethereum or IBM’s Hypervisor platforms – and we leave it up to the responsible system implementation teams to pick the most suitable platform for their needs. In general, the architecture will comprise of a blockchain platform and a set of RESTful APIs that can be used to connect the platform to existing Applicant Tracking (ATS) or Vendor Management Systems (VMS). As a point of reference, the Appliqant solution is built using the Ethereum platform, and we use AWS API Management to expose the blockchain to our user-facing applications.

HireCoin (TBD) – Cryptocurrency to Drive the Appliqant Blockchain

A natural next step for the environment is to enable cryptocurrency transactions within our blockchain. Since Appliqant is built on the Ethereum platform, we can already use Ethereum as a means of transaction. However, in order to further improve efficiencies and reduce transaction costs, we will be moving to a lightweight crypto that only enables money flow in the Appliqant hiring process.

 

Summary

To summarize, our new blockchain-based business process addresses all of the major issues in today’s staffing and recruitment industry. The specific benefits of the process are:

  1. End Clients will pay a fixed deterministic markup for each job.
  2. Vendor network is incentivized to share jobs across tiers and pool in resources.
  3. Submission path/hierarchy is pre-defined before Vendors start working on sourcing.
  4. Candidates only need be screened and submitted by one company.
  5. Establish full trust and transparency in the process.
  6. Eliminates delays in creating contracts/SOWs between various entities in the chain.
  7. Negotiations can be limited to only the End Client and the Consultant.
  8. Timesheets as proof of work accessible to all stakeholders.
  9. All parties get paid instantaneously once work is approved by the End Client.

It is obviously and definitively beneficial for End Clients and Consultants/Temporary Workers. However, we can expect some resistance to change from the staffing industry as their processes and job roles will be significantly impacted. The technology exists already, but adoption will have to be driven by End Clients who can break through the change-resistance of many Vendors. Over time, we believe most Vendors will also realize that this is a fairer, more equitable process which will be to their benefit.

The Appliqant platform offers this process in addition to its core interview automation features. Companies using Appliqant can easily switch to this model for their recruitment needs.

Leave A Comment

Contact Info

1345 Avenue of the Americas, New York, NY 10105

Phone: +1 (212) 768-8900

Bitnami