An ecommerce preorder brief explains how an online shop accepts interest or orders for goods that are not yet available for normal fulfilment. For a Kenyan business, the important decisions include what the customer is committing to, when payment happens and who communicates a change in availability. A preorder button alone does not settle any of those questions.
Prepare the workflow with your ecommerce website developer before advertising the offer. Keep supplier expectations, customer-facing dates and payment states distinct. The site should describe the commitment your team can actually support.
The examples here are illustrative planning choices, not product offers, payment advice or a legal cancellation policy. Confirm commercial terms with the responsible business owner and review any applicable requirements separately before launch.
Define what the customer is requesting
Decide whether the feature records a non-binding expression of interest, reserves an allocation or creates an order. These states can look similar in a mockup but have different operational consequences. Choose labels that explain the selected model consistently across the product page and confirmation.
Write a short description of what the customer receives at each stage. If staff must confirm availability before accepting the order, the initial screen should not imply that a unit is already reserved. If the business does reserve goods, define what record establishes that allocation.
Separate preorders from ordinary out-of-stock listings. A product can be unavailable without the shop accepting future orders. Ask who may enable the preorder mode and what information must be approved before that change becomes visible to shoppers.
Establish a credible availability record
Record the product, source of availability information, expected milestone and person responsible for updates. A supplier's estimated arrival and the shop's ready-to-dispatch date are not necessarily identical. Allow for the real receiving and preparation work in the business plan without inventing a universal lead time.
Choose wording that matches the certainty of the information. If a date is an estimate, describe it as such. Do not turn an informal supplier message into an unconditional delivery guarantee because the product template requires a date field.
Set a review trigger when the source changes. A revised shipment expectation should reach the people managing customer communication and public product information. Avoid relying on one employee to remember every page, message and pending order affected by a delay.
Agree payment timing before choosing the extension
Describe whether payment is collected at the initial order, after availability is confirmed or through another explicitly agreed process. Ask the developer to demonstrate what the selected payment provider and platform support. An ordinary checkout integration does not automatically support charging a customer later without further action.
WooCommerce's Pre-Orders documentation describes its extension's upfront and release-time charging options. Those options have implementation and gateway dependencies. Treat the documentation as a starting point for checking compatibility, rather than a promise that the same behaviour is available with every Kenyan payment integration.
Keep a verified payment separate from an order request. If the customer must complete a later payment step, explain how they receive the approved instructions and how the order reflects the outstanding action. Do not label an unpaid allocation as paid simply because it appears in the preorder list.
Decide how allocations and quantities are controlled
Agree whether there is a limit to the number of units the business will accept. Identify the source of that limit and the person who can change it. A future supplier quantity should not be treated as unlimited stock merely because nothing has arrived in the warehouse yet.
Consider variations individually. A product might have several colours or sizes with different expected quantities. The allocation should follow the item the customer actually selects, rather than reserve a generic unit while staff later discover that the requested variation is unavailable.
Define what happens to cancelled or expired allocations. Staff need to know whether the unit returns to an available pool and whether another customer is contacted. Record the intended behaviour before assuming that changing an order status also updates every related stock record.
Plan baskets containing different fulfilment dates
Ask whether customers can combine preorder goods and currently available products in one basket. If allowed, decide whether the shop holds the whole order or offers separate fulfilment arrangements. Communicate that choice before the customer commits.
Check delivery charges against the selected model. Do not let a split shipment create an unexplained later charge or an unsupported promise that the original checkout amount covers every future dispatch. The business owner should approve the rules, and the developer should show the resulting totals in a safe test flow.
Keep pickup options consistent too. A collection confirmation should follow actual readiness, not simply the arrival of an estimated release date. The click and collect planning guide covers the separate preparation and physical handover decisions.
Write communication for changes and exceptions
Prepare messages for the initial request, verified payment where applicable, revised estimate, availability confirmation and cancellation outcome. Use the same definitions as the product page. The customer should not receive a confirmation that describes a stronger commitment than the one they were shown at checkout.
Choose the event that triggers each message and its owner. A supplier date changing does not necessarily mean every affected customer has been informed. Decide how staff identify the relevant orders and record the communication work without sending repeated or contradictory notices.
Use the order notification brief to map triggers, recipients and failed-message handling. Keep financial confirmation tied to the authoritative payment record. A message sent successfully proves dispatch of the message, not completion of the customer's payment or receipt of the goods.
Describe cancellation and refund responsibilities
Have the business owner approve the customer-facing terms for the actual offer. Keep them accessible at the relevant decision point. This guide does not prescribe a universal cancellation deadline or claim that a particular policy satisfies every requirement.
Identify who can approve an exception and how staff locate the original order and payment. If a refund is authorised, it should follow the agreed verified process. Do not assume that deleting a preorder automatically reverses a transaction or tells the customer what happened.
Plan partial changes. A customer may ask to cancel one variation while retaining another. The order, allocation and financial records need to remain understandable. The refund workflow guide addresses the operational checks separately from setting the commercial terms.
Test the whole lifecycle with safe records
Use a staging store and the payment provider's supported testing arrangements. Prepare cases for an available allocation, the final permitted unit, an unavailable variation, a mixed basket and an interrupted payment step. Do not create fake production orders to demonstrate the feature.
Walk through a revised availability date and an approved cancellation. Check what changes on the product page, what remains in the order record and which messages should or should not be sent. Include a repeated notification or provider event where the implementation team identifies that as relevant.
Ask staff to locate an affected order without relying on the person who built the system. They should be able to identify the customer-facing commitment, allocation state, verified payment state and next operational action. If those answers require guessing from a single generic status, refine the workflow.
Prepare an operational launch checklist
Before enabling the feature, confirm the products, approved wording, allocation limits, payment compatibility and communication owner. Record which test scenarios passed and any known limitations. Keep uncertain products out of the initial launch rather than filling their missing details with assumptions.
Include staff training and maintenance in the scope. Someone must update estimates, review pending actions and handle exceptions after the developer hands over access. A working launch demonstration is not a replacement for that ongoing ownership.
For a proposal, send one representative product and its intended lifecycle. Request an ecommerce quotation covering product display, payment states, allocation, messages and acceptance. That gives the development team enough context to discuss the implementation before choosing a plugin or estimating custom work.
Frequently asked questions
Is a preorder the same as a waiting list?
Not necessarily. Define whether the customer is expressing interest, reserving goods or placing an order, then reflect that choice in the interface and operations.
Can every gateway collect payment automatically later?
Do not assume so. Have the developer verify the chosen provider, extension and charging model before promising that behaviour.
Should a release date trigger dispatch automatically?
Only if the actual workflow and implementation justify it. An estimated date does not prove that goods are received, checked and ready to leave.
Can we launch with a small product range?
Yes. A reviewed range with clear ownership is a practical starting point. Expand after the business has demonstrated that it can manage the full lifecycle accurately.
