{"id":1083,"date":"2026-11-11T21:10:25","date_gmt":"2026-11-11T21:10:25","guid":{"rendered":"https:\/\/zamacore.com\/blog\/?p=1083"},"modified":"2026-11-11T21:10:25","modified_gmt":"2026-11-11T21:10:25","slug":"business-software-development-in-kenya-through-the-eyes-of-a-repair-workshop","status":"publish","type":"post","link":"https:\/\/zamacore.com\/blog\/business-software-development-in-kenya-through-the-eyes-of-a-repair-workshop\/","title":{"rendered":"Business Software Development in Kenya Through the Eyes of a Repair Workshop"},"content":{"rendered":"<figure><img decoding=\"async\" src=\"https:\/\/zamacore.com\/blog\/wp-content\/uploads\/2026\/11\/zamacore-business-software-development-in-kenya-through-the-eyes-of-a-repair-workshop-flier.webp\" alt=\"ZamaCore guide to connecting a Kenyan repair workshop's back office\"><\/figure>\n<p>At a pump repair workshop, the loudest machine can be the office telephone. A customer asks whether a borehole pump is ready. The technician has finished the repair, stores is waiting for the old seal and accounts has not been told that the customer approved an extra part. Each person gives an honest answer from a different record. The person on the telephone still cannot tell the customer whether to send a vehicle.<\/p>\n<p>Business software development in Kenya often starts with precisely this kind of gap. The problem is hard to see on an organisation chart because everybody already has a job and most departments already have a spreadsheet. The missing piece is a shared account of one repair moving between them. If you are planning software for a workshop or another service business, follow the job card before you design the management dashboard.<\/p>\n<p>Consider a fictional workshop in Industrial Area that services pumps for farms, apartment buildings and small factories. The examples below use invented jobs and figures so you can test the reasoning against your own records. No particular product is assumed. You can use the same walkthrough to evaluate an existing system, commission an extension or decide that a revised paper process will solve the immediate problem.<\/p>\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_86 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\/business-software-development-in-kenya-through-the-eyes-of-a-repair-workshop\/#Give_one_job_a_beginning_and_an_end\" >Give one job a beginning and an end<\/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\/business-software-development-in-kenya-through-the-eyes-of-a-repair-workshop\/#Map_the_workshop_with_verbs_people_recognise\" >Map the workshop with verbs people recognise<\/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\/business-software-development-in-kenya-through-the-eyes-of-a-repair-workshop\/#Decide_whose_equipment_is_in_the_building\" >Decide whose equipment is in the building<\/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\/business-software-development-in-kenya-through-the-eyes-of-a-repair-workshop\/#Make_quotation_versions_visible_to_everybody\" >Make quotation versions visible to everybody<\/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\/business-software-development-in-kenya-through-the-eyes-of-a-repair-workshop\/#Treat_a_parts_issue_as_a_physical_event\" >Treat a parts issue as a physical event<\/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\/business-software-development-in-kenya-through-the-eyes-of-a-repair-workshop\/#Record_labour_so_it_helps_the_people_doing_the_work\" >Record labour so it helps the people doing the work<\/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\/business-software-development-in-kenya-through-the-eyes-of-a-repair-workshop\/#Put_a_real_test_between_repair_and_release\" >Put a real test between repair and release<\/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\/business-software-development-in-kenya-through-the-eyes-of-a-repair-workshop\/#Take_finance_along_without_letting_it_design_every_screen\" >Take finance along without letting it design every screen<\/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\/business-software-development-in-kenya-through-the-eyes-of-a-repair-workshop\/#Commission_a_pilot_around_actual_workshop_pressure\" >Commission a pilot around actual workshop pressure<\/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\/business-software-development-in-kenya-through-the-eyes-of-a-repair-workshop\/#Decide_what_to_report_after_the_pilot\" >Decide what to report after the pilot<\/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\/business-software-development-in-kenya-through-the-eyes-of-a-repair-workshop\/#Try_a_Wednesday_call_from_an_impatient_customer\" >Try a Wednesday call from an impatient customer<\/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\/business-software-development-in-kenya-through-the-eyes-of-a-repair-workshop\/#Give_the_workshop_its_first_monthly_review\" >Give the workshop its first monthly review<\/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\/business-software-development-in-kenya-through-the-eyes-of-a-repair-workshop\/#Prepare_a_brief_your_developer_can_price\" >Prepare a brief your developer can price<\/a><\/li><\/ul><\/nav><\/div>\n<h2 id=\"s1\"><span class=\"ez-toc-section\" id=\"Give_one_job_a_beginning_and_an_end\"><\/span>Give one job a beginning and an end<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>A facility manager calls about a pump that trips after ten minutes. A driver drops it off with an unsigned handwritten note. The workshop can identify the model but cannot tell whether the caller has permission to approve a repair. If the first screen requires an approved quotation before a job can exist, staff will invent a value or keep the pump in a notebook. Start the record when responsibility begins.<\/p>\n<p>Give the intake record its own reference. Capture who delivered the item, who requested the work, how the asset can be identified and what condition was visible on arrival. A pump serial number and a customer&#8217;s asset number may both be useful. Neither is a substitute for the workshop&#8217;s job reference. The same pump can return for a different repair, and one customer can deliver several similar pumps on the same day.<\/p>\n<p>Define the end of the job with equal care. A technician may mark work complete when the pump passes a bench test. The workshop may still hold the pump pending payment or collection. The customer may have collected it while an internal review remains open. Choose language that reflects each event. A single completed flag will disappoint the first customer who drives to collect equipment still waiting for release.<\/p>\n<p>Try the definition on real work before building anything. Pick a recently collected pump and reconstruct its journey from the intake note, quotation, parts issue, test result and collection signature. Ask staff which event they can prove and which event they only remember. The gaps show where the new system needs a record. They also identify rules the business must settle before a developer can produce a meaningful estimate.<\/p>\n<h2 id=\"s2\"><span class=\"ez-toc-section\" id=\"Map_the_workshop_with_verbs_people_recognise\"><\/span>Map the workshop with verbs people recognise<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Invite a service adviser, a technician, a storekeeper and an accounts colleague to walk through the example. Use simple verbs. Receive the pump, diagnose the fault, quote, authorise, reserve parts, repair, test, release and collect. Write a name beside each verb indicating who normally acts. Then ask who can act when that person is on leave. A workflow requiring an absent manager to clear every repair will create a queue as soon as someone takes a holiday.<\/p>\n<p>For each step, identify what changes hands. Diagnosis hands a finding and a recommended action to the service adviser. Quotation hands a price and a scope to the customer. Approval hands authority to incur a cost to the workshop. A parts issue hands a physical item to a technician and creates a stock movement. Distinguishing these transfers prevents the design from treating every step as another editable note on the same screen.<\/p>\n<p>Ask each participant to identify the point at which they usually telephone a colleague. Why is the call necessary? The storekeeper might need to know whether the pump in bay two is the same one named on the issue slip. The service adviser might need permission to release a pump before the payment is allocated. These calls are evidence of missing information, uncertain authority or a genuine need for judgement. The software should address the first two and support the third.<\/p>\n<p>Capture useful disagreement. The technician says a job is waiting for parts, while stores says the part is on the shelf but reserved for another job. Both statements can be true. Make the distinction visible in the design. Stock on hand, stock available to promise and stock allocated to this repair are different facts. The workshop can then decide whether to move a reservation or wait for replenishment.<\/p>\n<h2 id=\"s3\"><span class=\"ez-toc-section\" id=\"Decide_whose_equipment_is_in_the_building\"><\/span>Decide whose equipment is in the building<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>A repair business handles assets it may never own. A pump left for diagnosis should not appear as workshop stock available for sale. Equally, a replacement motor purchased by the workshop belongs to its inventory until it is issued or sold under the relevant arrangement. Ask your developer to explain how the records distinguish customer property from workshop materials. The answer affects handling, reporting and customer confidence.<\/p>\n<p>Use location as a working fact. A pump may move from reception to a bench, a test area, an outside specialist and the collection cage. Record location changes only at points where someone needs to find the item or responsibility changes. Demanding a scan for every metre of movement invites staff to ignore the system. Define the few handovers that the workshop can maintain reliably, even on a crowded afternoon.<\/p>\n<p>Consider a subcontracted rewind. The pump body stays in the workshop while its motor travels to a specialist. A single location field for the entire asset can no longer tell a useful story. Ask whether the system needs a component record, a subcontract reference and an expected return date. Decide who checks the returning motor against the original job. A simple, well identified component record can prevent an expensive mix up.<\/p>\n<p>Plan for items left behind. If a customer delays collection, staff need a reminder tied to the job and a record of contact attempts. The application should preserve the customer&#8217;s equipment history while the business follows its agreed collection process. Avoid inventing disposal rights or automatic charges in a software specification. Have the business determine its terms, then give staff a clear way to apply those terms to a specific job.<\/p>\n<h2 id=\"s4\"><span class=\"ez-toc-section\" id=\"Make_quotation_versions_visible_to_everybody\"><\/span>Make quotation versions visible to everybody<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>A diagnosis might initially call for a seal replacement. Once the pump is opened, the technician discovers a worn bearing. The first quotation cannot simply be rewritten if the customer already approved it. Record the new finding, the proposed extra work and the customer&#8217;s decision. The original agreement remains part of the history, and the technician can see whether authority extends to the additional part.<\/p>\n<p>Design the approval evidence around how customers actually respond. One customer authorises work by purchase order, another through a named facility manager. Record the agreed method and identify the person on whose authority the workshop proceeds. If a telephone approval requires follow up in writing under your own rules, make that follow up visible. Avoid filling an approval field with a placeholder purely so the repair can advance.<\/p>\n<p>Give the service adviser a practical way to issue a revision. They should be able to see which lines changed, why they changed and whether the customer accepted each one. A customer might approve the bearing but defer repainting. If approval applies only to an entire quotation, staff may create several disconnected jobs to accommodate a partial decision. A line level decision can be valuable where partial approvals occur regularly.<\/p>\n<p>Test the customer&#8217;s view as well. Ask someone unfamiliar with the job to read the revised quotation. Can they tell the original work, the additional work and the amount they are being asked to approve now? Technical accuracy inside the application cannot compensate for an ambiguous document sent to a customer. Checking the printed or emailed result belongs in acceptance testing, alongside the screens that produced it.<\/p>\n<h2 id=\"s5\"><span class=\"ez-toc-section\" id=\"Treat_a_parts_issue_as_a_physical_event\"><\/span>Treat a parts issue as a physical event<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>A technician asks for a seal kit. The storekeeper has two kits on the shelf, one reserved for a different job. Ask whether the technician needs a reservation, an issue or a purchase request. Each action has a different consequence. A reservation protects a future promise. An issue records movement out of stock. A purchase request asks someone to obtain more stock. Combining all three under request part leaves everyone uncertain about availability.<\/p>\n<p>Keep the part identity precise. Two seals may look similar and fit different pump models. A storekeeper who searches by a local nickname should still be able to verify the part number, size and approved substitute. If the business permits substitutions, identify who authorises them and how the choice reaches the technician. The customer may need to approve a different material or price before work proceeds.<\/p>\n<p>Follow an unused part back to stores. A technician collects two seals and uses one. The other comes back in its original packaging. The system should connect the return to the original issue and update the job cost appropriately. If both seals remain charged to the job, the workshop might overcharge the customer or hide a stock difference. If both disappear from the issue record, the history becomes equally misleading.<\/p>\n<p>Ask how the application handles a damaged part. Returning a damaged bearing to available stock would make a future job appear better supplied than it is. The storekeeper may need a separate inspection or disposal path under the business&#8217;s rules. The repair job should retain a record of why the part was not used, who made the decision and what happened to its cost. This gives operations and finance the same explanation.<\/p>\n<h2 id=\"s6\"><span class=\"ez-toc-section\" id=\"Record_labour_so_it_helps_the_people_doing_the_work\"><\/span>Record labour so it helps the people doing the work<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>A technician may spend twenty minutes diagnosing a pump, wait an hour for approval and spend another forty minutes completing the repair. The customer experiences a longer turnaround than the technician&#8217;s hands on time. A useful system distinguishes waiting from active work. Otherwise management may wrongly conclude that the technician spent two hours repairing a straightforward fault when most of the delay came from an unanswered approval.<\/p>\n<p>Decide how accurate labour records need to be for the decisions you intend to make. If the workshop bills a fixed diagnostic fee, recording every minute may create more effort than value. If a specialist regularly travels between sites and assignments, start and finish records may help planners allocate scarce time. Ask staff to demonstrate the collection method. A rule nobody can maintain during a busy repair will create attractive but unreliable reports.<\/p>\n<p>Consider work shared by two people. A senior technician diagnoses the fault and a colleague completes the repair. Their observations and time records should remain distinguishable under one job. The test result may need an independent sign off depending on the workshop&#8217;s own process. A system with only one assigned technician can hide collaboration or encourage staff to share credentials. Model the real assignment pattern before choosing the screen layout.<\/p>\n<p>Show the people doing the work what they gain. A technician who can see the approved scope, parts ready for collection and unresolved questions has a reason to keep the job status current. If the only visible benefit is a management chart, staff may see data entry as an inspection of their behaviour. Useful information returned to the bench makes a better case for adoption than another reminder from the office.<\/p>\n<h2 id=\"s7\"><span class=\"ez-toc-section\" id=\"Put_a_real_test_between_repair_and_release\"><\/span>Put a real test between repair and release<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>A repaired pump can look complete before it has demonstrated satisfactory operation. Agree what evidence the workshop requires for a given job class. The example pump might need an observed run, a recorded result and a named technician confirming that the fault did not recur under the agreed test. The software should support the workshop&#8217;s competent technical judgement. It should never guess a safe operating result from the fact that a parts issue is complete.<\/p>\n<p>Capture failed tests as part of the job history. A pump may pass a visual inspection and fail after running. If staff can record only the final successful test, the workshop loses information about rework and repeated faults. Ask how the developer would represent the failure, the corrective action and the subsequent successful test. The customer may receive a concise report while the workshop retains more detailed technical observations.<\/p>\n<p>Decide who can release an item for collection. A technician&#8217;s successful test may be necessary, but accounts may also need to clear a credit hold. The service adviser needs to see which decision is pending and who owns it. A generic status of processing encourages telephone calls and vague promises. A precise status such as awaiting release authorisation makes it possible to tell a customer when an answer is expected.<\/p>\n<p>Test a reopened job. A customer reports the same fault after collection. The workshop must decide whether to reopen the original repair or create a linked return job. Ask what the customer should see and how the workshop will count rework. Rewriting the original completion date can distort turnaround reports and erase an earlier handover. A related record preserves the sequence and allows the team to investigate the cause fairly.<\/p>\n<h2 id=\"s8\"><span class=\"ez-toc-section\" id=\"Take_finance_along_without_letting_it_design_every_screen\"><\/span>Take finance along without letting it design every screen<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Finance needs a reliable basis for invoices, receipts and adjustments. The technician needs to know what work is authorised and which parts are available. These people can share references without sharing the same screen. Ask the developer to show how an approved quotation becomes a billing instruction and how actual work changes the instruction when appropriate. A mismatch should have an owner and a resolution path.<\/p>\n<p>Use a specific job to check the handover. A customer accepts a quotation including a seal and labour, then approves a second bearing. The final job includes both parts and a returned unused seal. Ask finance to reconcile the amount charged against the approved scope and actual issues. If the application merely sends the latest total to the accounting package, the accountant still has to reconstruct the explanation from messages.<\/p>\n<p>Clarify how external accounting records return to the workshop. The service adviser may need to know whether release is authorised without seeing the customer&#8217;s full financial history. A simple release instruction linked to an invoice reference can be enough. When the accounting connection is unavailable, agree who can authorise a temporary release and what evidence they must retain. The repair desk should never have to invent a payment to move a pump out of the collection cage.<\/p>\n<p>Keep a daily list of exceptions. Show jobs repaired but unbilled, approved extra work missing from a billing instruction and payments that cannot yet be matched. Give each exception an owner and a reason it remains open. The aim is to direct attention toward unresolved work. A long list containing every completed repair will bury the few cases that genuinely need a decision before the books can close.<\/p>\n<h2 id=\"s9\"><span class=\"ez-toc-section\" id=\"Commission_a_pilot_around_actual_workshop_pressure\"><\/span>Commission a pilot around actual workshop pressure<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Select a repair class that includes diagnosis, approval, parts, testing and collection. Use ordinary jobs and include a few difficult cases. A pilot consisting only of tidy examples can make an inadequate system look finished. Ask a relief service adviser to use the pilot as well as the usual enthusiasts. The relief colleague is more likely to expose terminology or assumptions that only the project team understands.<\/p>\n<p>Agree how staff will run the old and new records during the pilot. If the team enters every transaction twice, workload will rise temporarily. Name the official record for each decision and specify how the two sets of entries will be checked. If one system is used for customer promises and another for stock, misunderstandings can occur quickly. A short daily reconciliation is usually more manageable than a large investigation at the end.<\/p>\n<p>Choose clear acceptance evidence. Can reception identify every item in the collection cage? Can the technician see the latest approved scope? Can stores explain the difference between a reserved kit and an issued kit? Can finance trace every billed extra to customer approval? These questions are specific enough for staff to answer with records. A statement that the system is easy to use can complement those answers but cannot replace them.<\/p>\n<p>Rehearse a service interruption. If the workshop connection fails while a driver delivers a pump, someone still needs to acknowledge custody. Agree on a temporary numbered record, the person who will enter it later and the check that prevents a duplicate job. Run the exercise during the pilot and watch where confusion arises. A short interruption plan that staff have practised is more useful than a long document nobody has used.<\/p>\n<h2 id=\"s10\"><span class=\"ez-toc-section\" id=\"Decide_what_to_report_after_the_pilot\"><\/span>Decide what to report after the pilot<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Start with a report that prompts an action. Jobs waiting for customer approval can be assigned to the service advisers who need to follow up. Jobs awaiting parts can be reviewed by purchasing. Pumps ready for collection can trigger a call at an agreed time. Show the age of the wait and the last contact, so the responsible person can decide which customer needs attention first.<\/p>\n<p>Compare turnaround fairly. A simple seal replacement and a specialist rewind involve different work. Group jobs by an agreed repair class and distinguish internal work from external waiting. Otherwise a manager may conclude that a technician is slow when the real bottleneck is an outside service provider. Check a sample of jobs behind any unusual figure before changing staffing or promising customers a different completion time.<\/p>\n<p>Look for records that have stopped moving. A job can remain open because a pump is still under repair or because someone forgot to record collection. Both deserve action, but they require different action. Assign a regular review of old jobs and record the reason each remains open. A reliable list of unresolved jobs becomes a useful management tool because staff know it reflects real work in the building.<\/p>\n<p>Use the pilot&#8217;s evidence to choose the next improvement. If approvals now arrive promptly but parts are often reserved against the wrong job, improve identification before adding more reports. If finance can trace every charge but service advisers cannot see a release instruction during an outage, improve the fallback. Business software earns its place by removing a specific obstacle that people recognise in their working day.<\/p>\n<h2 id=\"s11\"><span class=\"ez-toc-section\" id=\"Try_a_Wednesday_call_from_an_impatient_customer\"><\/span>Try a Wednesday call from an impatient customer<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Imagine the service adviser taking a call at eleven in the morning. The customer&#8217;s driver is available for collection this afternoon and wants to know whether to set off. The adviser opens the job and sees that the technician finished the work yesterday. That fact alone cannot answer the caller. The bench test may still be outstanding, the customer may have approved only part of the repair or accounts may have placed a release condition on the equipment. Ask the pilot team to find the relevant facts while the caller waits.<\/p>\n<p>Give the adviser a precise scenario. The technician replaced the authorised seal and found that the bearing also needed attention. The customer approved the bearing by email. Stores issued a bearing of the correct size and the pump passed its test. Accounts has not yet reviewed the revised amount. The adviser should be able to distinguish technical readiness from commercial release and tell the caller who is making the remaining decision. A system showing only repair complete or invoice pending will leave the caller to interpret an internal status.<\/p>\n<p>Introduce a complication. The email approving the bearing came from the building caretaker, while the named purchasing contact normally approves additional charges. The adviser needs a route to resolve the discrepancy without accusing the caretaker or erasing the work already done. The application can display the earlier evidence and assign the question to a supervisor. The workshop&#8217;s own policy determines whether to seek further approval, accept the instruction or resolve the charge another way. Software should preserve the record whichever decision management makes.<\/p>\n<p>Have a supervisor answer the driver. A useful response might explain that the pump has passed testing, release is under review and the workshop will call back at a specific time. Record that commitment as an owned action. If the service adviser starts a lunch break, the replacement should see the same promise and know which decision is pending. A customer waiting for a collection answer experiences the workshop as one business, even though the information came from several desks.<\/p>\n<p>Return to the exercise after the decision. Finance confirms release and the driver arrives with an appropriate collection reference. Ask reception to identify the pump, check who is collecting it and record the handover. The collection should close the custody question without erasing the technical or commercial history. If the customer later calls about a missing accessory, staff should be able to inspect the intake and collection records and identify which accessories were documented at each point.<\/p>\n<h2 id=\"s12\"><span class=\"ez-toc-section\" id=\"Give_the_workshop_its_first_monthly_review\"><\/span>Give the workshop its first monthly review<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>After a month of use, select several jobs for review, including one routine repair, one subcontracted component and one disputed charge. Reconstruct each from intake to collection. Look for the moment the new software helped an employee answer a question more quickly. Then look for the moment somebody returned to a private note or telephone call. An accurate review needs both observations. The aim is to decide which parts of the design are already earning their place and which still need a change.<\/p>\n<p>Compare the number of jobs recorded as ready for collection with the physical items in the collection area. If the counts differ, trace the individual references. One pump may have been collected without the final signature. Another may have passed testing but remained in the workshop pending a commercial decision. These discrepancies lead to different improvements. The first may call for a simpler handover step. The second may require a clearer distinction between repair complete and release authorised.<\/p>\n<p>Ask stores to select one heavily used part and reconcile its movements across the same jobs. Trace issues, unused returns, damaged components and any substitutions. A difference does not immediately establish a stock loss. It may reveal that a technician changed a component after diagnosis and the original issue remained attached to the wrong job. The record should help staff identify the cause and correct it openly. If they can fix only the total, the next workshop review will need to rediscover the same explanation.<\/p>\n<p>Give each agreed improvement a concrete acceptance example. If the workshop wants better visibility of approvals, define which employee should see the caretaker&#8217;s email, which person reviews its authority and where the promised callback appears. Estimate development changes separately from training or policy changes. A useful monthly review ends with a small number of decisions that somebody can test on the next repair. A long list of vague requests for improved visibility usually means the workshop still has not identified the missing handover.<\/p>\n<p>Test the agreed improvement on a repair handled by relief staff. Their ability to find the specific pending customer approval and keep the customer&#8217;s callback promise is a practical measure of whether the change will survive the next shift handover.<\/p>\n<h2 id=\"s13\"><span class=\"ez-toc-section\" id=\"Prepare_a_brief_your_developer_can_price\"><\/span>Prepare a brief your developer can price<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Send a sample job card with customer details removed, a repair sequence agreed by the team and the hard cases you expect the pilot to handle. Identify the accounting package, the staff available for testing and the decisions that must remain with a qualified workshop employee. Ask the supplier to separate discovery, configuration, development, migration, training and support so you can see what effort the workshop must provide.<\/p>\n<p>Request a demonstration using your own sample numbers. Take one pump from intake to collection, return an unused part, record a failed test and approve additional work. Ask a service adviser who did not attend the sales meeting to follow the resulting record. If they can tell the customer what happened and what happens next, the process has begun to deliver the visibility the workshop wanted.<\/p>\n<p>A productive discussion about business software development in Kenya begins with a real handover. Bring the pump reference that your colleagues found hardest to explain. Invite reception, stores, the bench and accounts to follow it together. Their disagreements will help define the scope of a system worth building. For more guidance on commissioning software around daily operations, visit the <a href=\"https:\/\/zamacore.com\/blog\/\">ZamaCore business software blog<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Plan business software for a Kenyan repair workshop. Follow the job from intake through decisions, work in progress and a defensible handover.<\/p>\n","protected":false},"author":1,"featured_media":1084,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1083","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\/1083","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=1083"}],"version-history":[{"count":1,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/posts\/1083\/revisions"}],"predecessor-version":[{"id":1085,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/posts\/1083\/revisions\/1085"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/media\/1084"}],"wp:attachment":[{"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/media?parent=1083"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/categories?post=1083"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/tags?post=1083"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}