search
Quick Links
Terms
THE FOLLOWING DESCRIBES THE TERMS ON WHICH REMOTEHIREMAN DEALS WITH YOUR DISPUTES.
Content
  1. Language
  2. Acceptance Of Deliverables
  3. Rules Of Arbitration
Language
You agree to use English, French, Spanish or Chinese in all communications on the site to allow RHM to properly arbitrate in the case of a dispute. Should the user violate this and RHM determines it cannot deliver a fair arbitration, the user will forfeit arbitration.
Acceptance Of Deliverables
After coding is completed, the deliverables will be sent from the Seller to a location on the site where the Purchaser may download them.

If the deliverables are 100% satisfactory to the purchaser, then Purchaser agrees to indicate 100% acceptance of the deliverables via the web site (or a partial acceptance if the deliverables are only partially complete and satisfactory based on pre-agreed upon milestones) via the arbitration procedure.

Purchaser assumes sole and complete responsibility for adequate testing to determine for themselves whether or not the deliverables are 100% satisfactory or not (or partially satisfactory if pre-agreed upon partial milestones have been created). Purchaser agrees to never accept any work before deliverables have been 100% tested and they are 100% satisfied. If against the wishes of RHM, Purchaser accepts work without the above two items being true, Purchaser agrees that the acceptance and payment fall under the risky category of "advance payments" as detailed elsewhere in this contract, and can result in a loss of funds for the Purchaser. RHM cannot discourage this sort of high risk activity enough.

Realizing that the Seller will not be credited until work is fully or partially accepted, the Purchaser agrees to do all testing in as timely a basis as possible. Purchaser also agrees not to withhold acceptance unreasonably.

Should the Purchaser not be 100% satisfied, then Purchaser agrees to not accept the work and instead notify the Seller as well as RHM of the problem in a timely basis so that it can be resolved. Should there be any dispute by either Purchaser and Seller regarding acceptance, both Seller and Purchaser agree to abide by the RHM rules of arbitration in later section.

