Clarity in the product. Clarity in the promise.

A long feature list is not useful if an everyday exception cannot be explained. Product discussions should include the ordinary cases and the awkward ones.

• Ask how batches, returns or partial payments are handled today.
• Identify the exact record a team needs to inspect.
• Prioritise a coherent workflow over unrelated options.

Automation is useful when a user can understand its inputs and review its result. Data mapping and reconciliation need clear evidence of how a record was interpreted.

• Show source context and mapped values.
• Keep unresolved differences visible.
• Make correction and review steps explicit.

A planned capability is not the same as a tested workflow. Pilots and future integrations should have clear boundaries and an agreed way to review results.

• State current development status.
• Confirm supported formats and workflows.
• Avoid implying guarantees from a product description alone.

When a figure is corrected, the person looking at it later should be able to find out what happened. Records are appended and corrections are recorded as their own events, rather than quietly replacing what was there before.

• Corrections are recorded as events, not silent replacements.
• Permissioned review, with approval separated from the person making the change.
• Audit trails support investigation. They do not replace an auditor and do not imply certification.

A billing counter should not depend on a round trip to a data centre to record a sale. Operations are designed around a local service and database at the location, with the network as a convenience for everyday work rather than a requirement.

• Designed around local operational records at each location.
• No offline-uptime guarantee is made. Deployment and recovery validation are separate gates.
• Backup responsibility and a demonstrated restore belong in the agreed pilot scope.