A merchant dashboard for offers: publishing, limits and clear numbers

What a merchant offers dashboard needs to do

A merchant offers dashboard has three jobs: help the merchant publish an offer correctly, keep that offer within the limits they chose, and show what it produced. Everything else is secondary. A café owner or shop manager opens it between customers, usually on a phone, so each job has to be finishable in a few taps.

The dashboard is also where a marketplace keeps or loses its supply. Shoppers come back when there are fresh offers nearby; offers appear only when merchants find publishing easy and worthwhile. A dashboard that hides its numbers, or inflates them, may please a merchant for a week, but it does not earn the next offer.

In T-CODE, the offers app FLUIDS designed and built, the merchant tools live in the same mobile app as the shopper experience: one app for both sides. Merchants set up a store profile, publish time-limited offers or offers capped by a number of codes, confirm use with a redemption code, and follow results in a dashboard. This guide walks through each part and the decisions behind it.

Merchant onboarding: application, review and approval

A merchant should apply, be reviewed and be approved before they can publish anything. Open sign-up for merchants invites fake shops, duplicate listings and offers nobody intends to honour, and shoppers blame the app, not the merchant, when an offer turns out to be false.

T-CODE separates the merchant application from running a store. Its merchant model distinguishes a pending application, a rejected application, an approval before a shop has been created, and an owner with a shop ready to manage. Each state leads to a different next step; a workable design for each looks like this:

The application form should collect what the reviewer actually checks: the business name, a contact person, the category, the city and branch locations, and business registration details, such as the commercial registration number for a business in Saudi Arabia. The platform side needs a simple review queue for whoever approves merchants, with the ability to record why an application was rejected.

Publishing an offer: the fields that matter

A good publishing flow asks only for what the shopper needs to decide and what the system needs to enforce. In T-CODE, a merchant creates an offer, sets the price, duration and branch, and chooses between a time-limited offer and one capped by a number of codes, then tracks each offer's status.

A practical order for the form is:

1. What the offer is: a short title, an image and a plain description of what the shopper gets.
2. Terms: the price or discount, and any conditions such as minimum purchase or excluded items.
3. Where: the branch or branches that will honour it. Only visible branches should be selectable.
4. Limit: an end date, a number of codes, or both.
5. Preview: the offer as a shopper will see it, before it goes live.

Two details save support time later. First, keep the merchant's list of offers filterable by branch and status, so a merchant with several offers can find the one to edit. Second, show at publish time how the offer will appear on the shopper's map and list; mistakes in offer titles are easier to spot in a preview than in a form.

Editing a live offer without breaking promises

Once shoppers have reserved codes, an offer is a promise, and the dashboard should protect it. The simplest rule is that a reservation keeps the terms that were shown when it was made. Store a snapshot of the title, discount and conditions with each reservation, so a later edit does not change what an existing code entitles someone to.

Some edits are safe and some are not:

• Safe: fixing a typo, replacing an image, extending the end date, adding a branch, raising the code cap.
• Restricted: lowering the cap below the number of codes already issued, which the server should refuse.
• Needs a rule: ending an offer early or removing a branch while reservations are open. Decide whether those reservations are honoured until expiry or cancelled with a notice to the shopper.

Caps deserve special care. In T-CODE the cap is enforced rather than advisory, and edits should respect the same principle: a cap that a merchant can quietly undercut after codes are issued is not a cap. Our guide to coupon redemption codes explains how caps and expiry are enforced on the server.

Which numbers a merchant dashboard should show

A merchant dashboard should show a small set of numbers, each with one precise definition. T-CODE's dashboard brings together branches, offers, views, followers, used codes and conversion rate in one view, so an offer's performance is not a guess. Whatever you include, define it:

Let merchants filter by offer, by branch and by period. A merchant with two branches needs to know which one is responding to an offer, and a single number for the whole store hides that. Activity over time, for example the last week, month or quarter, helps the merchant connect a spike to the offer that caused it.

Be careful with what the dashboard implies. Used codes show that offers were taken up at the counter; they do not show profit, new customers or sales that would not have happened anyway. Label the numbers plainly and let the merchant draw conclusions.

Building the dashboard: in the app, on the web, or both

The first architecture decision is where the merchant works. T-CODE puts shoppers and merchants in one mobile app, which suits small merchants who manage everything from a phone and confirm codes at the counter. Larger merchants, with marketing staff and many branches, often want a web dashboard for publishing and reporting, while counter staff keep using the phone.

• One app for both sides: a single codebase and store listing, and merchants already have the tool in their pocket. The app must switch cleanly between shopper and merchant roles.
• Separate merchant web dashboard: better for long forms, bulk edits and wide tables, but it is a second product to design, test and maintain.
• Platform admin panel: needed either way, for reviewing merchant applications, handling reports and correcting data.

Whichever you choose, permissions decide what each person can do in the dashboard: an owner publishes and sees all branches, while a staff member may only confirm codes at one branch. That model is covered in multi-branch merchant roles and permissions. The same reporting principles apply to service businesses, as in our guide to a salon owner dashboard.

FLUIDS designs and builds two-sided products like this as marketplace platforms and custom software, including work for e-commerce and retail. The T-CODE case study shows the merchant tools in context. Scope, price and timeline are agreed in a written proposal before development.