Questions before changing a website or order process

Can we start with a fault in an existing application?

Yes, a reproducible problem can be a useful starting point. The investigation needs enough context to distinguish the symptom from its cause. A missing notification might involve delivery, permission or application logic. An assessment can identify what is established and what remains uncertain before a repair is proposed. See software repair.

Does a product catalogue need to take payment?

That depends on how the business sells. A catalogue can help someone identify a product and submit a precise enquiry while staff confirm availability or specifications. Adding payment changes the provider, account and operational requirements. It should be a separately defined decision, not an assumed part of putting product information online.

Can you guarantee access to a particular provider?

No. The actual parties, intended use, account conditions and relevant restrictions need review. The provider and qualified responsible parties establish the applicable arrangements. Technical development can investigate a supported interface after those dependencies are understood; it cannot substitute for approval or guarantee ongoing availability.

Why distinguish an enquiry from an accepted order?

The customer needs to know what the business has committed to. Receiving requested items is one event; agreeing quantity, availability and conditions may be another. The interface should reflect the business's actual decision and show what information or review remains. The order request service develops that distinction into a workflow.

Will Spanish pages mean the project is delivered in Spanish?

Project discussions and technical delivery are in English unless separate support is agreed. For Spanish public content, the project must identify a reviewer for terminology and commercial meaning. A translated page should lead to a useful next step and state when a linked detail is available only in English.

Can the application save everything automatically?

Persistence is a design decision. A device may be shared, information may become stale and a saved draft may never have reached staff. We agree what can be retained, where, for how long and how the person recognises its status. A draft on a device must not be presented as an accepted request.

How do we know the change is finished?

The scope identifies demonstrable outcomes and the responsible reviewer. A relevant error or interruption is included alongside the normal task. An operator might need to continue an existing request after a colleague leaves; the review checks the information available at that point rather than only whether a screen loads.

Is ongoing support included?

Only as stated in the agreement. Updates, incident investigation, provider changes and new features have different responsibilities. The support page explains how to define them. Start with one task and its current obstacle, and the appropriate first engagement can be discussed.