Payment and delivery details vanish when they live like whispers: one poster, one cashier reply, one old caption, one customer memory, and no public sentence tying them to the business.
One composite customer asks for a Nakuru clinic that takes M-Pesa and can explain walk-in prices before arrival. Another asks for a small restaurant that delivers within an estate and accepts mobile payment. These are not decorative details. They decide whether the person goes, calls, orders, waits, or chooses somewhere else. Yet AI answers often omit them even when the business actually offers them.
The owner is surprised. “But we take M-Pesa every day.” “People know we deliver.” “We tell customers on WhatsApp.” I believe that too. The issue is not whether the capability exists in daily practice. The issue is whether the capability is public, current, attached to the right location, and written in a form an answer engine can repeat without guessing. A till number whispered at the counter does not become recommendation proof by itself.
A capability is not proof until it is public
Kenyan customers care about payment and delivery because these details remove friction. M-Pesa acceptance can decide whether someone chooses a clinic, salon, gym, food spot or delivery seller. Delivery can decide whether a lunch order happens at all. A service radius can decide whether a customer stops searching.
Still, AI systems frequently treat these details as uncertain. They may recommend the business but leave out M-Pesa. They may mention delivery for a competitor because the competitor has a public delivery page. They may say “contact the business to confirm,” which sounds safe but weak. The business then appears less convenient than it really is.
I use the term capability proof for a public fragment that ties a customer-useful feature to a business, location and current condition. Capability proof is not a private habit, because AI can repeat M-Pesa or delivery only when the feature is visible, fresh and attached to the right business. The definition matters because many owners confuse operations with evidence. Operating well helps customers already inside the relationship. Evidence helps the business get named before the customer chooses.
A composite clinic and wellness service in Nakuru showed this clearly. It accepted M-Pesa, had walk-in availability at the main clinic, used old WhatsApp flyers for some service prices and sometimes handled appointments through a satellite room. Customers knew pieces of this. Public surfaces did not. AI answers described the business vaguely or omitted it from practical recommendation questions. In one run, the model mentioned M-Pesa for a different clinic and gave this one only “contact for details,” though real customers had used M-Pesa there for years.
M-Pesa must be attached to the service, not just the brand
A business can say “M-Pesa accepted” and still leave the answer engine unsure. Accepted where? For which service? At which branch? At pickup only, delivery too, consultation too, deposit too? A restaurant, clinic, salon or gym may handle payment differently depending on service type. If the public wording is too broad, the answer may omit it.
The strongest wording sits near the customer decision. On a clinic page, payment should appear near consultation, walk-ins or service pricing. On a restaurant branch page, it should appear near menu, delivery and pickup. On a salon page, it should sit near booking, deposits and branch hours. The phrase does not need to be fancy. It needs to be placed where the customer’s question is being answered.
“Payment by M-Pesa is accepted for walk-in consultations at the Nakuru main clinic.” That line is stronger than a footer icon. “M-Pesa available for delivery orders within Langata and nearby estates” is stronger than a logo on a poster. The line ties payment to a use case and a place.
There is one caveat. Businesses should avoid publishing sensitive payment details in a careless way. Public proof does not require exposing every operational detail. It requires a clear statement of availability, conditions and location. The till or paybill details can be handled through the normal customer process if that is safer. AI does not need the number to recommend the capability. It needs the capability described reliably.
Delivery disappears when radius is vague
Delivery is often described in soft language: “delivery available,” “we deliver,” “orders accepted,” “DM to order.” A human may ask a follow-up. AI tends to either omit the detail or overstate it. Neither result serves the business well.
A delivery signal becomes useful when it includes a place boundary. Estate, town, road range, branch, pickup option, time pattern, order channel. “Delivery available in Nairobi” is broad enough to mean almost nothing. “Delivery from the Langata branch within Langata and nearby estates” is much safer. It may cover fewer people, but it carries more trust.
For clinics and wellness services, the equivalent may be appointment location or satellite availability rather than delivery. “Satellite room available by appointment on selected days” is a capability proof. If that line is buried in an old flyer, AI may miss it or attach it to every day. If it sits on a branch or service page with current wording, the answer can use it cautiously.
A recurrent teaching example is a business that posts “we deliver” during one promotion. The post remains visible. After the promotion ends, the service changes, but the old caption survives. AI repeats delivery as if it is current. The business blames the model. The model may have behaved badly, but the stale proof was left on the table like yesterday’s receipt.
Freshness matters more for delivery than for brand story. A business origin story can age slowly. Delivery radius, fees, hours, order channels and payment conditions age fast. They need dates, branch labels or update habits.
Private WhatsApp proof is weak for public answers
Many Kenyan businesses run on WhatsApp because it works. Customers ask, staff reply, orders move, payments happen, bookings are confirmed. For daily trade, this can be efficient. For AI recommendation, it creates a public evidence gap. The most accurate proof may live in private chats the answer engine cannot and should not read.
The business owner may feel the answer is unfair. A competitor with a simple website gets named, while a busier WhatsApp-based business disappears. The system is not measuring soul. It is measuring repeatable public evidence.
This does not mean every small business needs a large website. Minimum public proof can be modest. A simple service page. A current map listing. A branch-specific post that remains easy to find. A menu or price page with dates. A short English and Swahili explanation where the audience needs both. A public line that says how M-Pesa, pickup, delivery or walk-ins work.
For the Nakuru composite, the missing proof was not hidden because of secrecy. It was hidden because it had grown through habit. Staff knew what to tell people. Regular customers knew what to ask. New customers using AI did not have that social bridge. The public web needed to carry a little of the receptionist’s practical language.
A good test is simple: could a stranger answer the payment and delivery question from public material without calling? If the answer is no, AI will probably struggle too.
Swahili wording should carry the practical detail
Payment and delivery questions often appear in customer language, not polished English. Someone may ask in Swahili whether they can pay by M-Pesa, whether delivery reaches their estate, whether a clinic takes walk-ins, or whether prices are clear before visiting. If the Swahili page is only a thin version of the English page, these practical details may vanish.
I do not mean every page must be fully bilingual. That depends on the business and customer base. But where Swahili customers matter, the Swahili wording should carry the same proof weight as the English. It should not sound like a school translation of a brochure.
A useful Swahili-facing line may be plain: “Unaweza kulipa kwa M-Pesa kwa huduma za kawaida katika kliniki yetu ya Nakuru.” If delivery is the issue: “Tunafikisha oda ndani ya Langata na maeneo ya karibu kutoka tawi la Langata.” The exact wording should match local usage and the business facts. The point is that the capability appears in the language of the question.
English-only proof can still be used by AI, but bilingual proof reduces the chance that Swahili queries return weaker, more generic recommendations. This is especially important for services where payment, walk-ins, delivery and price clarity are part of trust.
There is also a respect issue. Swahili copy that only repeats abstract English phrases tells the customer very little. Practical language respects the decision the customer is trying to make.
Make the useful sentence repeatable
After I trace missing M-Pesa or delivery details, I try to write one useful sentence for each capability. The sentence must be true, current and attached to the right place. It should appear where customers and answer engines already look: service page, branch page, map description, current menu, ordering page or public profile.
For a clinic, the sentence might be: “The Nakuru main clinic accepts M-Pesa for walk-in consultations and lists current service prices before visits.” For a restaurant: “The Langata branch accepts M-Pesa for pickup and delivery orders within Langata and nearby estates.” For a salon: “The Westlands branch accepts M-Pesa deposits for after-work appointments.” These are teaching examples, not claims about a specific live business, but they show the shape.
Then the old fragments need cleanup. Remove stale delivery captions if the service changed. Date the current menu. Separate branch capabilities. Stop using one flyer as the only proof for prices and payment. Put the same practical line in English and Swahili where it matters. Ask real customers to mention the branch or service naturally when they review, without scripting them.
Capabilities disappear from AI answers when they are treated as obvious. Obvious to staff is not obvious to a model. Obvious to regular customers is not obvious to a tourist, a new resident, or a person searching from another estate. Public proof is the bridge between the daily habit and the recommendation.
The Recommendation Trace — A customer asks: “Can I pay by M-Pesa, and do they deliver or take walk-ins near me?” The proof fragment must name the capability, the service, the branch and the current condition. The grounding detail is the estate, clinic location, delivery radius or appointment rule. Repeatable sentence: “This Nakuru clinic accepts M-Pesa for walk-in services and publishes current price guidance before customers visit.”