Distinguish the physical format from playback behaviour
Two visible screens do not establish how many independent content outputs the system provides. A dual-screen product can be configured in different ways, and the buyer should describe the required result. Mirrored content repeats the same image on both faces. Independent content allows each face to serve a different audience or message. Another requirement may involve coordinated timing between different files. Explain the use case in the enquiry and ask the supplier to identify the proposed architecture rather than inferring capability from a photograph of the cabinet.
Define a separate canvas for each audience
Record orientation, resolution and the critical message for each output. In a storefront, one side may need a short promotion while the other explains product choices. At a shared interior location, separate screens may present related information to people approaching from different directions. Prepare representative content for both canvases before approving the player. Check text rotation and scaling, especially if the physical installation is portrait. A campaign exported for a single landscape screen may not be suitable merely because it can be made to fit.
Ask how outputs are controlled and updated
Identify whether one controller or multiple players drive the screens, how they are named in the management platform and what licences are needed. Ask whether schedules can be applied independently and how a content update reaches the correct face. If coordinated playback matters, define the acceptable timing behaviour and test it with the intended files. Do not assume independent playback implies precise synchronisation. Keep network requirements and platform ownership explicit, so a dual-screen cabinet does not introduce an unexpected second software subscription or support responsibility after purchase.
Test interruptions on each side
During sample review, update one face while observing the other. Restart the system and check that the correct content returns to each output. Disconnect the network and inspect the fallback behaviour. Where separate players are used, record how a fault on one side appears to the operator. Include any automatic power schedule and time zone requirements. These practical tests reveal configuration errors that may not appear during a short demonstration. Retain the files, settings and software versions that produced the approved result.
Handover a clear screen naming system
Label the outputs with audience-based names such as street-facing and store-facing, rather than ambiguous numbers alone. Put the same names in the content folders, management platform and operator guide. Give staff a safe test asset that identifies each face during troubleshooting. Ask RSXD to confirm the exact controller and management options included in the quotation. The agreed scope should state whether the system provides mirrored, independent or coordinated content, plus any limitations. A clear architecture and naming convention make later campaign changes much less dependent on installer memory.
A practical record to keep
Prepare a two-output content schedule that identifies file, audience, start time and intended relationship to the other face. Use it during demonstration and commissioning. If the requirement changes from mirrored playback to two independent campaigns, treat that as a configuration review rather than assuming the original controller and licence scope remain sufficient.
Common questions
Is independent content the same as synchronised content?
No. Independent outputs can show different files, while synchronisation concerns timing between outputs. Specify and verify each requirement separately.
How can operators avoid publishing to the wrong face?
Use clear audience-based device names, labelled content folders and a simple identification test. Include those names in commissioning and staff instructions.
Further product information
This article is a project planning guide. Available features and performance depend on the exact quoted configuration. Confirm model details, site requirements and integration scope with RSXD.