What does the customer believe happened after “recibido”?

An acknowledgement is a small piece of content with a large job. It tells the customer how to interpret the action they have just taken. A polished translation can still produce the wrong expectation if nobody has agreed which event the message describes.

For a Venezuela-connected catalogue, useful Spanish and English versions must preserve the business meaning across the product page, request form and follow-up. The review starts with the event and the customer's next decision, then works toward the words.

Build a case in which receipt is real but the decision is incomplete

Imagine a fictional request for a replacement part. The customer provides a product reference and a quantity but cannot tell whether the connector measurement includes its outer rim. The application stores the request. Staff must ask for clarification before deciding whether the item is suitable and available.

At that point, a receipt can truthfully say that the request arrived. It cannot yet say that the business accepted the order. “Pedido confirmado” may lead the customer to expect supply, while “We've received your enquiry” describes a weaker event. If those appear as counterparts, the two audiences have not been given the same process.

Write the underlying fact in plain language before drafting the interface: the request is stored; the connector detail remains unresolved; staff will use the supplied contact route to continue the enquiry. The business must approve the actual follow-up arrangement. The content should not invent a response time to make the message feel more reassuring.

Include the unresolved detail in the customer-facing explanation

A generic thank-you is not always enough. In this fictional workflow, the message might say: “Recibimos tu solicitud. Falta confirmar la medida del conector antes de aceptar el pedido.” Its English counterpart could explain that the request was received and the connector measurement needs confirmation before order acceptance.

These are illustrative messages for a hypothetical process. Their usefulness depends on the system actually retaining the request and the team actually being able to identify that missing detail. If neither fact is established, the wording needs a different boundary.

Ask a reviewer to explain what they would do next. Would they wait for a question, assume stock had been reserved, or submit again? Their answer is stronger evidence than asking whether the translation sounds natural. A sentence can be fluent and still send someone toward the wrong action.

Review the whole chain of language

Start before the acknowledgement. A button saying “Confirm order” may already imply acceptance even if the following message carefully says “request received.” The catalogue may describe an item as available while the form says availability must be checked. A follow-up email may use a stronger state than the application.

Gather the specific text in one small review set: product condition, form instruction, submit action, receipt, request for missing information and staff response. Identify which pieces are shared across services and which depend on the item. A shared acknowledgement should not inherit a claim that is true for only one route.

Mark content embedded in scripts or provider-controlled templates as well as editable page text. That distinction helps the implementer find the actual source of a message; it does not require the customer to understand the architecture. The business reviewer needs to see the words in the sequence in which a person encounters them.

Do not translate an uncertain outcome into certainty

Now change the example. The request might have arrived, but the browser did not obtain a reliable receipt. Neither “We received it” nor “Nothing was sent” is established by that observation alone. The message should communicate the uncertainty and offer the agreed way to check the possible existing request.

Translate that recovery instruction with the same care as the success state. If one version says to contact staff and the other tells the person to submit again, the two journeys can create different operational risks. The form service covers the technical decisions behind this distinction.

Keep the meaning current after a process change

Assign an owner to the business rule and a reviewer to each language version. If the organisation later introduces automatic acceptance for a defined class of item, that is a process change with a content consequence. Update the relevant messages and retest the exception where automatic acceptance does not apply.

The W3C guidance on form notifications discusses clear feedback and understandable recovery instructions. Use it alongside the actual business events. A general writing rule cannot tell you which event your application has proved.

The completed review should leave a short record of the event, the text in each language and the action the reader understood. That record makes a future wording change easier to assess. Bilingual website development can include this complete journey rather than treating the homepage as the full translation scope.