Design an MVP customers can understand when a service is unavailable

Start with the action the customer believes is complete

Imagine a fictional Tanta service that helps customers prepare a room-design brief. A visitor signs in, saves preferences and optionally asks a public-information helper about the process. The most damaging confusion may be a simple sentence: “Your brief is saved” when the request has not been confirmed. The customer leaves and assumes the team has everything needed.

List the claims your interface makes: signed in, loaded, saved, sent, answered and completed. Beside each claim, write the evidence required before showing it. A clear state model is a product feature. It helps customers make a sensible next choice and gives support a shared vocabulary instead of a collection of contradictory screenshots.

Distinguish waiting, uncertainty and a confirmed result

Use the wording only when the application has evidence for that state. A timeout is not automatically proof that nothing changed. An empty record returned successfully is different from a record the application could not read. Avoid turning either situation into a reassuring message that the system cannot support.

Keep sign-in problems separate from customer identity

The Gammal Tech integration guide provides session methods for the supported login flow. Your interface still needs to show when sign-in is needed and start it from the customer’s explicit action. If the flow is cancelled or cannot finish, offer a clear route back to the page rather than leaving a disabled screen with no explanation.

Do not diagnose the problem by displaying a session token or requesting it through support. Ask for the page, time and visible symptom. A customer can describe “the window closed and the page stayed signed out” without sending a sensitive network export. Keep account support and application support distinct so the right person receives the question.

If the interface shows an earlier signed-in label after an operation fails, treat it as a state to review. It is not permission to continue a protected business action merely because a familiar name or button remains visible.

Protect the customer from a destructive recovery step

When loading saved preferences fails, do not automatically create defaults and save them over an unknown existing record. Show that retrieval is unavailable and keep the save path from pretending it has a complete current record. Once a supported read succeeds, reconcile the displayed data with any draft the customer still has before submitting another change.

A browser can keep an in-memory draft during the current page visit if the application implements it. Tell the customer what that means. Do not promise the draft survives a closed tab, a refreshed page or another device unless that behavior is actually built and checked. Avoid quietly persisting sensitive drafts just to hide a failure.

For the room-brief example, a useful message is: “Your current edits are still visible on this page. We have not confirmed they are saved.” That distinguishes the customer’s visible effort from the service’s confirmed state without claiming a backup feature.

Make the information helper optional to the core journey

If the information helper is unavailable, the customer should still be able to read the service description and find the ordinary contact route. Keep essential instructions on the page rather than requiring an AI answer to reveal how the business works. This is especially useful for a small startup whose first offer should remain understandable without a conversation.

A returned string may be a service notice or an answer needing review. Display it safely and avoid treating it as a confirmed booking, a payment decision or a message already sent to staff. A public prompt does not grant those capabilities. Use the documented AI service within its intended information role and review unknown-answer behavior.

Give a contact option that genuinely exists. “Contact the team using this address” is different from “We have alerted the team,” which would need an actual completed process.

Rehearse failures without disrupting the service

1. Create local fictional fixtures for pending, unconfirmed and unavailable states.
2. Ask a colleague what they believe has already happened on each screen.
3. Check whether the next step could duplicate a request or overwrite unknown work.
4. Review keyboard access, status announcements and whether controls become usable again.
5. Record the expected state, observed wording and the owner of each correction.

These checks assess your interface; they do not require provoking a live outage or sending real payments. Keep credentials and customer records out of screenshots. A small set of understandable states is more useful than inventing a separate message for every low-level exception.

Connect the screen to a real operating response

Name who reviews customer reports, who checks configuration and who decides whether to pause the affected function. Record the support hours the business can provide and the evidence it needs. The NIST small-business guide includes response and recovery in risk planning; your worksheet turns that general responsibility into decisions for this particular product.

Your finished artifact is the state table, approved wording, failure fixtures and escalation note. Review it whenever a feature adds a new kind of commitment. The founder can then demonstrate a considered customer experience: the website helps people understand both success and interruption, while the team has a practical route to restoring the service.

Common questions

Should every failed request be retried automatically?

No. Some failures leave the outcome uncertain, and the SDK already has network retry behavior. Define a supported recovery step for the operation rather than adding a blanket repeat loop.

Does a friendly error message replace technical reliability work?

No. It makes the customer journey clearer while the team addresses the cause. The product still needs appropriate integration, monitoring, support and recovery arrangements for its scope.