Requests connect users that need help and are willing to pay some amount for getting help – we call them Requesters, and users  that can and want to help on a certain issue – we call them Helpers

Requester post a Request and Helper help to solve the issue described and specified by Request.

Requests app connect between Requesters and Helpers and provide the means to collaborate and manage a request's help session.


Yes. These are two modes of the app, and each user can play the both roles. In other words, if you use the Requester mode and you post a request, you considered to be Requester. If you are locking other user’s request for offering some help, you considered as Helper. The app provides a button to switch between modes.  The only thing to remember is that when you play as Requester, you see your Requests. If you play as Helper, you see requests made by other users. It might be confusing at first, but easy to get used to.  


It depends on what you do.

  • Posting requests is FREE.
  • For helping on request, user pay a fee (commission). The fee is charged from user's wallet at the moment of locking request.


A single Request is a post made by user that need help or assistance with some issue. Requests posts are stored on cloud and available for other users to view and lock.


No.  Rhizome Networks is not taking any side in the deal between Helper and Requester. This also means that as an Helper you get the entire payment given by Requester, without having to share your revenue. 


Yes for as long its status is pending. At the moment of posting a 'request' the status of a request is 'pending'. During this period, Helpers can view the request and decide if they can and want to help. Once an Helper lock a request, the request change to 'pending-approval' mode and stoped being public for new searches of requests.

Note that request item may still appear on non freshed search results, while it was already locked by an helper, Yet other helper can't lock it.

In addition, a 'request' may also be exposed on social-feed channels, such as Twitter, if user gave a consent in profile settings. Exposing on social-feeds may help to expose a request for wider audience of potential helpers currently not registered. Of course, a request can be handled only through the app, and after registration. 

IMPORTANT!!! Since 'request' is public you should never exposed private or secret details in the description of request. 




Request session is the life course of Request entity as resulted from collaboration of Requester and Helper. A request session includes few steps, and the status of Request entity is changed during these steps:

  • When request is just posted the status is ‘pending’.
  • When Helper want to solve a request, user lock a request and request status change to ‘pending-approval’.
  • If helper decide to abandon the request status go back again to ‘pending’.
  • When request is pending-approval, Requester is require to either Accept or Reject the Helper. If Helper is rejected, the status goes back to ‘pending’. If Helper is accepted, the status change to ‘in -progress’.
  • When status is ‘in-progress’ both sides require to collaborate in order to solve the issue. Users can collaborate in any way they choose, phone call, ,messaging, emails, video call, or any other collaboration means we provide such as Collaboration Dashboard.
  • When issue is solved, and only then, Helper request payment and status change to ‘pending-payment’.
  • When request is ‘pending-payment’ requester is must to pay to Helper the amount agreed, upon accepting the Helper.
  • If for some reason dispute arose, each side can move the request to ‘dispute state. Requester and Helper are the only one responsible to solve a dispute. Once dispute is solved both sides need to mark that dispute was resolved, and request goes back to ‘pending-payment’
  • After payment received by Helper, the Helper must close the Request and request status change to ‘closed’.
  • Finally, after request was closed, both sides can rate each other and write a review on each other.


Yes. Posting 'request' is free, meaning you do not have to pay for posting a request. Still, when creating new 'request' you have to set a payment offer,and amount you are willing to pay to Helper for helping you to solve an issue. When help is done you need to pay the agreed amount to Helper.



Yes, a limit exists. An Helper can lock up to three requests at a time.


Users can earn money by offering their help to users that post Requests, asking for help. You start by viewing available requests. Each request has a payment offer. Then lock a request you are willing to help with. You may set a bid either the same or different than payment offer.  Only one user can lock a request.  Once a request is locked, requester required to either accept or reject the locking helper. If you were accepted, you can collaborate for solving the issue, or maybe you need to make some tasks. It’s all depends on what the requester is actually asking for.  Once help was completed (and only then) you use the app to request a payment. The requester then is required to pay you, in whatever approach you both find as convenience.  Once payment received you close the request. That’s how you earn money.


Helper is charged for user fee for each time a Request is locked. The fees are summed, and the balance is shown by wallet. Helper can pay the usage fee in one of two ways: wait of a payment-request generated periodically or but a prepay ticket.


