Standard Options & Custom Self-Service Projects

Identify the operating task and the closest documented equipment route before discussing customisation. Ask which cabinet, payment, language or other options already belong to a specific model. A standard option should have a clear configuration reference and supporting documentation.

Keep unverified requests separate from that list. Changing the name or appearance of a cabinet does not establish compatibility with a new product, process or installation environment.

A change to dimensions, compartments or a mounting arrangement needs a defined drawing and a review of its effect on operation and service access. Integration needs a different scope: the systems involved, interfaces, permissions, data exchanged and the parties responsible for testing.

Specify the desired result without assuming that an existing machine supports it. A network port, badge reader or touchscreen is not evidence of compatibility with a particular business system.

A new operating process may require design work, samples, prototypes and a separate acceptance plan. Identify the essential requirements, the evidence already available and the uncertainties that would need to be resolved before commercial commitment.

Submitting a custom brief does not mean development has been accepted. Ask any proposal to identify deliverables, exclusions, responsibilities, ownership, ongoing support and the treatment of changes to the agreed scope.

Provide the country, site, user sequence, products or materials, quantity plan and purchasing window. Classify each requirement as a standard option, physical change, integration or unresolved development question. Include the local operating and maintenance responsibilities.

Request a written response that identifies what is confirmed, what needs testing and what is outside the proposed scope. Keep equipment, implementation, software, consumables and support costs separate when comparing alternatives.