In short
Russian procurement documents rarely use the phrase “video wall”. The term that appears in tender specifications is система отображения информации коллективного пользования — literally a collective-use information display system. The distinction is not cosmetic: the tender term names the whole system rather than the screens, and a bid written in the wrong vocabulary reads as an incomplete answer.
What the term covers
Four groups: the display surface (LCD panels or LED cabinets with mounting), the controller — which today usually means a server rather than a dedicated box, the control software with its operator roles and layouts, and the sources being displayed. A quote that prices only the first group answers a different question than the one the specification asked.
Writing the requirement
Specify capability, not a model: number of video outputs and their resolution, source types and counts, operator roles and audit requirements, operating system, and whether the deployment must run without outbound connectivity. Naming a vendor model ties the purchase to a single supplier and makes the justification harder to defend.
Ask the site and procurement teams to supply the applicable security and documentation requirements. Record these alongside the engineering specification and agree how the supplier will demonstrate each one during acceptance.
Turn an operating task into a measurable requirement
Describe what the group needs to see, not only what equipment it expects to buy. Name the operating modes: routine monitoring, shift handover, incident coordination and briefing. For each mode, identify the audience and the person who controls the display.
Build a source register with connection method, resolution, frame rate, access owner and expected availability. Mark which sources appear together. A catalogue of every possible source is useful, but it does not describe the simultaneous rendering workload.
Write a separate requirement for legibility. Select actual dashboard labels, map annotations and video details, then agree the viewing positions used for acceptance. A resolution written in the specification does not demonstrate that an operator can read the intended content.
Define responsibilities at the system boundary
List the customer-provided services: network access, source accounts, identity infrastructure, power and room access. Identify the team responsible for each one. Include the permissions needed to display a source without exposing administrative credentials to other operators.
Distinguish the shared visualisation layer from the system that owns the underlying process. Specify where commands are issued and which information is read-only on the wall. This keeps the acceptance plan tied to the actual role of the display system.
Record the required interfaces without assuming that every vendor implements them identically. Ask the supplier to demonstrate the formats, authentication method and source behaviour that the installation will use. Preserve a list of unresolved compatibility questions alongside the proposed configuration.
Compare offers using the same bill of materials
Separate displays, mounting, output connections, capture hardware, controller server, software and services. Ask bidders to state included quantities, assumptions and exclusions. A comparable offer should show how each requirement is met and which dependencies remain with the customer.
For software licensed per server, distinguish commercial limits from hardware capacity. Craft Wall has no licence caps on displays, sources, operators or canvases. The server still needs enough GPU resources and physical outputs for the agreed workload.
Write acceptance checks before installation
Describe a repeatable test for each important requirement. Include opening the intended sources, applying a prepared scene, changing a layout and using the agreed operator permissions. Assign an expected result and a responsible reviewer to every test.
Test the required maintenance and recovery scenarios with the implementation team. Record what the operators see when a source is unavailable, how the issue is escalated and what is checked before returning to normal operation.
Keep the accepted configuration, source register and operator instructions together at handover. Future changes should refer back to this record, so adding a dashboard or display does not silently change the workload or the agreed responsibility for support.