Yes. If you have an affiliate account on some affiliation network, and you find the situation is relevant for providing an affiliate link or affiliate code to Requester, then you can do that. Usually, combining affiliate links within help session, can be relevant, if for example you help to choose some product. 

One thing must be remembered - Requests was not created to be used as a channel for easy access to potential buyers of a product you promote. This is not the case. The help that you provide and the means that you use during this help must, before all - provides an answer to Requester's need.

In other words, as an Helper, you should not take advantage of help session to push things that Requester does not ask. If you decide to provide an affiliate link it must be relevant to case. Remember that at the end of help session, you may will be rated by the Requester, so make sure you provide an accurate help for a need and do not take an opportunity to push an unrequested promotions. 






Handling a 'request' costs at the moment $1 per request. The fee for handling a 'request' is named: 'Request Handling Fee' (RHF). We charge RHF of $1 from your wallet whenever you lock a 'request'. Periodically we scan users wallet and generate 'Payment Request' . The payment-request is presented to you on app's dashboard, and you need to pay the requested amount before you can lock more requests.


We charge the 'Request Handling Fee' (RHF) at the moment when Helper lock a 'request' for simple reason: we do not want users to lock as many requests as possible, when according to type, and nature of request content, they are not a suitable Helper for the job. In addition, only one Helper can lock a request at a time, so when Helper lock a request, other helpers can't lock the request. We want users to lock requests only when user is quite sure in own ability to help with the issue presented by a 'request'.



No. Requests app does not pay to users. Requests app connect Requests and Helpers and provide a way to collaborate and manage a help session.


Requester pay to helper using any payment means agreed by both sides of the deal. We do not force specific payment means.

Requests app, do provides Helper with an option to set code in user’s profile view. If set, we will use the code to construct a link in the Request view shown to requester. Using is of course, optional. Requester and Helper can use any payment app, use cache, or whatever payment approach the choose.

It is HIGHLY recommended to agree on payment means before collaboration is started.  



App’s wallet is used to manage user’s balance. For example, the fee for locking a request is charged from wallet’s balance. An amount granted by  a coupon or earning from referral program is added to wallet’s balance. Although the wallet shows positive or negative balance, it is not connected with real payment means. It only used as a log for managing the balance.


No. You can’t withdraw balance and exchange it to real money. The balance in your wallet can only be used internally as source for collecting usage  fees or as source for paying of advanced features.



Yes. Since money transaction is involved, either between users, or as Helper, when paying usage fee, and account can be created by users that have the authority in their country to use payment means. Usually, this age is 18 years old. For example, as Helper you will require to pay usage fees via PayPal, so a user must have a PayPal account. Since PayPal account has age limit this limit also apply to Requests.



Users of Content Glass Cloud, including users that uses Requests app may receive the following mail types:

  • Account create
  • Email verification
  • Reset password
  • Close account verification
  • Special cases such as re-activate or closing an accounts.
  • Technical Support ticket response (including auto response)

The first four mail types above, are sent with message details section on the bottom of the mail.  Message details can help you to identify the source of mail. The unique code (as of 16/05/22) can be used to verify that mail is authentic. you can do this test by entering the user-console with your user credentials, there under 'Monitoring' click the 'Mail Activity' to show report of sent mails. If mail was sent to you it is expected that you can find a record with match unique-code. System mail uses minimalist plain-text style and  look "boring". The only call to action there are links for confirming email or reset password.

Example of message details:

Message details:
 Sending host: ''
 Server time: 'Mon, 16 May 2022 17:26:46 +0300'
 Sent to user: 'abcefg'
 Sent to email address: ''
 Unique code: '62d825sdf26c3bffa7a'

In addition, our service terms do not allow users to promote their referral-code, using mail-campaign, neither to present themselves as affiliates of Rhizome Networks.

The bottom line should be clear - we think that mails should be used only for essential system notices. We do not use mail-campaign for promoting our services and we do not allow users to use mail-campaign for promoting assets related with our apps and services. We certainly DO NOT send solicit mails.

In the case that you received a suspicious mail, that carry our brand, pretend to be sent from our systems,  without any action you took, for example without sign-up, ask to reset password or ask to close account, and without having the style and content characteristics described above - you should assume that this is a spam and you should delete the mail.