KENYA · GUIDE 0599 · EDITION 4.2
Software user training in Kenya: Customers and Market Demand
The buyer and the buying decision
Small organizations adopting a business system. The offer to test is: Train users to complete specific tasks in software they are authorized to use.
Teach users the software tasks their roles require, agreeing starting skills, training access, safe practice data, and the support route for unfamiliar cases.
Separate interest from an accepted order
Pilot one lesson ending in a completed fictional transaction.
The purpose of this test is to establish whether the buyer accepts the specified result, delivery arrangement and payment terms. An encouraging interview does not establish repeat demand. Ask what the buyer currently uses, what would make them change supplier and who has authority to approve the first order. Record a refusal as carefully as an enquiry so that unsuccessful offers do not disappear from the evidence.
Collect evidence specific to this offer
Record baseline skills, tasks completed independently, repeated mistakes, access barriers, learner questions, and job-specific guidance needed before the team adopts routine software use.
| Question to resolve | Evidence to retain |
|---|---|
| What exactly will the buyer accept? | Ask learners to complete realistic tasks independently, including correction and recovery, rather than accepting attendance or copied demonstration steps as evidence of competence. |
| What is included in the first trial? | Teach users the software tasks their roles require, agreeing starting skills, training access, safe practice data, and the support route for unfamiliar cases. |
| How will a prospect see the offer? | Offer role-specific demonstrations and measure actual task completion. |
| What must happen before repeating the trial? | Learners can perform the agreed task; no unsupported certification or competence claim. |
Decide whether to continue
Review the specification with the buyer before committing to tools or stock. A trial is commercially useful only if actual costs, rejected work, time spent and cash collected can be reconciled. Training fails when users can repeat a demonstration but cannot recognize an error or know whom to contact before changing live business records.
If a buyer changes the required output, record a new scope and re-cost the test. Do not count a request for a different product as proof of demand for the original one. Keep personal contact details in your private records and use customer statements publicly only with permission.
Turn the example into a buyer test
Fictional user training USR-99 teaches six shop staff a two-hour Loyverse session using three workflows: find an item, review an authorised stock change and retrieve an approved report. Each learner uses fictional training items and completes a task sheet. Certification, account sharing, live cash transactions and deciding accounting/tax treatment are excluded.
| Buyer discussion | Evidence to retain |
|---|---|
| Specification to confirm | Training does not grant permissions the job role lacks. |
| Output to inspect | Staff know when to stop and ask rather than invent a corrective stock adjustment. |
| Failure that can defeat acceptance | Learner cannot find item |
Ask the buyer to describe one acceptable and one unacceptable result. Record the decision maker, price basis, quantity, handover point and payment date privately. A sample request, an encouraging conversation and an accepted order are different evidence. Keep the first commitment within your demonstrated capacity; no customer interview or successful trial is asserted here.
What a failed test should change
Check code/name and supported search fields.. If the offer cannot meet that check, revise the specification or process before promising a repeat. Keep rejected offers and reasons in the same register as positive replies so that your record does not exaggerate demand.