the last question

Referral tracking and rewards

Expanded referral screen with the top-three leaderboard. The same screen with the leaderboard collapsed into a sticky header above the referral list.

The same screen in two states. Left, the expanded leaderboard. Right, the sticky collapsed header leaves room for the referral list, filters and progress cards.

Images show design versions and explorations. Amounts and dates are example values. Open any image to see it at full size.

The problem

After receiving a referral code, the friend had to complete an application and meet the conditions for a reward. The referrer needed to follow both parts: where the application stood and what counted toward their earnings.

At Zepto, I worked on this experience for people joining as full-time workers or through Flex. The work covered both sides of a referral, from entering a friend’s code during an application to following their progress and earning rewards. It also included the internal tools for setting those rewards.

The rules differed between full-time and Flex work. A reward could depend on the friend’s attendance or order count, the referrer’s own activity, and the store they joined. The interface had to explain those conditions before someone referred a friend, then show what happened afterward.

Working through the design

The designs below follow the referral from checking an offer to applying, tracking work and receiving a reward, then show the internal tools behind those rules. They include alternatives from different design cuts, rather than one continuous shipped flow.

Finding an offer before referring

Before sharing a code, the referrer needed to know which offer applied to the place and type of work their friend would join. I explored city-based rate schedules and store-based offers. The reward conditions also differed by work type: Flex offers described daily activity requirements, while full-time offers specified attendance and the time allowed to complete it.

The store-based version used city selection, store search, and Nearby Stores and Other Stores tabs. Each store entry showed the potential referral amount. This separated finding a relevant store from inspecting its reward conditions.

The empty states needed to explain the scope of what was missing. No nearby stores did not mean no stores in the city. The nearby-list message suggested checking other stores. A separate city-level message said there were no available stores in that city.

Alternative store-offer states: empty Nearby Stores list, empty Other Stores list, no stores in a city, and a populated store list.

Four alternative availability states, not consecutive steps. The first two describe an empty list within a tab. The third describes an unavailable city. The fourth shows store entries with their offers.

Getting a friend into the application

The onboarding entry flow started with the Packman introduction and earning offer, then phone entry and OTP verification. I worked through the verifying, verified and incorrect-code states before the applicant reached the application.

Onboarding entry flow from the Packman introduction through phone entry, OTP verification states, the application checklist and referral-code entry.

The sequence in the Referrals file, including the OTP error state. Open the overview to inspect the screens at full size.

The referral code was optional. I kept it separate from the work details and document steps. Someone without a referral could continue through the same application. Someone with one could enter the code in a sheet, see the referrer’s name and edit it before continuing.

Application with work details, documents and an optional referral-code action. Referral code entry sheet. Application with the accepted code, referrer name and edit action.

The optional code opens in a sheet. Once accepted, the application shows the referrer’s name and lets the applicant change the code.

What does pending mean?

One draft split referrals into Successful and Pending. The pending list showed names and phone numbers. Another explored a single page with the offer, reward rules, terms and FAQs. These gave different amounts of space to explaining the programme and following an existing referral.

The later status-card designs made pending more specific. A Flex application could be waiting on documents or a contract. Full-time applications also had interview and offer steps. Each needed its own sequence.

Profile entry, an active referral with daily reward progress, and pending referrals with onboarding steps.

A version from the second cut. Active referrals show work and earnings. Pending referrals show the application steps still ahead.

The component sets covered more than completed steps. They included verification in progress, failed verification, rejection, withdrawal and blacklisting. A timestamp showed when the status had last changed. Phone and WhatsApp actions sat beside the person, so the referrer could contact them from the same card.

A further exploration added an expiry warning and a reminder to help the friend finish onboarding. The card showed which step was holding up the application and when the referral would expire.

Flex onboarding states, including waiting, verification, failure, withdrawal, blacklisting and rejection.

The Flex onboarding state set. Waiting, verification and failure have explicit labels, alongside the completed steps.

Explaining the money

Once the friend started working, the information changed. The relevant questions were how much had been earned, what was still possible, and which conditions had not been met.

I explored horizontal checkpoints for this. Each checkpoint could be upcoming, in progress, earned or missed. The daily version showed the date and both people’s order counts beneath the amount.

In one example, the daily target is 100 orders each. The friend has completed 104, but the referrer has completed 96. The reward is marked as missed, and the 96 is highlighted to identify the unmet condition.

Daily reward card with both 100-order targets and aligned earned, missed, current and upcoming checkpoints. The missed day shows 96 orders for the referrer and 104 for the friend.

The missed day shows why. The friend’s count is 104, but the referrer’s 96 falls short of the 100-order target shown on the referral card.

The detail view gave this more room. It put possible, missed and earned rewards into a history alongside the application events. It also separated earning a reward from receiving the payment. An earned reward could show when it would be credited, while a paid reward showed its credit date.

The list could stay compact because the explanation was available inside each referral. The detail view retained the activity counts, including the unmet condition on a missed reward.

Complete referral detail view with possible earnings, a missed reward, an earned reward awaiting credit, a credited reward, and the contract, document and application events.

The complete detail view. Possible, missed, earned and credited rewards sit in the same history as the onboarding events. Both people’s activity counts remain visible.

Setting the rules

Those offer and progress screens depended on rules set by the team. The internal interface let them create and edit rate cards, give them validity dates, and assign them to cities and stores.

For Flex, the form included the activity metric, daily reward and earning duration. For full-time work, an editor allowed multiple attendance, day and amount slabs. Rows could be added or removed.

The referrer’s condition was configured separately. It could match the friend’s condition or use a different one. That is the other side of the two-count progress display in the app. The team sets a condition here, and the worker needs to understand whether they met it there.

The management table kept the rate-card status, scope and change information visible. The surrounding designs also included bulk upload and filtered reports.

Complete rate-card management dashboard with Full Time and Flex tabs, validity dates, status, city and store scope, referral amounts and referrer conditions.

The full-time rate-card dashboard. Each row shows the offer’s validity, status, scope and referral amount, alongside the referrer’s condition and change history.

Complete create-rate-card side sheet with basic details, validity dates, attendance metric, referrer conditions and city and store selection. Full-time rate-card editor with attendance, days and amount rows, plus Add slab and delete controls.

Left, the complete create-rate-card sheet. Its Edit Rate Card action opens the slab editor shown on the right, where attendance, the time allowed and the reward amount are configured together.

Additional referrer eligibility controls set to four punch-ins per week.

A separate referrer condition in the internal tool. This example requires four punch-ins per week.

The work connected the rule configured by the team to the explanation seen by the worker. Before a referral, that meant finding the applicable offer. During the application, it meant naming the unfinished step. After work began, it meant showing which conditions had been met and separating a reward earned from a payment credited.