An ecommerce coupon brief defines who can receive a discount, which items qualify and how the final amount is checked. For a Kenyan online shop, adding a coupon field is only the visible part of that work. The business also needs rules for mixed baskets, changed quantities, repeated attempts and promotions that end while someone is shopping.
Prepare those rules before commissioning ecommerce website development in Kenya. A developer can then estimate the actual discount workflow and its tests, rather than treating every promotion as the same percentage field.
The examples here are illustrative requirements, not offers from Mocky or recommended discount levels. Choose your own commercial terms after reviewing product margins, fulfilment obligations and the capabilities of the chosen store platform.
Define the commercial purpose of one promotion
Start with a single promotion and its intended audience. It might apply to an eligible product range, a customer group or a defined purchase occasion. Write the purpose in a sentence so staff can explain why the offer exists and recognise requests that fall outside it.
Record the owner who approves the terms and the person who can activate or stop the code. These may be different roles. A designer preparing a campaign image should receive approved wording rather than become responsible for deciding how the store calculates the discount.
Prepare a promotion record containing the code, customer-facing description, discount method, qualifying items, time window and exclusions. Add the approval status and a reference to the acceptance tests. Keep unpublished commercial decisions separate from wording that customers will see.
Distinguish a basket discount from an item discount
Write down what receives the reduction. A fixed amount taken off the whole basket behaves differently from the same amount taken off each qualifying item. A percentage also needs an eligible base: the entire basket and a selected product subset are different instructions.
WooCommerce's coupon documentation distinguishes fixed-cart, fixed-product and percentage coupons, with usage restrictions and limits. Treat that as a platform example. Ask the developer to map your approved promotion to the capabilities and configuration of your actual store rather than assuming every platform uses identical settings.
Use an illustrative mixed basket to review the calculation. Include one qualifying item, one excluded item and more than one unit of a qualifying product. Ask for a written expected result so the business can verify the implementation without interpreting code or relying on a campaign graphic.
State eligibility in terms staff can maintain
List qualifying products or categories clearly and explain who maintains that list. If category membership controls the offer, adding an item to that category could change its eligibility. The merchandising team needs to know that relationship before reorganising the catalogue during a live promotion.
Decide whether selected variations differ. A product with several sizes or finishes may have different commercial constraints, but that distinction must be supported by an explicit rule and tested on the chosen platform. Do not assume the product title alone contains enough information to identify the eligible item.
For customer-specific offers, ask what evidence establishes eligibility. A typed email address and an authenticated account are different inputs. Define the business requirement first, then have the developer explain its enforcement and limitations. Avoid advertising a stronger restriction than the system actually verifies.
Define thresholds and interactions with other offers
If the promotion has a minimum purchase amount, specify which items contribute to it and whether the threshold is evaluated before or after other reductions. Ask separately how shipping and tax enter the calculation. Agree the intended result with the people responsible for commercial and accounting decisions.
Decide whether customers can combine codes, use a code on a sale item or apply another benefit alongside it. Describe the order of calculation where more than one benefit is allowed. A phrase such as “cannot be combined” needs a corresponding store rule, clear customer wording and a test.
Use boundary examples. Review a basket just below the threshold, exactly at it and just above it. Then remove a qualifying item after applying the code. The checkout should recalculate according to the approved rules instead of carrying forward a discount that no longer matches the basket.
Agree time windows and usage handling
Record the promotion's start and end in an explicit time zone, such as Africa/Nairobi for the Kenyan operation. Ask how the platform interprets an expiry date and verify the actual boundary. Campaign copy and system configuration should describe the same period rather than leaving the final day ambiguous.
If usage is limited, define what consumes a use. An attempted checkout, an unpaid order and a verified paid order are different events. Ask how the chosen system handles abandoned payment, cancelled orders and simultaneous checkouts when only a small number of uses remain.
Document whether a cancelled purchase restores eligibility. The answer may depend on the promotion and the platform, so settle it before support staff make promises. Keep this decision alongside the store refund workflow so a later refund does not lead to an improvised coupon policy.
Keep the server responsible for the payable amount
Make server validation an explicit requirement. The browser can display an estimate, but it should not decide the authoritative price, discount or final amount to collect. Ask the developer how the server rechecks current eligibility and records the calculation used for the order.
Specify what happens if the basket changes, a code expires or a product price changes before payment begins. The customer should see the updated amount and any necessary explanation before continuing. A stale screen must not silently become the basis for collecting the wrong amount.
Payment preparation should use the verified order total. Payment confirmation must follow the provider verification and order-state rules for the implementation. Applying a coupon is not payment evidence, and a customer returning from a payment screen is not enough to mark an order paid.
Write helpful messages and support instructions
Prepare wording for an invalid code, an expired promotion, an ineligible basket and an exhausted usage limit. Explain the next step without exposing private customer eligibility information. Where possible, tell a shopper which visible condition they can correct instead of presenting an unexplained failure.
Check the order summary and the records used by staff. The discount should be understandable alongside item quantities, delivery charges and the payable total. Agree what information appears on documents through the appropriate accounting review rather than inventing invoice treatment in a design brief.
Give support staff a reference for checking the code's current rules and the order's recorded calculation. A manual goodwill adjustment is a separate authorised action. Staff should not be expected to alter totals informally because a customer supplies a screenshot of an older promotion.
Test the complete promotion before sharing the code
Use a review environment and payment-provider testing arrangements. Cover qualifying and excluded items, mixed baskets, changed quantities, thresholds, expiry boundaries and combined promotions. Include a rejected code and a customer who cannot satisfy the stated eligibility requirement.
Ask the developer to test repeated and concurrent attempts where usage limits matter. Review the saved order calculation as well as the screen. A successful visual preview does not establish that the server will reject an invalid discount or preserve the correct amount when payment is initiated.
Coordinate these tests with the ecommerce staff permissions brief. Confirm who can create, change and stop promotions, and how staff identify the currently approved terms. Restricting access is useful only when the responsible person can still manage an urgent correction through a known process.
Frequently asked questions
Can a coupon apply to only part of a basket?
That can be a requirement, subject to the chosen platform and configuration. Supply mixed-basket examples and ask the developer to demonstrate the approved calculation before launch.
Does an expiry date mean the last day is included?
Do not assume it. Record the intended end time and time zone, check the platform's interpretation and test the boundary against the customer wording.
Should a cancelled order return a coupon use?
Decide this as a business rule and confirm the implementation supports it. Keep the rule visible to support staff so different customers do not receive contradictory answers.
What should accompany a development enquiry?
Send the promotion record, example baskets, eligibility decisions and unresolved exceptions. Request an ecommerce quotation that includes server checks, payment-total handling, staff access and acceptance evidence, not just the coupon entry box.
