A modular kiosk uses an existing enclosure and approved module positions, while a fully customized kiosk may change structure, appearance, module layout and engineering. The correct route depends on workflow fit, evidence needs, quantity stage, change tolerance and project ownership.
This guide is for Distributors, software companies and project owners during customization strategy. A kiosk is an unattended transaction point, so the user flow, installed modules, site conditions, exception handling and service access have to be designed as one system.
Direct Answer
A sound decision begins with workflow fit and engineering change. It then reviews evidence, quantity and lifecycle, and ownership, tests the buyer's real workflow on a representative sample and freezes the accepted configuration before bulk release. Compare evidence, limitations and responsibility boundaries instead of counting features.
When to Use This Guide
Use this guide when a modular versus custom kiosk project requires an unattended workflow, kiosk form factor, module set, site condition and service plan to be approved together. It is not a substitute for payment certification, accessibility assessment, outdoor rating evidence, site engineering or approval by the local responsible authority.
Use the resulting modular versus custom kiosk decisions to prepare an RFQ, sample test, pilot gate or supplier clarification. If the project has already fixed a different configuration, apply the workflow fit and engineering change checks as a gap review and record every deviation before deciding whether a retest is needed.
Key Decision Points
Decision 1: Workflow fit
What to confirm: Determine whether an existing platform supports the required screen, modules and service path.
Risk if unclear: Forcing a poor workflow into a standard enclosure can create long-term service problems.
Decision 2: Engineering change
What to confirm: List exact structural, electrical, cosmetic and software changes.
Risk if unclear: The word custom can hide very different effort and approval needs.
Decision 3: Evidence
What to confirm: Define drawings, prototype, tests and approvals required after changes.
Risk if unclear: A modified enclosure may invalidate earlier fit or environmental assumptions.
Decision 4: Quantity and lifecycle
What to confirm: Discuss pilot, volume, tooling and future component changes.
Risk if unclear: A full custom design is difficult to justify or maintain without a clear lifecycle.
Decision 5: Ownership
What to confirm: Assign design files, tooling, certification, software and change approval.
Risk if unclear: Unclear ownership creates delays and reuse disputes.
Requirements, Evidence and Tradeoffs
Workflow fit
Determine whether an existing platform supports the required screen, modules and service path. Forcing a poor workflow into a standard enclosure can create long-term service problems.
Engineering change
List exact structural, electrical, cosmetic and software changes. The word custom can hide very different effort and approval needs.
Evidence
Define drawings, prototype, tests and approvals required after changes. A modified enclosure may invalidate earlier fit or environmental assumptions.
Quantity and lifecycle
Discuss pilot, volume, tooling and future component changes. A full custom design is difficult to justify or maintain without a clear lifecycle.
Ownership
Assign design files, tooling, certification, software and change approval. Unclear ownership creates delays and reuse disputes.
Evaluation and Approval Process
1. Freeze the user workflow.
Create a one page requirement record and include workflow fit as an explicit field. Determine whether an existing platform supports the required screen, modules and service path.
2. Test fit against current platforms.
Attach the exact model, revision and source used to verify engineering change. List exact structural, electrical, cosmetic and software changes.
3. List unavoidable changes.
Run a focused test for evidence and retain the input, expected result and observed result. Define drawings, prototype, tests and approvals required after changes.
4. Choose modular or engineered route.
Resolve the boundary around quantity and lifecycle with the responsible supplier or internal team. Discuss pilot, volume, tooling and future component changes.
5. Approve prototype and evidence plan.
List every deviation affecting ownership and decide whether correction or retest is required. Assign design files, tooling, certification, software and change approval.
6. Control changes through pilot and bulk.
Freeze the accepted wording for workflow fit in the quotation, approval and bulk inspection record. Determine whether an existing platform supports the required screen, modules and service path.
The final approval record should connect workflow fit, engineering change, evidence, quantity and lifecycle and ownership to the tested configuration and date. It should also name the responsible party, exceptions and change triggers so quotation review and bulk inspection use the same baseline.
Applying This Guide to an AONPOS Enquiry
AONPOS identifies Self Service and Payment Kiosk as one of its two core product lines. Project suitability must still be reviewed for the exact enclosure, computing configuration, installed modules, payment terminal responsibility, site conditions and service access.
Treat every peripheral and module as model specific. Confirm whether it is included, optional or supplied by another party, then record its mounting, interface, software owner and acceptance test before approving a sample.
Common Procurement and Integration Errors
1. Calling color or logo change full ODM. Forcing a poor workflow into a standard enclosure can create long-term service problems. Correct it by requiring the team to determine whether an existing platform supports the required screen, modules and service path.
2. Assuming modular means every module fits. The word custom can hide very different effort and approval needs. Correct it by requiring the team to list exact structural, electrical, cosmetic and software changes.
3. Starting enclosure design before module selection. A modified enclosure may invalidate earlier fit or environmental assumptions. Correct it by requiring the team to define drawings, prototype, tests and approvals required after changes.
4. Ignoring certification impact. A full custom design is difficult to justify or maintain without a clear lifecycle. Correct it by requiring the team to discuss pilot, volume, tooling and future component changes.
5. Promising lead time before engineering review. Unclear ownership creates delays and reuse disputes. Correct it by requiring the team to assign design files, tooling, certification, software and change approval.
Buyer Checklist Before Approval
1. Workflow fit: Determine whether an existing platform supports the required screen, modules and service path.
2. Engineering change: List exact structural, electrical, cosmetic and software changes.
3. Evidence: Define drawings, prototype, tests and approvals required after changes.
4. Quantity and lifecycle: Discuss pilot, volume, tooling and future component changes.
5. Ownership: Assign design files, tooling, certification, software and change approval.
Frequently Asked Questions
Which requirement should be confirmed first?
Determine whether an existing platform supports the required screen, modules and service path. This should be agreed before model selection because forcing a poor workflow into a standard enclosure can create long-term service problems.
What evidence is needed for engineering change?
List exact structural, electrical, cosmetic and software changes. Record the exact model, installed option, software or driver condition and observed result. The word custom can hide very different effort and approval needs.
What should the representative sample test cover?
The sample should verify evidence, quantity and lifecycle and ownership as well as the buyer's complete workflow. Save the inputs, expected result, observed result, configuration and test date so the quotation and bulk units can be checked against the same baseline.
When is a focused retest necessary?
Review and retest the affected functions when a change to workflow fit, engineering change, evidence or quantity and lifecycle can alter the approved result. The change record should identify what changed, which previous evidence remains valid and which test must be repeated.
Request a Model Specific Review
Share the kiosk workflow, enclosure format, required modules, payment responsibility, software environment, site conditions and sample criteria with AONPOS. Request a model specific review before project approval.
Related AONPOS Resources
1. Payment Kiosk Collection: https://aon-postech.com/collections/payment-kiosk
2. Payment Kiosk FAQ: https://aon-postech.com/pages/payment-kiosk-faq
3. Payment Kiosk Knowledge: https://aon-postech.com/blogs/knowledge-for-payment-kiosk
4. Request a Demo or Configuration Review: https://aon-postech.com/pages/get-demo