Before a commercial launch, Epistles will require complete and accurate service terms covering subscriptions, supported postal products, order acceptance, charges, fulfilment, cancellations, refunds, liability, complaints and applicable customer rights.
It would be misleading to paste generic policies into a live site and imply that those terms had been approved for a service that is still being developed. These pre-launch disclosures will be replaced with formally reviewed documents before any transactional feature is enabled.
Future customers will need to understand the difference between paying for ongoing correspondence software and placing a one-off physical postal order. A subscription term cannot substitute for an explanation of print choices, dispatch cut-offs, handling exceptions, cancellation stages and what counts as completion of the postal service. Equally, the terms must distinguish an email accepted by a provider from a confirmed delivery or read event.
The commercial terms will also need to address account access, authorised business users, evidence retention, customer-provided content, acceptable use and service interruption handling. These conditions should be based on tested operations and appropriate legal review. Publishing them prematurely would create a false impression that customer transactions are already available, so the current page is deliberately limited to a transparent pre-launch status statement. A fair order policy must explain how corrections are handled before printing starts, what happens after dispatch, how failed email delivery is communicated and what records are provided to the sender. It must not conflate the act of submitting an order with evidence that the recipient received a document. For paid services, the business will need an agreed process for complaints, payment disputes and refunds, including any statutory consumer rights that apply. Account terms should also explain how an organisation authorises staff to create correspondence and what happens when those permissions change. These are substantial commitments, and the wording should be approved against the actual operating system before commercial transactions begin.
Pricing that is clear before someone commits
A subscription for managing correspondence and a one-off charge for printing and posting are different products. Epistles should show them separately, including any extra pages, paper choices, postage classes, enclosures and applicable taxes before a customer authorises an order. A price calculator must not invent prices if provider rates have not yet been agreed.
Individuals may prefer a simple personal plan or occasional transactions, while firms may need team seats, storage allowances and volume rates. The public website should explain the pricing model clearly even before final commercial figures are published. It should not display fictional savings or ambiguous “free” promises.
From a digital letter to physical post
An online postal journey should begin with a clear preview of the final letter and enclosures. Customers need to check the postal address, paper and printing choices, postage class, estimated handling times and full price before confirming an order. The service should explain whether it offers ordinary postage, tracked services or proof of posting and should never promise a capability that has not been arranged with a fulfilment partner.
During an initial manual fulfilment operation, Epistles would maintain an internal queue for authorised staff to print, check, pack and hand correspondence to the carrier. Later integrations can automate parts of that workflow, but the customer should continue to see one consistent order history. Delivery evidence must accurately reflect the information supplied by the carrier or operations team.
Privacy is part of the service, not an afterthought
Correspondence often contains sensitive personal, financial or business information. Access control, secure transport, protected storage and careful document sharing have to be designed into the workflow from the beginning. Individuals should see only their own records, while organisations should be able to grant carefully scoped access to colleagues.
Public QR verification, analytics and search indexing must not become shortcuts around those restrictions. Retention should reflect legitimate requirements rather than promising to keep everything forever. Customers need clear explanations of how records are stored, who can handle postal fulfilment and what happens when they request deletion or export.
Help written for the question someone actually has
A helpful answer starts with the task. “How do I add a letter I received?”, “Can I keep attachments with it?” and “How will I know whether my letter was posted?” are more useful starting points than a long list of internal system names. Every guide should explain steps in plain language and show what information the system records.
Where the answer depends on a postal provider, a signature method or a future integration, the documentation must say so. Support articles should be reviewed when a feature changes, and obsolete instructions should be redirected or retired rather than remaining in search results indefinitely.