Internal review · 30 September 2026 · Not for public announcement
Scope of Work — Points, qualification, and paid opportunities
This is the version we build on the product we already have. It changes how earning works. It does not rebuild VIREL. Coding starts after the open decisions at the end of this document are agreed.
Growth should make the member base more valuable. It should not automatically increase what VIREL owes every day.
Today, a completed opportunity usually creates an immediate cash liability, whether or not a client is paying for that activity. A larger membership therefore costs more to keep active.
The new model separates participation from paid work.
Participate → earn VIREL Points → build activity and a work profile → become eligible for paid opportunities → complete the paid work → earn cash → withdraw cash.
If a client needs 100 people, the other members stay in the workforce and keep building a profile for work that fits them. VIREL does not manufacture cash tasks to keep everybody earning. The size, activity, and quality of the member base become something we can match to client demand.
VIREL Points are qualification. The cash wallet is money.
| Concept | What it is | What a member can do with it |
|---|---|---|
| VIREL Points (VP) | A record of participation, experience, and qualification. There is no conversion rate. 100 VP is not ₦100. | See the balance and the history. Use the balance, together with account status and campaign rules, to qualify for paid work. Points cannot be withdrawn, converted, transferred, or sold. |
| Cash wallet | Naira earned from an approved paid opportunity, plus any cash already in the wallet. This is the wallet members already have. | Withdraw to a bank account under the withdrawal rules that already exist. |
| Level | The six levels we already have: Novice, Explorer, Achiever, Champion, Elite, Legend. They stay. They are not a second points system. | This version does not redefine what each level unlocks. A paid opportunity may optionally require a minimum level, using the field that already exists. |
| Squad points | The existing squad score. It is unrelated to VIREL Points. | Leave squads, streaks, milestones, badges, rankings, and referrals as they are in this version. |
We are proving that members will keep participating when they can see that qualification leads to real paid work. We are not proving that people enjoy collecting points.
| Step | What the member does | What the product does |
|---|---|---|
| 1 | Completes a Point Opportunity | Credits VP only after the required check passes. Shows “+VP”, with no naira amount. |
| 2 | Reaches the agreed qualification | Balance, history, and any profile answers are saved. Editing later does not pay the VP again. |
| 3 | Sees a real Paid Opportunity | Shows the naira reward, the slots, and the requirements. If the member is short of a requirement, the screen says which one. |
| 4 | Does the paid work and submits proof | Uses the proof review we already have. A full slot list does not create a payment. |
| 5 | Proof is approved | Naira is added to the existing wallet. The notification says the naira amount was added to the wallet. |
| 6 | Withdraws | The existing withdrawal flow pays the bank. The pilot is complete only when that payment happens. |
These stay in place. This version connects them to the new earning logic.
| Already in the product | How this version uses it |
|---|---|
| Opportunities | Each opportunity becomes either a Point Opportunity or a Paid Opportunity. Current live opportunities remain paid. |
| Campaigns | A campaign remains the client, brand, or project. Opportunities remain the individual actions inside or connected to that campaign. |
| Slot limits | Paid opportunities use the existing participant cap. Approval already refuses to pay once the cap is full. A paid opportunity must have a cap greater than zero. |
| Proof review | Same submission, same approve and reject flow, same duplicate check. The credit and the notification depend on the opportunity type. |
| Cash wallet and withdrawals | Approved paid rewards use the existing credit into the wallet, then the existing bank withdrawal. The wallet is not replaced. |
| Monetized and Verified | A paid opportunity can require either status. Both already exist on the member. |
| Levels 1–6 | Kept. Optional minimum level on an opportunity stays available. The six levels are not redesigned in this version. |
| Allow list on an opportunity | The pilot group is an allow list. Members outside that list do not see the new Point Opportunities or the pilot Paid Opportunity. |
| Notifications, Help & Support, milestones, streaks, squads, badges, rankings, referrals | Left as they are, except the approval notification text, which must name VP or naira correctly. Help articles are updated before any public rollout, not as part of the first build. |
Modifications to features that already exist
| Area | Change | Where |
|---|---|---|
| Opportunity | Add a type: Point or Paid. Existing opportunities default to Paid, so current cash tasks keep paying naira. The current reward field remains the naira amount for a Paid Opportunity. A Point Opportunity stores a separate VP amount and must not write to the wallet. | API, Admin, App |
| Opportunity card | A Point Opportunity is visibly different from a Paid Opportunity. Point cards show “+VP” and no naira. Paid cards show the naira reward, the slots, and the requirements, including the minimum VP. | App |
| Proof approval | On approval of a Point Opportunity: credit VP and notify “+VP added to your VIREL Points.” On approval of a Paid Opportunity: credit the existing wallet and notify “₦ added to your Wallet.” Rejection, a duplicate, or a full slot list credits nothing. | API, notifications |
| Publish rule for paid work | Before a Paid Opportunity can leave draft, Admin must see and confirm the maximum payout: reward per person × number of slots. A Paid Opportunity with unlimited slots cannot be published. | Admin, API |
| Who can see a paid opportunity | Show it when the member meets the opportunity’s rules. When they do not, show the first rule they still need. Enough VP is one requirement. It does not guarantee a slot or a selection. | API, App |
| Member home | Add a VIREL Points balance to the existing dashboard. Keep the cash wallet where it is. The member should be able to tell four facts apart: VP, level, paid opportunities currently open to them, and cash. | App |
| Level progress display | Stop showing the Explorer threshold as a naira amount. See the note below. Do not invent new levels, and do not retune all six levels in this version. | App |
This is a display of the current level threshold. It is not a cash balance and it is not the new qualification rule.
Level today is calculated from lifetime cash credited to the member. The progress screen then prints each level’s stored threshold with a naira sign. The product default for Explorer is 1,000. The live screen shows about ₦8.9 billion because that is the threshold currently stored for Explorer, displayed as money. Every level also shows a 1× reward, so the multipliers are not creating the figure.
This version corrects that presentation so members are not told they must earn billions of naira to reach Explorer. It does not rebuild the level ladder. Later, once the points model is proven, we decide what Novice through Legend should unlock. Until then, level is status on the dashboard, and paid-work access is decided by VP, account status, history, and the campaign’s own requirements.
New pieces. Kept small enough to prove the journey.
| Item | What it includes | Acceptance |
|---|---|---|
| VP balance | Two fields on the member: current VP and lifetime VP. Nothing that writes the cash wallet writes these fields. | A wallet credit leaves VP unchanged. A VP credit leaves the wallet unchanged. |
| VP history | A separate ledger: amount, source, opportunity, balance after, date. Member-facing history is this ledger, not the money transactions. | Each credit and each admin adjustment appears once, with a reason. |
| Admin adjustment | Admin can add or remove VP. Every adjustment stores the amount, the reason, the admin, and the date and time. | An adjustment with a blank reason is rejected. The audit row is visible afterwards. |
| One Point Opportunity for the pilot | Title, campaign if any, instructions, link if needed, the check required, the VP amount, who can see it, start and end. The exact activity and the VP amount are an open decision below. A work-profile form is a candidate, not a decision already made. | Completing it once credits the agreed VP. Doing it again, or editing answers later, credits nothing. |
| One Paid Opportunity for the pilot | Title, campaign, instructions, naira per person, number of slots, maximum payout, minimum VP, optional level, monetized and verified flags, proof requirement, start and end. VIREL may fund this first one as a controlled test. | It cannot be published until the maximum payout is shown and confirmed. An approved completion credits that naira amount to the existing wallet. |
| Eligibility check | The smallest rule that can explain a yes or a no: pilot list, minimum VP, monetized if required, verified if required, minimum level if set, campaign allow or block list, and slots remaining. Approval and rejection history stays available so a later version can add quality without a new system. | A pilot member who is short of one rule sees that rule. A member with enough VP is still blocked when another required rule fails, or when the slots are full. |
| Qualification tag | A completed Point Opportunity can attach a simple tag, such as profile complete, so later campaigns can require it. Tags are labels. They are not a score. | The tag is written once, with the VP credit, and can be read when checking eligibility. |
| Pilot gate | Admin can add and remove the test accounts. Only those accounts see or earn on the new Point Opportunity and the pilot Paid Opportunity. Everyone else’s current opportunities and wallet stay as they are. | An account outside the list cannot see the new cards and cannot be credited VP from them. |
| Pilot events | Record the events listed in the measurement section, so the pilot is judged from data. | We can answer how many participated, how many became eligible, how many were paid, and where people stopped. |
One Opportunity record. Two reward paths. Campaigns stay the parent.
| Field | Point Opportunity | Paid Opportunity |
|---|---|---|
| Campaign | Optional. When set, this action belongs to that client or project. | Required for client-funded work. The campaign is the activation. This opportunity is one paid action inside it. |
| Reward | A whole number of VP. No naira field is shown to the member. | Naira per participant, using the reward field that already pays the wallet. |
| Slots | Optional. Unlimited is allowed, because a point task creates no cash liability. | Required. Maximum payout = naira × slots, calculated and shown before publish. |
| Check before credit | Whatever the opportunity requires. A simple validated form may auto-complete. A task that needs proof waits for approval. | Proof approval, using the current review. Auto-approval is not the default for paid work. |
| Where the reward goes | VP balance and VP history. | Existing wallet and the existing money ledger. |
| Repeat completion | No second VP credit for the same member on a one-time opportunity. | The existing duplicate-proof rule. A second approval does not pay again. |
Points open a door. They do not reserve a job.
| Check | Rule | If it fails |
|---|---|---|
| Pilot | Account is on the allow list for this opportunity. | The opportunity is hidden. Non-pilot members see none of the new pilot work. |
| Minimum VP | Current VP is at least the number set on the opportunity. Zero is allowed when we want an open paid task. | “You need N more VP.” The member can still see the opportunity and what it pays. |
| Monetized / Verified | Required only when the opportunity says so. | The screen names the missing status. |
| Level | Optional, using the minimum level that already exists. Leave it unset on the first pilot unless we explicitly want it. | The screen names the level required. |
| Tag or profile fact | Optional. For example, a later campaign can require the profile tag, a state, or a language once we are collecting those answers. | The screen names the missing requirement in plain language. |
| Slots | Approved completions are still below the cap. | The opportunity shows as full. Completing it after that does not create a payment. |
We know the maximum we can owe before a paid opportunity goes live.
| Input | Example |
|---|---|
| Reward per participant | ₦2,000 |
| Paid slots | 100 |
| Maximum participant payout | ₦2,000 × 100 = ₦200,000. Admin calculates and displays this before publish. The opportunity stays in draft until that figure is confirmed. |
| Client-funded campaign | The campaign budget is recorded against that maximum before launch. The first pilot may be funded by VIREL itself, and that funding source is written on the opportunity. |
Small changes to the dashboard and the opportunity list. No new home screen.
| Surface | What the member sees |
|---|---|
| Dashboard | VIREL Points, for example 185 VP. Current level, for example Explorer. How many paid opportunities are open to this member. Cash wallet, unchanged. |
| Point Opportunity | Marked as a Point Opportunity. Reward shown only as +VP. No naira on the card, the success state, or the notification. |
| Paid Opportunity | Marked as a Paid Opportunity. Naira reward, slots, and the requirements. A shortfall is explained. A full list is shown as full. |
| VP history | A list such as “Audience survey +10 VP”. Separate from wallet transactions. |
| Notifications | “Proof approved — +10 VP added to your VIREL Points.” or “Proof approved — ₦2,000 added to your Wallet.” |
| Everyone outside the pilot | No new cards, no VP balance, no change to how their current opportunities pay. |
People who already earned cash under the current model keep that cash.
Current wallet balances stay. Nothing in this version converts old earnings into points or points into naira.
Opportunities that are live today remain Paid Opportunities. They keep paying naira on approval.
During the pilot, Point Opportunities and the pilot Paid Opportunity are visible only to the test accounts. The two types can exist at the same time.
A founding-member VP allocation for eligible existing members is a later decision. The amount waits until the points rules and the first paid threshold are agreed. It is not part of the first build.
Record these now so we do not have to rebuild the history later.
| Event | Why we need it |
|---|---|
| Point Opportunity viewed, started, completed | Did people participate, and where did they stop? |
| VP credited, including source, amount, and balance after | How fast did qualification build, and from which activity? |
| VP adjusted by admin | The audit trail, separate from earned activity. |
| Paid Opportunity viewed, and the unmet requirement when blocked | How many became eligible, and which rule stopped the others? |
| Proof submitted, approved, rejected | Did eligible members finish the paid work, and was the work acceptable? |
| Wallet credited from the paid opportunity | Confirms the naira landed in the existing wallet and not in VP. |
| Withdrawal completed | The pilot includes a real bank payment, not only an in-app balance. |
Leave these out so the pilot stays about one behaviour.
Any conversion between VP and naira.
Transfers, a marketplace, or selling points.
A new wallet, a new campaign system, or a new proof system.
A second level ladder, or a redesign of all six levels.
Rebuilding streaks, squads, milestones, badges, rankings, or referrals.
A scoring model for quality, reliability, or capability.
A general questionnaire builder and a full states-and-LGA dataset. If the agreed first Point Opportunity is a short profile form, that form is fixed. The builder waits until a second opportunity needs it.
Cash tasks created only to keep members busy. Help articles, a public announcement, and the founding-member grant wait until after the pilot rules are agreed. Help articles are updated before any rollout beyond the pilot.
Each phase is usable on its own. The paid opportunity is in this version, not a follow-up project.
| Phase | Work | Done when |
|---|---|---|
| 0. Agree | Close the decisions in the next section. No implementation before that. | The first Point Opportunity, the first Paid Opportunity, the VP amounts, the threshold, and the pilot list are written down. |
| 1. Ledger | VP balance, lifetime VP, VP history, admin adjustment with audit, opportunity type defaulting existing tasks to Paid, pilot allow list. | VP and wallet can be credited independently. A non-pilot account is unaffected. Existing opportunities still pay naira. |
| 2. Point path | Admin can create the agreed Point Opportunity. The app shows it to the pilot only, credits VP once, and shows history and the dashboard balance. | A pilot account completes it and sees +VP. Repeating it does not pay again. The wallet does not move. |
| 3. Paid path | Admin creates the Paid Opportunity. Maximum payout is shown before publish. Eligibility explains a shortfall. Proof approval credits the existing wallet. | A qualified pilot member is paid naira into the wallet. An unqualified member sees the missing requirement. A full slot list does not pay. |
| 4. Pilot | Run the full journey on the test accounts, including one real withdrawal. Read the events. Adjust the threshold, the point tasks, or the paid offer from that data. | At least one pilot member goes from a Point Opportunity to a bank payment. We can say where others stopped. |
These are product choices. They are not implied by the technical work above.
| Decision | Needed from | Note |
|---|---|---|
| The first Point Opportunity | Client and product | A work-profile form is a strong candidate because it also tells us who the member is. The VP amount is agreed here. It is not fixed at 2. |
| Profile questions, if that is the first activity | Client and product | Choose the smallest set that helps matching, such as state, age range, language, and device. We do not hold a verified date of birth today. Social verification does not verify age, so an age range is an answer the member gives, not a verified fact. A full local-government list can wait. |
| The first Paid Opportunity | Client | The actual task, the naira reward, the slot count, the minimum VP, and whether VIREL funds it. |
| Pilot group | Client and operations | Who the 50–100 test accounts are, and who may add or remove them. |
| What “success” is on the pilot | Client | The numbers we will accept for participation, eligibility, completion, payment, and complaints, before a wider rollout. |
| Founding-member VP grant | Client, after the threshold exists | Who is eligible, and how many VP. Not built in the first phase. |
| What the six levels will mean later | Client, after the pilot | Access and privileges, not a naira multiplier. Out of this version except the display correction. |
What can stall the work, and what we are watching for
| Item | Effect |
|---|---|
| The open decisions above | Phase 2 and Phase 3 cannot be finished until the first point task, the first paid task, and the threshold are chosen. Phase 1 can be shaped without the VP amounts. |
| A real paid task and a budget for it | Without one funded paid opportunity, the pilot only tests point collection. That is the outcome this scope is written to avoid. |
| App store release | The member-facing changes ship in the mobile app. Apple and Google review sits on top of the build. The pilot accounts need that release, or a test build, before the journey can be run. |
| Naming | The opportunity reward field is already called points and it means naira. Squads already have a points ledger. VIREL Points must be a new balance with its own name in the API, the admin, and the app, so the three are not mixed. |
| Level thresholds stored in production | Correct the member-facing label. Do not use the stored Explorer figure as a qualification gate. Changing the stored thresholds is a separate product decision. |
| Client demand | The technology and paid campaigns have to grow together. If the pilot shows members earning VP with no realistic paid work behind it, we add entry-level paid work or change the point tasks. We do not invent cash tasks for everyone who was not selected. |
| Communication | Nothing in this scope is announced to the community until we agree the message. Help & Support is updated before a rollout past the pilot, so members can find answers on what VP is, why it cannot be withdrawn, and why a paid opportunity may be hidden. |
The version is accepted when a pilot account can do all of the following on the real product
Complete the agreed Point Opportunity and see the agreed VP, with no naira on that card or notification.
See that credit in VP history, and see the cash wallet unchanged by it.
Repeat or edit that activity and receive no further VP.
See the Paid Opportunity, including the naira reward and the requirement still missing, if any.
Submit proof, have it approved, and see the naira in the existing wallet.
Withdraw that balance through the current withdrawal flow and receive the bank payment.
Confirm a member outside the pilot never saw these opportunities and never received this VP.
Confirm Admin saw the maximum payout before the Paid Opportunity was published, and that an adjustment to VP has an admin, a reason, and a time.