Rules Of Arbitration
These rules of arbitration exist to ensure a fair and safe environment for the buying and selling of computer software and related systems. Should a dispute arise over the completion of a project, the allocation of escrowed funds, or any other issue, both Purchaser, Seller and RHM agree to the following rules:
  • About Mediation / Arbitration

    Should the Purchaser and Seller not be able to come to agreement on acceptance, (including but not limited to whether deliverables have been met and bid acceptance should occur), both parties agree to designate RHM as sole mediator and arbitrator (two distinct roles). RHM agrees to mediate and arbitrate fairly and impartially according to the rules in this section, as they apply. Purchaser and Seller agree that RHM's decision is final and binding to them and hereby waive any other further legal challenges or remedies including but not limited to civil or criminal litigation against the other party or RHM.

  • Mediation

    Before arbitrating (however after efforts have been done and both parties can definitively not come out to a solution ie: the site provide an arbitration message board which allow both party to discuss their argument and may come to an acceptable compromise so RHM do not have to interfer), RHM may attempt to first mediate a mutually acceptable compromise solution between both parties if it determines the option is a viable one. A mediated compromise can provide a quick and easy way for both parties to obtain a successful outcome, without the time and energy required by a full-blown arbitration. Both Purchaser and Seller understand and acknowledge that they are NOT required to accept any mediation proposals. RHM acknowledges that the refusal of any party to accept a mediation proposal will not affect its standing in the subsequent arbitration.

    If a mediation succesfully occurs in which the original contract is either reduced or cancelled, RHM will document what occured by placing a rating on one or both parties' records, as detailed below under "RHM Ratings".

    Should either party not agree to a mediation compromise, or should RHM (at it's sole discretion) determine that the option is not a viable one, the process moves on to arbitration (Still the same Message Board).
  • Arbitration

    Arbitration of the bid request is based solely on whether or not the Seller met the conditions specified in the Purchaser's 'Entire Request' (unless either Purchaser or Seller prematurely forfeits by the other rules of arbitration detailed below).

    The 'Entire Bid Request' is defined as:
    1. The original bid request posting on the site (which includes but is not limited to the description, attachment and deliverables)
    2 The subsequent clarifications and/or changes made in bids/comments from both sides in the site bidding/comment system.

    Both Purchaser and Seller agree that any discussions conducted outside of the site (including email, off-site chat and oral conversations over the phone) are NOT considered part of the 'Entire Request' and WILL NOT be taken into account.

    RHM has found that due to poor wording or lack of attention to detail, that sometimes portions of the 'Entire Request' contradict other portions or are unclear. In the event that either Purchaser or Seller disputes with the other party any portion of the 'Entire Request' (including but not limited to disputes over an alleged contradiction, interpretation, or applicability) RHM will be the final determiner of the best method of resolving the issue. It will make this determination using the most impartial method that it can, in good faith, formulate.

    Despite repeated warnings to both Purchaser and Seller to the contrary, occasionally RHM finds that both parties have neglected to use the site to detail key items of the 'Entire Request', withholding the information necessary to make what RHM feels is a "just" arbitration decision. This can happen due to a deliberate manipulation by one party and/or due to genuine ignorance of the consequences of such behavior by one or both parties. Should RHM determine this to be the case, it may extend the definition of the 'Entire Request' to include items not normally covered (such as 3rd party chat logs). However, neither Purchaser nor Seller may demand such an extension nor possess the "right" to such an extension. Instead Purchasers and Sellers agree to properly document the 'Entire Request' on the site as RHM warns, and not expect, or count on an extension to occur in any arbitration. Site users who repeatedly do not use the site to document the 'Entire Request' may be ejected from the site.
  • Quick Resolution Arbitrations

    If a Seller does not upload completed deliverables to the site by the delivery deadline posted by the Purchaser, then the Seller will be found in forfeit of the arbitration. However, to prevent an unscrupulous Purchaser from unfairly manipulating a Coder to obtain free work; should RHM discover evidence that it feels indicates that the Purchaser continued to work with the Seller after the deadline, then the deadline may be deemed "Implicitly Extended" by the Purchaser's actions nullifying the previous deadline and the above mentioned forfeiture.

    If the timezone for a deadline is ambiguous, then Purchaser and Seller authorize RHM to determine the time zone to be enforced, using whatever method it deems (in it's sole opinion) to be appropriate.

    If the Seller has already agreed to provide status reports prior to the arbitration and did not fulfill that agreement, then they also be found in forfeit of the arbitration. However, to prevent an unscrupulous Purchaser from unfarily manipulating a Coder to obtain free work, should RHM discover evidence that it feels indicates that the Purchaser continued to work with the Seller after the status report requirement was not met, then the Purchaser will be considered to have waived their rights to cancel on that particular missed stats report nullifying the previous deadline and the above mentioned forfeiture. Note: status reports are NEVER required of the Seller while arbitration is in process.
  • Insufficient Progress Arbitration

    If the Purchaser charges that the Seller is not making sufficient progress on a request, the Seller must supply specific demonstrable proof to the contrary. Examples of demonstrable proofs of progress are (depending on the level of progress expected) programming requirements, designs, prototype, code and/or test cases. If RHM determines that demonstratable proof of progress has not been supplied, the Seller will be found in forfeiture of arbitration.

  • Deliverable Dispute Arbitration

    The typical arbitration case involves a disagreement on what was delivered. The Purchaser typically claims that they did not receive 100% of the 'Entire Bid Request' and the Seller typically claims that they did provide this to the Purchaser.
    The only way to determine who is being truthful and who isn't, is to test the deliverables. When this occurs, an RHM tester will perform a "flaw list verification" where they compare the Purchaser's list of problems (the "flaw list") to the actual application/deliverables. Should one or more flaw list items be verified, then the Purchaser wins arbitration. Should no items be verified then the coder wins arbitration. The process works as follows.

  • The Flaw List

    First RHM will request a detailed flaw list from the Purchaser detailing exactly what the Purchaser contends was not delivered, and (if appropriate) instructions on how to duplicate the alleged behavior. Purchaser agrees to provide the above when requested by RHM, so that RHM can confirm or deny whether the original bid request requirements were met or not. Should the Purchaser not provide the flaw list then they will be found in default of arbitration. Note that all flaw list items will be screened per the "Flaw List Exceptions" rule below.

    An unscrupulous Purchaser who knows that they will lose arbitration, might be tempted to unfairly delay the inevitable payment to the Seller, by delivering flaw lists in 'piece-meal' fashion. To prevent this, the Purchaser agrees that any flaw list they present is the full, complete and final flaw list.

    Occasionally, the arbitrator may add items to the initial flaw list that they feel are pertinent, and these may even be items suggested by one of the involved parties. However, both Purchaser and Seller agree that only the arbitrator may do this, and that no other party may.
  • Testing Venue

    Since the deliverables must function in the Purchaser's environment for acceptance, and the Purchaser is the party creating the "flaw list", the Purchaser will be responsible for hosting the testing venue. However, if the coder is determined to have not released the deliverables in question to the Purchaser, the Coder will be responsible for hosting the testing venue. RHM does reserves the right to move responsibility for the testing venue to another party if it (in it's sole opinion) believes a fairer result may be achieved. Additionally, RHM may choose to host the testing venue itself, if it (in it's sole opinion) determines:

    a). that the arbitration venue responsibility would not be better served by either the Purchaser or the Seller
    b). that significant setup assistance will not be required from the Seller (since a Seller can take advantage of such a situation to do configuration tweaks that were not done on the Purchaser's system)
    c). that it has an existing environment adequate to testing the deliverables

    Both Purchaser and Seller agree that if required to provide the testing venue, they will provide RHM with access to all aspects of their environment that are necessary for RHM to:
    a). Verify or deny the Purchaser's claims in the flaw list
    b). Verify or deny that deliverables have been modified to cheat the testing process

    Note that these aspects may include (but are not limited to) software, hardware, documentation, remote access to systems etc. Should the party responsible for hosting the testing venue refuse to provide all aspects of the testing venue when required to, they will default on the arbitration and forfeit it.

    RHM may use file comparisons (and/or other means) to ensure that modification of deliverables does not occur by the testing venue host. If RHM (in it's sole judgment) determines that the host has modified deliverables to influence an arbitration unfairly in their favor, the host will forfeit arbitration, be found in default of their contract under the terms of 'fraud', and will have their account involuntarily closed.

  • Flaw List Exceptions

    Certain types of flaw list items will not be tested and must be removed from the flaw list. They include:

    a). Subjective Items:

    Items that cannot be objectively stated cannot be objectively tested. The Purchaser will be given the chance to restate them objectively, but if they do not, then they will be removed from the flaw list.

    b). Cosmetic Items:

    The Seller acknowledges and understands that they are expected to follow software development standards, which dictate doing adequate testing to ensure that the application received by the Purchaser contains all agreed upon functionality and in stable working condition. However, the Purchaser also acknowledges and understands that the complexity of modern software makes it impossible to create software that is 100% bug free (Windows is an excellent example).
    To ensure a fair test, certain items called "Cosmetic Items" will be removed from the flaws list. "Cosmetic items" are defined as flaw list items that are infrequent, do not affect the major functionality of the deliverables and can be corrected very easily. Some examples are a web page with the wrong background color or "typos" in a few data entry fields. Should items be found to be "cosmetic items" and the Seller actually wins arbitration, then they will be required to fully correct them before receiving payment.

    Note that should the tester determine that the frequency of potentially cosmetic items shows a lack of adequate testing by the Seller, then the 'cosmetic' items will NOT be removed from the flaw list.

    c). Setup program bug items:

    The flaw list may contain reference to items caused by a faulty setup program. Due to the exponential number of different computer configurations in the world, setup programs sometimes do not run perfectly on every machine. More importantly, sometimes these issues cannot be identified until they are run on a particular "problem configuration" machine. If the tester determines that one or more setup program related flaw items fall in this category and could not have been prevented by the Seller using adequate testing using their own equipment and proper testing measures commensurate with the bid request, then these flaw items will not be considered.

  • Forfeiting Arbitration by not responding

    Purchaser agrees to be prompt in corresponding with Seller and RHM, including final acceptance of 'Work Complete'. Should a Purchaser not respond to RHM arbitration communication in 3 days, they will forfeit arbitration at RHM's discretion. Should a Purchaser not fully comply with RHM requests to either certify Work Complete or produce a flaw list within 5 business days, then will forfeit the arbitration at RHM's discretion. If RHM determines a forfeit has occurred then the escrowed funds will be awarded to the Seller.

    Seller agrees to be prompt in responses to Purchaser and to RHM. Should a Seller not complete status reports prior to the beginning of the current arbitration or respond to RHM arbitration communication within a timely basis of 3 business days, they will forfeit arbitration at RHM's discretion. If RHM determines a forfeit has occured, then in addition to the Seller's bid being cancelled, all of the Seller's other bids which have been selected by Purchasers may be assigned to another (presumably more responsible) Seller. This may be done with or without notice to the original Seller.
  • When the Purchaser Wins Arbitration

    If the Purchaser wins arbitration, they may, at their option, apply the entire escrowed amount to a new Seller at no charge. RHMwill offer the Purchaser options (if available) of switching to other Sellers on the original bid, opening a new bid request to get new Seller bids, or otherwise offering to connect the Purchaser with Sellers for the purpose of completing the project.

    The Purchaser also has the option to cancel the bid request and request a refund of escrow funds. To compensate RHMfor the costs in this process, all refunds of this nature are subject to a 3.5% cancellation charge for the Purchaser. However, to compensate the Purchaser when cancellation is not their fault...should the Seller be determined by RHM to be "at fault" for the cancellation, then funds in the Seller's account (if available) will be used by RHM to lessen or completely eliminate this charge.

    If the Purchaser is awarded back 100% of their escrowed funds on a project, then they agree that the deliverables created by the coder may NOT be kept by the Purchaser. Purchaser agrees to relinquish possession by promptly and completely destroying all deliverables and copies of deliverables in their possession.

  • One Party Rating the Other Party

    To prevent 'retaliatory ratings', RHM reserves the right to suspend rating rights on either party and/or to remove/edit ratings that it judges to be either retalitory in nature or involving a "trade" of favorable ratings to avoid a deserved bad rating.