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.
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:
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 PayPal.me code in user’s profile view. If set, we will use the code to construct a PayPal.me link in the Request view shown to requester. Using PayPal.me 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:
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: 'https://contentglass.cloud'
Server time: 'Mon, 16 May 2022 17:26:46 +0300'
Sent to user: 'abcefg'
Sent to email address: 'abc.efg@gmail.com'
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.
Copyright 2021 - Rhizome Networks LTD
Requests