A merchant can like a report and still refuse to connect the account that produces it. The report may look useful, but the purchase asks several additional questions. Will the software expose customer information? Will it change anything? What happens when the answer is wrong? Can the merchant leave without losing the work?
Those questions belong in the product, not only the sales conversation. Software earns trust when its behavior makes a specific promise credible and gives the customer a workable response when that promise fails. Attractive branding can introduce the promise. Repeated, observable behavior must support it.
This chapter of The AI Software Factory applies the broader trust capital argument to an app’s operating behavior. The competitive advantage proposed here is a hypothesis to test: credible limits and reliable recourse may make an otherwise useful product easier to adopt. No conversion improvement is assumed merely because the interface looks reassuring.
Identify the risk behind the hesitation
A buyer’s question about security may conceal several different concerns. They may fear account takeover, an inaccurate recommendation, a public mistake, an unexpected bill or being trapped with a supplier who disappears. A generic security badge cannot resolve every one of those concerns.
Ask what consequence the buyer wants to avoid. In a hypothetical merchant report app, the buyer might accept an occasional classification correction but reject any possibility that the software publishes prices automatically. That distinction should change permissions, the workflow and the offer.
Record the concern in the customer’s language and connect it to a behavior the product can demonstrate. “I need to know nothing changes without me” suggests a read-only connection and a visible action preview. “I cannot lose the results if I cancel” suggests a usable export and a clear retention policy.
This is also a discovery technique. If the buyer cannot identify a material concern and does not value the result, more trust features may simply polish an unwanted product. Address uncertainty that obstructs a real use case before building an elaborate assurance center.
Create a promise inventory
A product makes promises in more places than its headline. A button saying “undo” promises recovery. A label saying “private” promises a data boundary. A progress indicator promises that work is happening. A price page saying “unlimited” promises a commercial obligation whose meaning customers will interpret broadly.
List consequential promises across marketing, onboarding, settings, support and billing. For each, identify the responsible system behavior and the evidence available to the customer. If a promise cannot be tied to either, revise it or build the missing behavior.
The inventory should include implied promises. A report dated today may suggest fresh source data even if the input was uploaded last month. A polished answer without a source date may suggest certainty that the model cannot justify. Fix the representation before arguing that the fine print was technically accurate.
Assign an owner to each promise. Privacy language should match the actual data lifecycle. Availability language should match the operating process. Commercial language should match the billing configuration. A founder who changes one surface should know which others need review.
Make the boundary visible before commitment
A prospective customer should be able to understand what the app reads, what it stores and what it can change before granting access. The explanation need not expose implementation details. It should describe consequences in ordinary language.
For a proposed report connection, “Reads inventory and sales reports to prepare recommendations; cannot edit listings” is more useful than a list of unfamiliar authorization scopes alone. The underlying scope still needs to enforce the claim. A friendly explanation cannot compensate for broad write authority.
Show when the boundary changes. An optional publishing feature should explain its new authority at the point of enablement. It should not inherit consent from the initial read-only connection because both features happen to share an account integration.
Safe AI writes develops the commitment protocol. Here the trust question is whether the customer can predict when preparation becomes action. Surprise creates friction even when the resulting action happens to be correct.
Use evidence customers can inspect
Trust evidence should fit the decision. A merchant considering a reorder recommendation needs source dates, relevant quantities, assumptions and a way to check the calculation. A procurement reviewer may need data-processing terms and access controls. These are related but different evidence needs.
Avoid collecting impressive artifacts simply because competitors display them. A long document that does not answer the buyer’s concern adds reading work. A concise explanation supported by the actual workflow may be more useful, though regulated or contractual reviews can require substantial documentation.
Make evidence inspectable at the moment it matters. Put source rows beside the recommendation, a change preview beside the action and billing units beside the charge. A separate help page can explain details, but it should not be the only place the product discloses a consequential assumption.
Distinguish a recorded fact from an inference. “The report contains six sales” is a source observation. “Demand is likely to rise” is an inference requiring assumptions. Combining them in one confident sentence makes it harder for the customer to identify the part they should question.
Reliability records need a denominator
A claim such as “thousands of successful jobs” says little about the failures or the difficulty of the work. A useful reliability record specifies what counts as a job, which period it covers and what outcome counts as success.
For a hypothetical import service, report accepted files, completed imports, rejected files and unresolved failures separately. A file rejected because required columns are missing should not vanish from the account history. It may represent good validation, but it still matters to the customer’s experience.
A measured record also needs limits. Results from small standard files do not prove performance on larger or unusual formats. A period with no provider outage does not establish behavior during one. Publish only the claims the actual observations support.
Start by collecting evidence internally if the record is immature. The absence of a public reliability percentage is better than a percentage invented from incomplete logs. Customers can still see their own job status and receive honest explanations of known limitations.
Design the failure experience deliberately
An error message is part of the product’s promise. “Something went wrong” leaves the customer unable to distinguish a rejected request, a temporary dependency problem and a completed action whose acknowledgment was lost.
Where evidence permits, state what happened, what is known about the effect and what the customer can do next. If the app cannot establish whether an external write succeeded, say so and prevent a careless repeat. A reassuring but unsupported “nothing changed” can be more damaging than a clear unresolved state.
Give the failure a stable reference that support can investigate without asking the customer to repeat sensitive input. Preserve the relevant operation state. Keep private details out of broadly visible logs and messages.
Software rollback explains recovery mechanisms. The customer-facing consequence is simpler: the app should help people recover their position, not merely announce that the developer has fixed the code. A technically repaired service may still owe the customer a corrected result or an explanation.
Recourse should be usable under stress
A refund policy, appeal process or support channel only builds confidence if a customer can use it when the product fails. Requiring them to find a hidden form, reconstruct internal identifiers or debate an ambiguous definition undermines the promise.
Specify what the customer should submit and what response they can expect. Avoid promising a response time the operation cannot sustain. If service hours are limited, say so before purchase and make urgent failure routes proportionate to the product’s consequences.
For a proposed report app, recourse might include rerunning a failed job, correcting a source mapping, exporting the accepted input and refunding an unusable paid run under stated terms. These are possible policies, not claims about an existing Salars service.
Track whether recourse resolves the original problem. A fast reply that sends the customer back through the same broken flow is not successful recovery. Count reopened cases and recurring exceptions so support evidence can improve the product rather than merely close tickets.
Commercial clarity is product behavior
A customer should understand what creates a charge, when charges occur and what happens at a limit. Usage pricing can work well when the unit maps to understandable value. It becomes harder to trust when background retries or unexpected input expansion change the bill without useful warning.
Show the included allowance, current usage and any relevant cap. Explain whether failed attempts count. If the system retries internally, decide how those attempts affect the customer’s obligation and disclose that decision consistently.
Cancellation deserves the same care as purchase. State when access ends, whether remaining work continues and how exports operate. If a customer can cancel online but must contact support to obtain their data, the exit behavior should be clear in advance.
The pricing chapter examines model selection. Trust asks a separate question: can the customer predict the commercial consequence of normal use? A higher transparent price may be easier to evaluate than a lower price with unclear obligations, but that remains something to test with the intended buyers.
Give customers an exit they can understand
Exit design is part of the buying decision because the customer may be committing valuable data or workflow dependence. An export should contain useful records in a format appropriate to the product, not just an opaque archive that preserves technical completeness.
Explain which records are exported, which derived outputs are included and which service-dependent features do not transfer. A standalone report may preserve most of its value outside the app. A live integration may require a new connection elsewhere.
Test exit with an account representative of actual complexity. Can the customer identify the files, interpret key fields and recover their work? Does the export omit hidden required relationships? Does it accidentally include another account’s information?
Do not equate portability with deletion. Privacy design traces what remains in backups, logs and processor systems. Customers need a scoped explanation of both exit and retention rather than an absolute claim that every copy disappears immediately.
Resist confidence theater
A green status icon, a model confidence score or a human-reviewed badge can look persuasive without representing meaningful evidence. Each should have an operational definition. Who reviewed what? Which checks passed? How old is the evidence?
A model’s fluent explanation does not establish that its answer is correct. If a score has not been calibrated for the task, avoid presenting it as a probability. A qualitative uncertainty statement tied to missing information may be more honest and more actionable.
NIST describes its AI Risk Management Framework as voluntary guidance addressing trustworthiness through design, development, use and evaluation. Its current page also says version 1.0 is being revised. Using that guidance does not certify a product or demonstrate that customers trust it.
Treat assurance artifacts as evidence with scope. A security review can support claims about the examined system and time. It cannot automatically support a newly connected feature, a new processor or a different data class. Revisit evidence when the promise changes.
Measure buying friction without assuming causation
A proposed trust improvement needs a success criterion tied to the problem it aims to resolve. If prospects hesitate over write access, measure comprehension of the boundary and continuation among relevant prospects. If customers struggle after failed jobs, measure recovery outcomes and repeated support contacts.
Do not attribute every conversion change to a revised explanation. Traffic mix, price, product quality and seasonality may change at the same time. A bounded comparison should hold what it reasonably can and record other changes.
Protect counterexamples. A buyer who proceeds quickly but misunderstands the authority is not a success. A customer who trusts the app enough to skip necessary review may face greater risk. Include understanding and safe completion alongside commercial results.
A small qualitative review can identify confusing language before a larger experiment. Ask participants to explain what the software can do and what happens if it fails. Their explanation is more revealing than agreement with a leading question about whether the page feels trustworthy.
Repair a broken promise with a narrower next promise
After a failure, a broad statement that the team takes quality seriously does little to clarify the customer’s position. Identify the affected promise, the known scope, the unresolved questions and the available remedy. Do not describe a suspected cause as established while investigation continues.
If a hypothetical report used stale inventory, separate correcting that report from preventing future stale inputs. The first helps the affected merchant now. The second changes source-date validation or the report representation. Both need evidence, and neither justifies saying every possible freshness problem has been eliminated.
A follow-up commitment should be small enough to verify. “We will identify the affected reports and provide corrected versions by the stated time” can be checked. “This will never happen again” reaches beyond the evidence and creates another fragile promise.
Keep a record of the repair in the account history where appropriate. Support should know what the customer has already received and which questions remain open. That avoids asking the customer to repeat the failure through several channels.
Trust repair may also require changing the offer. If a workflow cannot meet the advertised guarantee economically or technically, narrowing the guarantee can be the responsible result. A transparent limitation gives customers a sounder decision than continuing to sell a promise the system repeatedly misses.
What Would We Do at Salars?
For a proposed merchant diagnosis app, we would begin with one limited promise: transform a supported report into a reviewable diagnosis without changing the merchant’s account. The first version would make the source date and read-only boundary visible before processing.
We would create a promise inventory covering the sales page, connection screen, report, billing and cancellation. Each statement would point to an enforceable behavior or be narrowed until it matched one. “Private” would become a scoped explanation of data use and retention rather than a decorative badge.
A proposed release review would include a successful report, an unsupported file, an interrupted job, an uncertain recommendation and an account exit. Reviewers would inspect what the customer sees and whether the next action is clear. These exercises are proposed; this article does not report a deployed Salars app or measured conversion change.
We would then ask qualified prospects to explain the boundary and recourse in their own words. If the explanation remained confusing, we would revise it before increasing promotional claims. If prospects understood everything and still did not want the outcome, we would return to product discovery rather than add more assurance copy.
The useful form of trust capital is a customer who can accurately predict the software’s behavior, evaluate its evidence and recover when it falls short. That capability belongs in the operating design from the beginning. Explore the broader AI collection for the commercial and technical decisions that support it.
Sources
- NIST AI Risk Management Framework — voluntary lifecycle risk guidance and current revision notice; not product certification or measured customer trust.
Loading comments…