{"id":656,"date":"2026-08-20T19:15:04","date_gmt":"2026-08-20T19:15:04","guid":{"rendered":"https:\/\/zamacore.com\/blog\/?p=656"},"modified":"2026-08-20T19:15:04","modified_gmt":"2026-08-20T19:15:04","slug":"delivery-exception-management-software-kenya","status":"publish","type":"post","link":"https:\/\/zamacore.com\/blog\/delivery-exception-management-software-kenya\/","title":{"rendered":"Delivery Exception Management Software Kenya: Resolve Failed Deliveries, Damages and Returns Faster"},"content":{"rendered":"<p><!-- zama-client-demand-20:2026-08-20 site=zamacore slug=delivery-exception-management-software-kenya --><\/p>\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_85 counter-hierarchy ez-toc-counter ez-toc-grey ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<p class=\"ez-toc-title\" style=\"cursor:inherit\">Table of Contents<\/p>\n<span class=\"ez-toc-title-toggle\"><a href=\"#\" class=\"ez-toc-pull-right ez-toc-btn ez-toc-btn-xs ez-toc-btn-default ez-toc-toggle\" aria-label=\"Toggle Table of Content\"><span class=\"ez-toc-js-icon-con\"><span class=\"\"><span class=\"eztoc-hide\" style=\"display:none;\">Toggle<\/span><span class=\"ez-toc-icon-toggle-span\"><svg style=\"fill: #999;color:#999\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" class=\"list-377408\" width=\"20px\" height=\"20px\" viewBox=\"0 0 24 24\" fill=\"none\"><path d=\"M6 6H4v2h2V6zm14 0H8v2h12V6zM4 11h2v2H4v-2zm16 0H8v2h12v-2zM4 16h2v2H4v-2zm16 0H8v2h12v-2z\" fill=\"currentColor\"><\/path><\/svg><svg style=\"fill: #999;color:#999\" class=\"arrow-unsorted-368013\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" width=\"10px\" height=\"10px\" viewBox=\"0 0 24 24\" version=\"1.2\" baseProfile=\"tiny\"><path d=\"M18.2 9.3l-6.2-6.3-6.2 6.3c-.2.2-.3.4-.3.7s.1.5.3.7c.2.2.4.3.7.3h11c.3 0 .5-.1.7-.3.2-.2.3-.5.3-.7s-.1-.5-.3-.7zM5.8 14.7l6.2 6.3 6.2-6.3c.2-.2.3-.5.3-.7s-.1-.5-.3-.7c-.2-.2-.4-.3-.7-.3h-11c-.3 0-.5.1-.7.3-.2.2-.3.5-.3.7s.1.5.3.7z\"\/><\/svg><\/span><\/span><\/span><\/a><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/zamacore.com\/blog\/delivery-exception-management-software-kenya\/#Give_every_failed_or_disputed_delivery_a_visible_next_action\" >Give every failed or disputed delivery a visible next action<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/zamacore.com\/blog\/delivery-exception-management-software-kenya\/#What_the_workflow_should_achieve\" >What the workflow should achieve<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/zamacore.com\/blog\/delivery-exception-management-software-kenya\/#A_realistic_Kenyan_operating_scenario\" >A realistic Kenyan operating scenario<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/zamacore.com\/blog\/delivery-exception-management-software-kenya\/#The_records_and_definitions_to_agree_first\" >The records and definitions to agree first<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/zamacore.com\/blog\/delivery-exception-management-software-kenya\/#A_practical_end-to-end_process\" >A practical end-to-end process<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/zamacore.com\/blog\/delivery-exception-management-software-kenya\/#Exceptions_the_demonstration_must_include\" >Exceptions the demonstration must include<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/zamacore.com\/blog\/delivery-exception-management-software-kenya\/#Roles_permissions_and_segregation_of_duties\" >Roles, permissions and segregation of duties<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/zamacore.com\/blog\/delivery-exception-management-software-kenya\/#Capabilities_worth_putting_in_the_scope\" >Capabilities worth putting in the scope<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/zamacore.com\/blog\/delivery-exception-management-software-kenya\/#Integrations_identifiers_and_failure_handling\" >Integrations, identifiers and failure handling<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-10\" href=\"https:\/\/zamacore.com\/blog\/delivery-exception-management-software-kenya\/#Operational_views_and_management_reporting\" >Operational views and management reporting<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-11\" href=\"https:\/\/zamacore.com\/blog\/delivery-exception-management-software-kenya\/#Security_privacy_and_audit_evidence\" >Security, privacy and audit evidence<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-12\" href=\"https:\/\/zamacore.com\/blog\/delivery-exception-management-software-kenya\/#How_to_run_a_controlled_pilot\" >How to run a controlled pilot<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-13\" href=\"https:\/\/zamacore.com\/blog\/delivery-exception-management-software-kenya\/#Measures_that_can_show_whether_the_process_is_improving\" >Measures that can show whether the process is improving<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-14\" href=\"https:\/\/zamacore.com\/blog\/delivery-exception-management-software-kenya\/#Common_implementation_mistakes\" >Common implementation mistakes<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-15\" href=\"https:\/\/zamacore.com\/blog\/delivery-exception-management-software-kenya\/#Questions_to_use_in_a_serious_software_demo\" >Questions to use in a serious software demo<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-16\" href=\"https:\/\/zamacore.com\/blog\/delivery-exception-management-software-kenya\/#Related_ZamaCore_resources\" >Related ZamaCore resources<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-17\" href=\"https:\/\/zamacore.com\/blog\/delivery-exception-management-software-kenya\/#Frequently_asked_questions\" >Frequently asked questions<\/a><ul class='ez-toc-list-level-3' ><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-18\" href=\"https:\/\/zamacore.com\/blog\/delivery-exception-management-software-kenya\/#What_is_a_delivery_exception\" >What is a delivery exception?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-19\" href=\"https:\/\/zamacore.com\/blog\/delivery-exception-management-software-kenya\/#Does_exception_management_require_GPS_tracking\" >Does exception management require GPS tracking?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-20\" href=\"https:\/\/zamacore.com\/blog\/delivery-exception-management-software-kenya\/#How_should_partial_delivery_be_recorded\" >How should partial delivery be recorded?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-21\" href=\"https:\/\/zamacore.com\/blog\/delivery-exception-management-software-kenya\/#When_can_returned_goods_become_available_stock\" >When can returned goods become available stock?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-22\" href=\"https:\/\/zamacore.com\/blog\/delivery-exception-management-software-kenya\/#What_should_a_delivery-exception_pilot_test\" >What should a delivery-exception pilot test?<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-23\" href=\"https:\/\/zamacore.com\/blog\/delivery-exception-management-software-kenya\/#Discuss_this_workflow_with_ZamaCore\" >Discuss this workflow with ZamaCore<\/a><\/li><\/ul><\/nav><\/div>\n<h2><span class=\"ez-toc-section\" id=\"Give_every_failed_or_disputed_delivery_a_visible_next_action\"><\/span>Give every failed or disputed delivery a visible next action<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<figure class=\"wp-block-image size-large\"><img decoding=\"async\" src=\"https:\/\/zamacore.com\/blog\/wp-content\/uploads\/2026\/08\/delivery-exception-management-software-kenya-featured-2026-08-20.jpg\" alt=\"Delivery exception management software Kenya team inspecting damaged returned goods\"><figcaption>Dispatch, driver and warehouse staff inspect a damaged return and prepare the controlled next step.<\/figcaption><\/figure>\n<p><strong>delivery exception management software Kenya<\/strong> is useful when a business needs to control a specific operational decision, not when it merely wants another screen. A driver reports that a customer was unavailable, goods were damaged, the address was unclear or only part of an order was accepted. The update arrives through a call or messaging app, while dispatch, customer service, sales and the warehouse each keep a different version of the next step.<\/p>\n<p>The order can remain marked out for delivery, stock may be unavailable for resale, a customer may wait without a confirmed plan and finance may not know whether to invoice, credit or hold. The critical requirement is not a map; it is a controlled exception record connecting evidence, ownership, inventory and communication. This guide is written for logistics managers, dispatchers, customer-service teams, warehouse supervisors, finance staff and operations directors. It explains what to record, which exceptions must stay visible, how to structure a pilot and what a serious buyer should ask to see in a demonstration.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"What_the_workflow_should_achieve\"><\/span>What the workflow should achieve<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>The workflow should register the exception against the correct order and delivery attempt, classify the observed condition, preserve evidence, assign immediate and follow-up actions, and record final resolution. It should connect returns, replacement, redelivery, partial acceptance or cancellation without erasing the original attempt.<\/p>\n<p>This use case starts when planned fulfilment deviates from the agreed delivery outcome and ends when the exception has a supported resolution across relevant operational records. It complements dispatch and proof-of-delivery systems but does not assume GPS, route optimisation or a specific transport model. That boundary matters because a narrow, complete workflow is easier to test than a broad promise. It also prevents this use case from competing with a general ERP, inventory, procurement or analytics page that owns a wider buying intent.<\/p>\n<p>A useful design begins with the source transaction and ends with an authorised, traceable outcome. It should preserve the normal path and the difficult path: missing information, partial work, a rejected item, a late response, a correction and an approved override. If staff must leave the system and solve every exception through calls or private messages, management still lacks dependable operational evidence.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"A_realistic_Kenyan_operating_scenario\"><\/span>A realistic Kenyan operating scenario<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>A van reaches a retailer with ten cartons. The customer accepts seven, rejects two because of visible damage and disputes one item variant. The driver returns three cartons to the depot. Customer service promises a replacement before warehouse staff confirm stock, and the original delivery remains shown as complete.<\/p>\n<p>The demonstration should record the partial acceptance, damage, item dispute, customer evidence, returned quantities and next action. It should show depot return receipt, inspection, inventory status, authorised replacement or credit path, customer update and final order position while retaining the first delivery attempt.<\/p>\n<p>During discovery, bring actual forms, spreadsheets, transaction samples and reports with sensitive details removed. Name the people who create, check, approve, correct and use the record. This gives the implementation team enough context to distinguish required controls from habits that can be simplified.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"The_records_and_definitions_to_agree_first\"><\/span>The records and definitions to agree first<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Exception handling depends on stable customer, order, delivery, item, quantity, unit and destination records. The organisation also needs a manageable reason and resolution hierarchy, evidence rules, communication owner and authority for redelivery, replacement, return acceptance, credit or cancellation.<\/p>\n<ul>\n<li>Delivery attempt: one identifiable fulfilment visit or hand-off against an authorised order or consignment.<\/li>\n<li>Exception: a documented deviation from the expected delivery outcome requiring review or action.<\/li>\n<li>Accepted quantity: the amount the authorised recipient accepted under the organisation\u2019s evidence rule.<\/li>\n<li>Returned quantity: goods physically returned into a controlled depot or warehouse process and status.<\/li>\n<li>Resolution: the approved final treatment, such as redelivery, replacement, return, credit path, cancellation or other outcome.<\/li>\n<li>Customer communication: a traceable approved update about status or next action, not a substitute for the operational record.<\/li>\n<\/ul>\n<p>Agree these definitions in plain language and nominate a data owner for each one. The same term can mean different things to stores, finance, production, quality and sales. A system cannot produce trusted reports when departments use different units, dates, statuses or reasons for the same event. Controlled lists should therefore be reviewed deliberately rather than expanded whenever a user wants a new label.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"A_practical_end-to-end_process\"><\/span>A practical end-to-end process<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<ol>\n<li><strong>Identify the delivery attempt.<\/strong> Connect the report to order, consignment, customer, destination, planned quantity and responsible route or driver.<\/li>\n<li><strong>Record observed exception.<\/strong> Capture time, reason, affected items and quantities, immediate evidence and reporter without requiring a final resolution on the road.<\/li>\n<li><strong>Take immediate controlled action.<\/strong> Protect goods, inform the right owner, record partial acceptance and prevent an unsupported completed-delivery status.<\/li>\n<li><strong>Coordinate the resolution.<\/strong> Assign customer contact, stock check, return inspection, commercial approval, replacement or redelivery work with deadlines.<\/li>\n<li><strong>Receive and disposition returns.<\/strong> Confirm physical depot receipt, condition and inventory status before goods become available, held or otherwise processed.<\/li>\n<li><strong>Close across connected records.<\/strong> Confirm customer outcome, order and delivery status, inventory movement, finance hand-off and preserved exception history.<\/li>\n<\/ol>\n<p>Each stage should have an entry condition, responsible role, permitted action and visible completion rule. Notifications can help, but a message is not the workflow. The authoritative record must remain searchable inside the system, including what changed, who decided, why an exception was accepted and which downstream record was updated.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Exceptions_the_demonstration_must_include\"><\/span>Exceptions the demonstration must include<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>The happy path is usually the easiest part of a software demonstration. Operational value appears when the team can see, own and resolve deviations without corrupting the original record. Ask the vendor to demonstrate these representative cases:<\/p>\n<ol>\n<li><strong>Customer unavailable.<\/strong> Record the attempt and approved evidence, confirm contact or appointment next step and avoid an automatic redelivery promise without capacity.<\/li>\n<li><strong>Partial acceptance.<\/strong> Separate accepted, rejected and returned quantities by item so order, inventory and finance can follow the supported position.<\/li>\n<li><strong>Damage discovered.<\/strong> Capture condition and custody context, protect the goods, assign inspection and prevent premature resale or blame.<\/li>\n<li><strong>Wrong item or destination detail.<\/strong> Preserve what was planned and presented, route correction authority and avoid editing the original order invisibly.<\/li>\n<li><strong>Returned goods do not reach the depot.<\/strong> Keep the custody and return task open, identify the responsible hand-off and escalate according to policy.<\/li>\n<\/ol>\n<p>An exception should not be deleted merely because it is uncomfortable. It needs a reason, evidence where appropriate, an owner, a next action and a final disposition. Over time, exception patterns help process owners improve supplier instructions, training, maintenance, product design or approval rules without relying on anecdotes.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Roles_permissions_and_segregation_of_duties\"><\/span>Roles, permissions and segregation of duties<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Drivers need a practical way to report observed conditions, dispatch needs current ownership, customer service needs approved information, the warehouse controls returned stock and commercial or finance roles authorise selected outcomes. The system should not let one user promise, move and financially resolve everything without review.<\/p>\n<ul>\n<li>Driver or field reporter: records the attempt, observed exception, quantities and immediate evidence.<\/li>\n<li>Dispatcher: triages the case, protects schedule integrity and assigns operational follow-up.<\/li>\n<li>Customer-service or sales owner: confirms customer facts and communicates an approved next step.<\/li>\n<li>Warehouse receiver: records physical returns, inspection status and related inventory movement.<\/li>\n<li>Commercial or finance approver: decides authorised replacement, credit, cancellation or charge treatment.<\/li>\n<li>Operations manager: reviews overdue, recurring and high-impact exceptions and process actions.<\/li>\n<\/ul>\n<p>A permission model should be demonstrated with real role scenarios. Ask who can create, edit, approve, reopen, cancel, export and configure a record. Shared accounts weaken accountability. Broad administrator access should be limited, reviewed and logged. Temporary delegation should record the delegating person, substitute, effective period and actions taken during that period.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Capabilities_worth_putting_in_the_scope\"><\/span>Capabilities worth putting in the scope<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>A request for proposal becomes more useful when it describes testable behaviour rather than asking whether a product has a module with a familiar name. For this workflow, consider the following capabilities and confirm which are standard, configurable or require development:<\/p>\n<ul>\n<li>Order, consignment and delivery-attempt linkage<\/li>\n<li>Reason, affected item, quantity, time and evidence capture<\/li>\n<li>Partial acceptance, rejection and return quantity separation<\/li>\n<li>Immediate action, owner, deadline and escalation<\/li>\n<li>Customer-contact and approved communication history<\/li>\n<li>Depot return receipt, condition and inventory-status workflow<\/li>\n<li>Redelivery, replacement, cancellation and selected finance hand-off<\/li>\n<li>Custody or responsibility hand-off history where required<\/li>\n<li>Reopen and correction with preserved original event<\/li>\n<li>Exception age, recurrence, resolution and unresolved-value reporting<\/li>\n<\/ul>\n<p>Not every organisation needs every capability in the first release. Classify requirements as essential for the pilot, needed for rollout, or a future improvement. This keeps the first implementation coherent while preserving a documented path for later phases.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Integrations_identifiers_and_failure_handling\"><\/span>Integrations, identifiers and failure handling<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>The workflow may connect sales orders, dispatch, electronic proof of delivery, customer service, warehouse returns, inventory and finance. Agree which system owns each status and how corrections propagate. A completed proof record should not override a known partial acceptance, and a returned quantity should not become available stock before the approved receiving decision.<\/p>\n<p>For every connection, name the source of truth, matching identifier, direction of data, update frequency, permitted fields and reconciliation owner. Ask what users see when an interface is unavailable, a record is rejected, a duplicate is detected or a message arrives out of sequence. A successful technical response is not the same as a completed business transaction.<\/p>\n<p>Data migration deserves the same care. Clean a representative sample before estimating the full effort. Preserve original references where they are needed for audit or lookup, document transformations, and reconcile control totals after loading. Historical data can be archived or migrated at different levels, but the decision should be explicit and tested.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Operational_views_and_management_reporting\"><\/span>Operational views and management reporting<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Dispatch needs active exceptions by urgency, route and owner. Customer service needs cases awaiting customer contact or confirmed promise. Warehouse teams need returns expected, received and awaiting inspection. Finance needs exceptions affecting invoicing or credit decisions. Management needs age, reason, recurrence and final resolution with drill-down.<\/p>\n<p>Every headline measure needs an agreed formula, reporting period, data owner and drill-down path. Terms such as open, late, rejected, completed, available, loss and value are not self-explanatory. An authorised manager should be able to move from a summary to the transactions behind it and see when the data was last updated.<\/p>\n<p>A dashboard should prompt action rather than decorate a meeting. Define which threshold creates an alert, who receives it, what response is expected and when an unresolved issue escalates. Keep the first dashboard small enough that each measure has an owner and a practical response.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Security_privacy_and_audit_evidence\"><\/span>Security, privacy and audit evidence<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>The workflow should collect only information required for its operational purpose and restrict it according to responsibility. Buyers should review authentication, session management, sensitive exports, approval authority, configuration changes, backup restoration, retention and incident response in proportion to the risk. If external users participate, their access must remain limited to the records and actions intended for their organisation.<\/p>\n<p>An audit history is useful when it can answer: who created the record, what changed, which value was replaced, who approved the decision, when it became effective and what happened downstream. Corrections should preserve the original event and the authorised reason instead of silently rewriting history. Export and deletion rules should be agreed before launch, not invented during an investigation.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"How_to_run_a_controlled_pilot\"><\/span>How to run a controlled pilot<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Pilot one delivery operation with enough volume to include successful deliveries and real deviations. Test customer unavailable, partial acceptance, damage, wrong item, disputed detail, physical return, replacement, redelivery, cancellation or credit hand-off, an overdue task and a reopened case.<\/p>\n<ol>\n<li><strong>Map the exception journey.<\/strong> Follow the event from field report through customer contact, return, inventory, commercial decision and closure.<\/li>\n<li><strong>Simplify reasons and resolutions.<\/strong> Separate observed condition from final outcome so reporters do not guess on the road.<\/li>\n<li><strong>Define authority and promises.<\/strong> Specify who can schedule redelivery, promise replacement, accept return or approve finance treatment.<\/li>\n<li><strong>Connect returned stock.<\/strong> Test expected return, depot receipt, condition, hold, release and related order quantities.<\/li>\n<li><strong>Train with realistic cases.<\/strong> Use de-identified partial, damaged and disputed deliveries and require complete resolution.<\/li>\n<li><strong>Review recurrence.<\/strong> Analyse several weeks of reasons, owners, age and outcomes to improve instructions and controls.<\/li>\n<\/ol>\n<p>At the pilot review, separate configuration defects, data problems, training gaps, process-policy questions and genuinely new scope. Record decisions and re-test the affected scenario. Expansion should depend on acceptance evidence and user readiness, not on a demonstration that covered only the normal path.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Measures_that_can_show_whether_the_process_is_improving\"><\/span>Measures that can show whether the process is improving<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Record a baseline before changing the process. Useful measures for this use case can include:<\/p>\n<ul>\n<li>Active delivery exceptions by reason, owner and age<\/li>\n<li>Partial, rejected and returned quantity awaiting resolution<\/li>\n<li>Expected returns not yet confirmed at the depot<\/li>\n<li>Cases waiting for customer contact or commercial authority<\/li>\n<li>Time from reported exception to confirmed next action<\/li>\n<li>Redelivery, replacement, return and cancellation outcomes<\/li>\n<li>Repeated exceptions by customer, route, item or approved cause<\/li>\n<li>Cases reopened because the recorded resolution did not complete<\/li>\n<\/ul>\n<p>These are measurement candidates, not promised results. Select only the measures the organisation can define and collect consistently. Document changes in volume, seasonality, product mix or policy that could affect the comparison. Credible operational learning is more valuable than an unsupported return-on-investment claim.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Common_implementation_mistakes\"><\/span>Common implementation mistakes<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<ul>\n<li>Marking a delivery complete when only part was accepted<\/li>\n<li>Letting field reporters choose a final commercial resolution without authority<\/li>\n<li>Promising replacement before checking stock and delivery capacity<\/li>\n<li>Returning damaged goods directly to available inventory<\/li>\n<li>Editing the original order or attempt so the exception disappears<\/li>\n<li>Collecting excessive customer information or uncontrolled images<\/li>\n<li>Assuming location tracking is required to manage every exception<\/li>\n<\/ul>\n<p>Put the relevant risks into the project register with an owner and decision date. A polished interface cannot compensate for missing process owners, unreliable master data, unavailable frontline users or acceptance tests that were never agreed.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Questions_to_use_in_a_serious_software_demo\"><\/span>Questions to use in a serious software demo<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<ul>\n<li>Can accepted, rejected and returned quantities be recorded by item?<\/li>\n<li>How does an exception prevent an unsupported completed-delivery status?<\/li>\n<li>Can the driver report an observed condition without choosing the final resolution?<\/li>\n<li>Who can promise redelivery, replacement, cancellation or credit treatment?<\/li>\n<li>How is an expected return matched to physical depot receipt and inventory status?<\/li>\n<li>Can customer updates be traced to approved operational information?<\/li>\n<li>Does reopening preserve the first attempt, evidence and earlier decision?<\/li>\n<li>Which queues expose overdue actions across dispatch, customer service and warehouse?<\/li>\n<\/ul>\n<p>Use representative but de-identified records for the demo. Ask the presenter to complete the transaction rather than describe what could be configured later. Note which behaviour is available now, which requires configuration, which requires integration and which is outside scope. Confirm discovery, implementation, hosting, support, security updates, data export, source-code terms where relevant and exit arrangements in writing.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Related_ZamaCore_resources\"><\/span>Related ZamaCore resources<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<ul>\n<li><a href=\"https:\/\/zamacore.com\/solutions\/courier-dispatch-software-kenya\">courier dispatch software in Kenya<\/a><\/li>\n<li><a href=\"https:\/\/zamacore.com\/blog\/electronic-proof-of-delivery-software-kenya\/\">electronic proof of delivery software<\/a><\/li>\n<li><a href=\"https:\/\/zamacore.com\/blog\/distributor-management-system-kenya\/\">distributor management system<\/a><\/li>\n<li><a href=\"https:\/\/zamacore.com\/solutions\/inventory-management-software-kenya\">inventory management software in Kenya<\/a><\/li>\n<li><a href=\"https:\/\/zamacore.com\/contact\">contact ZamaCore<\/a><\/li>\n<\/ul>\n<h2><span class=\"ez-toc-section\" id=\"Frequently_asked_questions\"><\/span>Frequently asked questions<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<h3><span class=\"ez-toc-section\" id=\"What_is_a_delivery_exception\"><\/span>What is a delivery exception?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>It is a documented deviation from the expected fulfilment outcome that needs review or action. Examples include customer unavailable, partial acceptance, damage, wrong item, disputed quantity, return or failed hand-off. The record should connect the event to the correct order and attempt.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"Does_exception_management_require_GPS_tracking\"><\/span>Does exception management require GPS tracking?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>No. Location data may be relevant in some operations, but it is not the core requirement. A controlled workflow can focus on order, attempt, reason, quantity, evidence, owner, return and resolution using the organisation\u2019s available processes and devices.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"How_should_partial_delivery_be_recorded\"><\/span>How should partial delivery be recorded?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Record accepted, rejected and returned quantities by relevant order line, preserve the original planned quantity and assign the unresolved balance. The system should update connected operational records according to approved rules without making the whole delivery appear complete.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"When_can_returned_goods_become_available_stock\"><\/span>When can returned goods become available stock?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Only after the organisation\u2019s required physical receipt, condition check and status decision. The exact rule depends on the product and policy. Software should keep expected, received, held, damaged and released quantities distinct and traceable.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"What_should_a_delivery-exception_pilot_test\"><\/span>What should a delivery-exception pilot test?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Include unavailable recipient, partial acceptance, damage, wrong item, customer dispute, returned goods, replacement or redelivery, an approved commercial outcome, overdue work and a reopened case. Verify the result across order, delivery, inventory, customer communication and finance hand-off.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Discuss_this_workflow_with_ZamaCore\"><\/span>Discuss this workflow with ZamaCore<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Bring one failed or disputed delivery and follow it from the field report through customer communication, depot return, inventory status and final resolution. ZamaCore can review the workflow through an online demo or an appointment-based in-person discussion at the Zama Systems office in Karuguru Plaza along Eastern Bypass. Bring a representative form, spreadsheet, report or de-identified transaction so the discussion stays grounded in the way your team actually works.<\/p>\n<p><a href=\"https:\/\/zamacore.com\/contact\"><strong>Request a ZamaCore workflow discovery or demo appointment<\/strong><\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Use delivery exception management software Kenya teams can configure to resolve failed deliveries, damage, partial acceptance, returns and replacement work.<\/p>\n","protected":false},"author":1,"featured_media":655,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-656","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/posts\/656","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/comments?post=656"}],"version-history":[{"count":1,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/posts\/656\/revisions"}],"predecessor-version":[{"id":657,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/posts\/656\/revisions\/657"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/media\/655"}],"wp:attachment":[{"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/media?parent=656"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/categories?post=656"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/tags?post=656"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}