Ecommerce delivery zones in Kenya should turn your actual fulfilment arrangements into checkout choices that a customer can understand. Start with the destinations you can reliably serve, the information your courier needs and the rules you use to charge for each order. Do not begin by adding a long county list and assuming every address within it has the same service.
This guide helps Kenyan online stores prepare delivery requirements for a developer. It covers checkout behaviour and operational testing rather than comparing courier companies. If delivery rules are part of a new build, discuss them with Mocky's ecommerce development team before the checkout is implemented.
Map the service you actually offer
Write down where you can deliver and what delivery means for each area. Door delivery, collection from a named pickup point and arranging a separate quote are different services. A customer should not discover after payment that an advertised destination requires an unexpected collection journey.
For each service area, confirm the operating arrangement with the fulfilment provider. Record any exclusions and the information needed to resolve an address. A marketing phrase such as “nationwide delivery” should not replace the specific rules the checkout and support team need to handle an order consistently.
Use the map as a business specification rather than asking a developer to invent one. The person responsible for dispatch should review it alongside sales or customer support. This helps identify situations where the website promises an option that the team cannot actually fulfil under the stated conditions.
Distinguish delivery areas from shipping charges
A zone describes a service area or grouping; a rate determines what the customer pays under defined conditions. Your platform may use different terminology or geographical controls. Ask the developer to show how the proposed system represents the areas your business needs, including any limitations.
Shopify's shipping guidance describes rates based on options such as fixed charges, order value or weight. That is one platform's model, not a guarantee that every local store has the same controls. Specify your intended behaviour first and ask how it will be implemented on the platform being proposed.
Keep the calculation and the customer-facing explanation aligned. If a particular destination needs manual quotation, show that clearly before the customer commits to a final total. Do not use an unexplained zero charge as a substitute for a rate that has not yet been agreed.
Decide how customers identify their destination
Ask what address details the fulfilment team genuinely needs. A town name alone may be insufficient for door delivery, while a pickup service may need the selected branch. Use labels that match the way your customers and dispatch staff describe the destination.
Avoid forcing customers into an inaccurate choice just to continue. If the form asks for a county but your charges are defined by a smaller service area, the checkout needs a way to distinguish those cases. Explain that requirement to the developer rather than assuming a standard address template will resolve it.
Check the mobile experience carefully. Long dropdowns, ambiguous area names and missing instructions can make customers select the nearest familiar option instead of the correct one. Give the business a clear process for handling destinations that are not listed. A visible enquiry route is better than silently assigning an unsuitable delivery service.
Write the rules for mixed and unusual baskets
A delivery rule that works for one lightweight item may behave differently when a customer adds several products. Decide how the system should handle quantity, weight, size and products that need special handling. Record which product details must be maintained for the calculation to remain accurate.
Consider baskets containing items supplied from different locations or requiring separate dispatch. Ask whether the proposed checkout combines delivery charges, shows multiple shipments or blocks an unsupported combination. The customer-facing behaviour should reflect your actual operation rather than expose an unexplained total.
For an illustrative case, a store might sell both compact accessories and bulky display items. That does not establish a particular price or courier arrangement. It simply shows why the requirements should include more than a single-item test. Choose examples from your own catalogue and agree the expected result before development is accepted.
Define free-delivery and collection conditions precisely
If you offer free delivery above a threshold, define which areas qualify and how the eligible basket value is calculated. Clarify what happens after a discount changes the basket total. The developer should not have to guess whether the threshold applies before or after discounts, or whether excluded products count toward it.
Show the conditions in customer language. A promotional message promising free delivery should lead to the same result as the checkout under the stated rules. If only selected areas qualify, make that limitation visible where the promotion is presented, rather than relying on staff to explain it after an order.
Treat collection as its own option. Identify the location, what happens after ordering and when the customer should expect a readiness message. Do not display collection merely as “free shipping” if the customer must travel to a particular place. A clear service name helps prevent the wrong fulfilment expectation.
Test unsupported addresses and boundary cases
Create a test sheet with destinations inside and outside each intended service area. Include an address near a boundary or an area name that might be confused with another. Write the expected service and charge beside each example before asking the developer to demonstrate it.
Shopify documents that customers outside configured shipping regions may receive a no-rate message. Whatever platform you use, decide what your own customer should see when a destination is unsupported. It should not quietly fall through to an unrelated cheap rate or an unapproved free-delivery option.
Test the order-value boundaries too. For a threshold, check just below it, exactly at it and just above it, including the intended discount behaviour. Use the same approach for weight boundaries if relevant. These checks often reveal gaps that an ordinary sample basket does not expose.
Protect totals and use a controlled test environment
A customer's browser should not be the final authority for a delivery amount. Ask the developer to explain how the chosen address, basket and applicable rules are validated when an order is submitted. The total saved with the order should match the verified checkout calculation.
Conduct acceptance tests in a suitable test environment using sandbox payments or approved mocks. Do not create misleading live sales, send advertising conversion events or dispatch courier requests as an accidental side effect of testing. Agree what is blocked and which internal records will be used before the demonstration begins.
For a system with manual quotation, test that path separately. Check what status the request receives, who reviews it and how the final amount is communicated. A request awaiting a delivery quote should not be presented to the customer as an already confirmed, fully priced dispatch.
Keep a delivery policy owner after launch
Assign responsibility for updating zones, rates and customer explanations. Courier arrangements can change, and the website needs a controlled way to reflect those changes. Ask which settings staff can maintain and which require developer work.
Keep a small change record and rerun the relevant test cases after an update. If a zone is removed, check the unsupported-address message. If a threshold changes, test its new boundary. Avoid assuming that a successful launch test proves the rules will stay correct through every later promotion.
For a broader project discussion, read our ecommerce planning guide. Delivery is one part of that build, but it deserves its own written specification because it directly affects what customers expect and what the fulfilment team must deliver.
Frequently asked questions
Should every county have one flat delivery fee?
Only if that matches the service your business can actually provide. Define the real areas, service types and exceptions first. Then ask the developer how the chosen platform can represent those rules without forcing customers into misleading selections.
What should happen when no rate matches?
Agree a clear unsupported-destination or quotation path. The checkout should explain the next step rather than invent a delivery amount. Check that the request status and customer message accurately reflect whether the order has a confirmed final total.
Do free-delivery promotions need separate testing?
Yes. Check eligible destinations, excluded products and the effect of discounts on the threshold. Use a test sheet with the expected result so the business and developer are approving the same behaviour.
What should I send Mocky before requesting a build?
Send your service areas, fulfilment arrangements, example products, charge rules and exceptions to the ecommerce team. Include a few representative baskets and destinations. That gives the team a concrete basis for scoping and checking the delivery workflow.
