FAQs

Start with what needs to happen, the location, approximate quantities and your preferred timing. Equipment names, the symptoms of a problem and an onsite contact are useful when available. Estimates are fine; mark anything that still needs checking.

Yes. Add multiple requests to one project, including several jobs for the same service. Each request can have its own answers, assigned locations and timing. You can duplicate a request for similar work, edit it or remove it before submitting once. For example, new cameras may also need cabling and network changes. Keep the shared location, timing and contact details together so the connections between tasks can be reviewed.

No. Say whether equipment is already available, selected for purchase or still undecided. If you need recommendations, describe the result you want and any existing systems it must work with. Model details help assess compatibility, but you can begin without a complete equipment list.

Yes, coordinated work with an internal IT team, MSP or technology vendor can be discussed. Identify who owns configuration, access, approvals and testing. For example, your provider might guide a physical replacement remotely and confirm service afterward. Responsibilities and communication are agreed as part of the scope.

Multi-location work can be planned as one project. Share the site list, quantities, differences between sites and preferred rollout order. New York is the primary focus; East Coast and nationwide projects are reviewed against location, timing, requirements and available resources before dispatch is agreed.

A request provides a starting brief for reviewing the work, open questions and possible next steps. It does not confirm a booking, price or response window. When email delivery is enabled, the confirmation includes your reference and a private download of the service intake PDF. A confirmation email with the same PDF is sent when that option is enabled. If the page is in preview mode, it does not send a request. Scheduling and responsibilities need to be agreed before work begins.

Support hours, response expectations, maintenance windows and escalation arrangements are defined for the engagement. The public website does not activate support coverage or promise emergency dispatch. State any operating hours or deadlines that matter, such as a store opening or an evening change window, so availability can be reviewed.

Describe the work, quantities, locations, equipment readiness and access constraints so the scope can be reviewed. Parts, travel, specialist work, repeat visits, software subscriptions and licensing requirements may need separate consideration. Pricing and any warranty or support terms must be confirmed for the proposed work; a website selection is not a fixed-price offer.

Name the person who can admit the engineer and identify restricted rooms, escorts, parking or loading rules, working heights and permitted work hours. Include dependencies such as a furniture move or equipment delivery. For example, "the manager opens the cabinet after closing; IT joins at 6 p.m." describes the arrangements. If they are pending, say who will confirm them.

Agree how the result will be checked and who can accept it. Depending on the work, that might include functional tests, asset details, cable labels, permitted photographs, completion notes or an unresolved-issues list. Say whether a customer, local manager, remote engineer or vendor signs off. If you do not have a checklist, explain what must be working when the visit ends.

Keep the public project brief to the equipment, symptoms, locations and coordination needed to scope the work. Do not include passwords, access codes, payment-card details or private customer files. You can describe an error without copying sensitive contents. Identify the authorized account owner instead; any access method and permissions should be arranged for the agreed work.

Physical disconnection, inventory and collection are different tasks from backups, data migration or sanitization. Identify who authorizes shutdown, confirms required data work and receives each device or data-bearing part. For example, IT may retain all drives while a courier collects labeled chassis. Do not assume a refresh or removal includes data recovery, erasure or recycling; specify those requirements for review.

Existing clients and technicians can use the established NetComFIX portal for their existing account access. A public project request does not require a portal account. For a new field-engineer relationship, use the Field Team information and prepare your experience, locations and capabilities; assignment availability and any application process need to be confirmed separately.

Choose the closest outcome and describe what you see. Cabling covers physical network connections; network work concerns the equipment and connectivity using them. Onsite support covers a defined visit, remote support covers work that can be carried out with authorized remote access, and managed IT concerns an ongoing support arrangement. You can add related services when several parts of the project need attention.

Describe the improvement you want, approximate users, devices and sites, and the systems your business relies on. State which parts of IT should be in scope and whether you are considering ongoing cover or still comparing arrangements. For example, staff devices and email may need support while a software vendor keeps ownership of a booking platform. Estimates and an outline of priorities are enough to begin.

Name the current support arrangement and describe what that team should continue handling. Separate policy decisions, change approvals, vendor escalation and everyday support. For example, an internal IT lead might approve changes while a partner handles agreed maintenance. If responsibilities are undecided, describe the current process and gaps you want to close; a request does not automatically transfer ownership.

Describe the repeated symptom, timing and business impact, and the devices, services or providers involved. Summarize what earlier checks established and what only helps temporarily. "Ten users lose file access most mornings; reconnecting restores it" gives a useful pattern. Say whether you want a focused investigation, ongoing support or help deciding. An unknown cause is expected; the history helps avoid starting from assumptions.

Identify where your team needs capacity, the number of users or sites and the tools already used. List work to delegate alongside responsibilities your team or vendors will retain. For example, you may need routine ticket assistance during a migration while internal IT keeps security policy and software deployment. If the split is not final, describe the pressure points so a workable division can be discussed.

Describe the route a request follows, who approves changes and when it moves to another team or vendor. Include the ticket system and information needed at handoff. For example, a shared queue may track work while application incidents go to the software vendor. If the process is informal today, say who currently makes those decisions so ownership and communication can be agreed.

Explain the result you want, systems and device counts in scope, relevant platforms or vendors, and how maintenance happens today. Say whether you need a plan, delivery of agreed work or an ongoing arrangement. Include approval steps and periods that changes must avoid. If no schedule exists, start with the operational problem, such as aging-device failures, and the owner who can approve a plan.

Name the affected equipment, approximate count, visible symptoms and work being interrupted. Note when it began and what has already been checked or changed. "Two reception PCs cannot print after a desk move, but the printer powers on" helps define a visit more clearly than a suspected diagnosis. If the model or cause is unknown, the device type and observable behavior are enough to start.

Local hands means defined physical work at a site while your IT team or vendor supplies direction where needed. Describe the devices, approved tasks, readiness of instructions and how remote guidance or change approval will work. For example, an engineer may check indicators and trace labeled connections while your network team joins a call. Specify the checks or photographs to return; if instructions are incomplete, identify the decisions still needed.

List what is being installed or replaced, quantities and models, and whether hardware is onsite, ordered or still undecided. Separate physical setup from software and account configuration by naming the responsible team. For example, "two laptops and docks; IT supplies the approved build" defines that boundary. If equipment selection or configuration ownership is open, make it part of the scope discussion.

Identify who preserves files, handles accounts and approves the old equipment for removal. State whether the engineer should label and leave devices onsite or hand them to a named recipient. "IT confirms the data is preserved; leave labeled PCs in the locked office" is a useful instruction. If responsibility is unclear, flag it before a swap; physical replacement does not itself define data-handling work.

Count the desks and devices and distinguish disconnection, movement and reconnection tasks. State whether the destination layout, furniture, power and network outlets are ready, and which team finishes each dependency. Define checks such as network access, monitors, printing or a test call. If the layout is still being decided, describe the intended workspace and timing so final positions can be confirmed before setup.

Explain how the engineer reaches the equipment and what must remain operating during the visit. Include escorts, locked cabinets, handling restrictions and authorization before equipment is powered down. For example, one reception station may need to stay available while the other is replaced. If access has not been arranged, identify the coordinator and outstanding approval so the appointment can account for it.

Describe the task at each site, total locations and equipment counts, then separate repeatable work from site variations. Differences in mounts, cabinets, opening hours or device quantities can change visit requirements. For example, "20 branches, one switch each; four branches have restricted access" gives both scale and exceptions. A provisional site list is useful if final locations are still being confirmed.

State whether equipment is selected, configured, available and assigned to sites. Name the configuration owner and describe delivery dates, rollout order and remote support windows. A pilot followed by regional waves is one possible plan. If models or delivery dates are open, label them as dependencies so a visit is not planned around equipment or guidance that is not ready.

Describe the physical work to delegate, expected sites or visit volume and whether the need is a project, recurring support or still being scoped. Explain how your team provides instructions, remote guidance, approvals and escalations. For example, your service desk may own configuration while a field engineer performs approved replacements. If the operating process is not ready, identify who will define it before dispatch.

Provide the approved task list, tests, acceptance criteria and reporting destination. Specify which asset details, ticket updates, permitted photographs or signed completion notes are required, including who accepts the result. "Record serial numbers and confirm connectivity with the remote engineer" is actionable. If no closeout format exists, describe the information your project team needs to decide a site is complete.

Start with the decision the survey must support, such as confirming installation readiness or comparing effort across branches. Give the site count and types, known differences, access arrangements and required measurements or report template. A survey for cabinet space differs from one for outlet locations. If the deployment is undecided, explain the choices the survey should resolve rather than asking for an undefined general inspection.

State what the pilot must prove, the representative sites involved and the possible scale afterward. Define successful tests, evidence and who decides whether the next stage proceeds. Include vendor availability, escorts, downtime and recovery dependencies. For example, a pilot may measure installation time and verify an approved workflow at two different store types. If pass criteria are not ready, identifying the decision owner is the first useful step.

Give the number of stores and checkout stations, the POS provider and selected terminal models if known. List receipt printers, scanners, drawers, displays and network connections, then describe equipment delivery and counter, power and network readiness. This reveals what needs physical setup and what depends on other work. If the provider or equipment is undecided, describe the checkout requirements and flag the selection for review.

Identify the authorized POS or payment provider and the person responsible for configuration, account access and activation. Onsite equipment work needs coordination with those responsibilities; it does not automatically include them. For example, a provider may join a scheduled call after terminals are connected. If that contact or process is unknown, mark it as a dependency. Do not include payment-card details, passwords or activation secrets in the brief.

Describe what is being replaced, the intended improvement, models and station counts, and whether replacements are ready. Explain how sales should continue during the change and what provider-approved tests and store sign-off are needed afterward. For example, one station may remain open while another is swapped. If a work window or validation plan is undecided, identify the store and provider contacts who can agree it.

Name the provider, terminal and affected peripheral if known. Describe the error or behavior, how many stations or stores are affected, whether sales can continue and what changed or was checked. A printer that stops responding and a terminal that loses network access need different investigation. If you do not know where the fault lies, report what works and what fails rather than selecting a cause.

State whether the provider has investigated, summarize its findings and include a non-sensitive case reference or approved physical checks. This helps coordinate field work with software and payment responsibilities and avoid repeating completed steps. "Provider asks for a cable check at terminal two" is useful. If no investigation has happened, say so; do not invent a diagnosis or include customer payment information.

List stores and station counts, selected provider and equipment standards, and any differences between store types. Describe equipment and instruction readiness, rollout order, trading constraints, tests and sign-off records. Identify stores awaiting equipment or preparation. For example, a pilot store can reveal issues before regional waves. If readiness is mixed, mark the exceptions so scheduling and acceptance can be reviewed site by site.

Describe the rooms, floors and users affected, the work that fails and when it happens. Note frequency and duration, and whether wired devices or nearby Wi-Fi areas still work. "Calls drop in the back offices at busy times, while wired desks stay online" is more useful than "bad internet." A rough layout helps frame the investigation. Unknown size or timing can be marked for checking.

Say whether interruptions affect wired connections, Wi-Fi, internet access or several of these. Include the router, switch, access point or internet provider if known, recent changes and checks already performed. Identify someone who can observe the issue and an authorized IT contact for equipment access. You do not need to identify the cause; describe what disconnects and what remains available.

Explain whether you are opening, moving or expanding a space, then list approximate users and connected equipment by area. Include phones, cameras, printers, guest access and other systems alongside staff computers. State what existing equipment or provider design should be reused. If no design is chosen, explain the intended use and rooms so requirements can be discussed before hardware is selected.

Describe the status of network outlets, cabinet space, power and internet service, including work still owned by another supplier. For example, "cabling is complete, cabinet power is pending and the internet appointment is next week" makes the dependencies clear. If readiness has not been checked, say so; equipment delivery alone does not mean the location is ready for a working network.

Describe the reason for replacement, the existing device models and counts, and whether replacements are available, chosen or need review. List dependent services such as phones, cameras, guest access and staff connectivity so the impact is visible. If the replacement model is undecided, explain the current limitation or failure rather than choosing a device solely by its port count.

Identify who prepares or approves configuration and who can verify the result. State the permitted work window and acceptable interruption, including services that must remain available. For example, your network provider might prepare the replacement and join a weekend cutover. If no owner or window is confirmed, mark those as planning gaps; validation and recovery responsibilities also need agreement.

List what each connection will serve, the approximate quantity and the destination at each end. For example, two outlets at six desks might return to the cabinet in the storeroom; ceiling access points may need separate runs. Counts and locations help define the physical work and cabinet requirements. If positions are undecided, provide the intended rooms and mark the final positions for review.

An occupied office, open renovation and finished home can offer very different cable access. Describe known conduit, cable trays, ceiling access, outdoor sections and closed walls, without assuming hidden routes are usable. For example, "accessible ceiling to the hallway, finished wall at the final outlet" identifies a point to inspect. If routes are unknown, a site review may be needed before installation effort can be confirmed.

Power over Ethernet, or PoE, delivers power and data over compatible Ethernet cabling to supported devices. A camera or access point may instead use a separate power supply. State the device model and known switch or injector so power compatibility and available capacity can be reviewed. If you only know that the device has a network cable, choose "not sure"; that alone does not confirm a suitable PoE supply.

Technical reference: Cisco: Power over Ethernet (opens in a new tab)

Share any approved cable specification, floor plan, port map or naming scheme. Say what evidence is required at handover: identified endpoints, connection checks or a particular test report. A working link check and formal cable certification are different requirements, so specify any required test standard or deliverable for review. If no plan exists, describe the desired outlet names and how the connections will be used.

Describe the number of cabinets and approximate connections, then explain what is difficult to manage: unidentified ports, tangled patch leads or obstructed equipment. State whether the work involves tracing, relabeling, repatching or an undecided mix. Identify which services must stay live and when an interruption can be approved. If you have no reliable port map, flag that before any cables are moved.

Identify the affected outlets or devices and describe both ends of the connection when known. Note whether the fault is constant or intermittent, what changed nearby and any patch-lead or device swaps already tried. For example, "three desks stopped connecting after a furniture move; other outlets work" gives a starting point. These details help plan testing but do not establish that the installed cable is the cause.

Both ends of a run may need access, along with the route or cabinet involved. Mention locked rooms, occupied desks, ceiling heights, escorts and permitted working hours. Identify who can authorize unplugging or changing a live connection. If access or interruption is not approved yet, name the person arranging it; a reachable desk outlet alone may not be enough to complete the intended checks.

List device types, quantities and accessories, then state where and how they will be prepared. Describe any approved build, checks, labeling, updates or packing instructions needed before handover. "Fifteen laptops with docks; central IT prepares the build" separates preparation from desk setup. For refresh or removal work, identify the older devices as well. If staging is undecided, name the preparation tasks that still need an owner.

Name the team responsible for software preparation, accounts, user assignments, backups and any data migration or removal. These are separate from physical unpacking, installation and inventory. For example, central IT may supply prepared devices and confirm data work before old equipment leaves a desk. If an owner is not appointed, record that as a planning gap rather than assuming data handling is included.

State whether replacement devices are available, selected or still need review. Describe how swaps should fit around users and business hours, and what should happen to old equipment. For example, five desks may be refreshed each evening with labeled old devices held for IT. If the replacement or retirement plan is uncertain, explain the intended outcome so the schedule can account for outstanding decisions.

Give device quantities by location, the preparation and delivery plan, receiving contacts and site access arrangements. State rollout order and when staff and remote IT can help, whether this is one office or a wider deployment. For example, a pilot office may precede two sites per week. If shipping or staffing is not confirmed, note the dependency so installation dates can be reviewed realistically.

Specify required asset fields, labels, user or site assignments and the person receiving the devices. Include collection or desk-handover arrangements and the records the receiving team needs. For example, a list may match existing asset labels to users and locations, with condition recorded for retired devices. If there is no inventory template, describe how your team will use the list so a suitable format can be agreed.

Confirm who can authorize shutdown and removal, and where each device should go: retained onsite, transferred to your IT team or handed to an agreed collection service. Identify outstanding backup or data-handling decisions before removal. For example, IT may retain drives and sign an inventory before courier pickup. If approval or destination is unknown, flag it; physical disconnection does not establish an erasure or disposal process.

Describe the physical observations or approved tasks needed, whether written instructions are ready and how the remote engineer will guide the visit. Specify evidence such as indicator status, display messages, permitted photos or a completed checklist. If instructions are not yet approved, identify the owner and open decisions. Physical checks, rack work and component replacement each need an agreed sequence and authorization before equipment is disturbed.

Give equipment types, quantities, models and facility or rack identifiers where appropriate. For installation or removal, include known rack space, dimensions, weight, rail kits, power and handling requirements. "Two rack servers; rails supplied and rack space assigned" identifies part of the preparation. If dimensions or readiness are unknown, mark them for confirmation; availability of the device alone does not establish that it can be safely fitted or removed.

Describe the physical change, distinguishing tracing or patching connections from installing or removing equipment. For connection work, give cable types, approximate counts and the status of approved port maps or labels. State which links must remain live and when changes are allowed. If labels or maps are uncertain, request identification before changes. "Trace six copper leads now; repatch only in the approved window" sets a clear boundary.

Identify the engineer who approves the physical task, handles shutdown and configuration, and verifies the result. Separate those duties from any data-related work. For example, a remote engineer may prepare a server for removal and confirm service after an approved component swap. If responsibility is not assigned, mark the gap before scheduling; an onsite person needs clear instructions about what may be touched or changed.

Name the device, component, reason for replacement and the status of the approved replacement part. Identify who provides the procedure and what happens to the removed part, especially if it holds data. For example, your IT team may retain drives while a vendor supplies return instructions for a power supply. If part suitability is unconfirmed, say so; the model and approved procedure need review before replacement.

State booking requirements, escorts, maintenance windows, permitted materials and any delivery or collection arrangements. Explain who admits the engineer, receives equipment and signs off the handover. "Escort booked for the service window; courier collection follows IT approval" identifies dependencies. If facility permission or timing is pending, name the coordinator; a remote support contact does not by itself provide physical access.

Identify the device type, model and count if known. Describe what happens and when it fails: no power, a blank display, startup failure or trouble once in use. Include work affected, recent changes and checks already attempted. "The power light turns on but the screen stays blank after an update" is useful without a diagnosis. If the failure stage is unclear, describe the last thing you can observe.

Files or specialist settings may exist only on the affected device, so identify what needs preserving and who manages backups or migration. You do not need to include the files themselves. For example, mention locally stored invoicing data or a specialist application configuration. If backup status is unknown, say that before work begins; diagnostics, repair and replacement do not automatically include data recovery or transfer.

Identify the device and connection type, such as USB, wired network or Wi-Fi. Describe errors or indicators, the users and tasks affected, what still works and any changes or checks already tried. For shared devices, say whether another computer can still use them. "Printing works from one PC, but scanning fails for four staff" gives a useful distinction. Unknown connection types can be marked for checking.

Record the affected equipment, symptom, frequency, duration and what restores operation. Include possible triggers such as waking from sleep, a video call or cable movement, along with earlier repairs and their results. Explain what work is interrupted. If no pattern is clear, describe the latest occurrence and distinguish observations from guesses. A temporary recovery is useful evidence but does not show that the underlying issue is resolved.

Describe the equipment, current faults, diagnosis already attempted and the work it must support. Include approximate age and known warranty or support coverage, marking unknown details honestly. Say what you need to decide: understanding the fault, assessing repair options or planning replacement. For example, recurring delays on an invoicing computer may warrant an assessment. Any repair price, part availability or warranty position needs confirmation for that device.

Give the device, operating system and application if known, what happens instead of the expected result, and the effect on your work. Include when it started and what has already been tried. "The reporting app closes when opening a document after an update" is useful without a diagnosis. If versions or model names are unavailable, describe the device and visible behavior; avoid including private file contents.

Say whether an authorized person can use the affected device, access the internet and reproduce the issue during an arranged session. Explain company approval steps or remote-access restrictions. For example, internal IT may need to authorize support before a staff member joins. If the device cannot connect or no one can attend, state that so the suitability of remote help and any alternative can be reviewed.

Identify the service, provider or device involved, the visible error and how many people are affected. State what still works, recent changes and checks already tried. "Three staff cannot print labels, but one wired computer can" helps separate the scope from a general outage. If you cannot compare devices, say so. Provide error wording without passwords, private message contents or other sensitive data.

Explain the desired result, device and application versions if known, what is already installed and who owns the setup requirements. Name existing settings or connections that must keep working and how the change will be checked. For example, add an approved shared printer while preserving current email access. If licensing, accounts or approval are not ready, identify them as dependencies rather than assuming configuration can proceed.

Include a ticket reference if available, the device or application, the teams involved and the work already completed. Separate what has improved from what remains wrong and describe the current business impact. For example, the original error may be gone while the app still freezes during a report. Without a ticket number, a short account of the earlier work and current symptoms is still useful.

Describe the property and the areas you want to see, then give a rough camera count if you have one. An entrance, stockroom and outdoor loading area can have different viewing and mounting needs. Explain priorities such as useful night images, local recording or phone access so equipment and installation can be considered together. "A shop with two entrances; help deciding the camera count" is a useful start.

State whether the cameras are owned, chosen or still to be selected. Include the camera brand and model, recorder model and viewing app when known; a brand alone may cover several product families. For an existing system, identify what should be retained. If you cannot find a model, describe the equipment and mark it unknown rather than assuming that any new camera will work.

An NVR is a network video recorder, typically used with network cameras. A DVR is a digital video recorder, commonly used with analog camera connections; some recorders support mixed systems. Cloud recording stores video through a compatible online service. These labels do not establish compatibility on their own. Tell us whether you want to keep the current recorder, compare options or change viewing as well. Exact models, storage needs, connectivity and any subscription requirements need review.

Retention means how long recordings should remain available. State the desired period and whether you need a local monitor, phone or computer access. For example, "phone and office monitor, with about 30 days of recordings" describes an aim, not a guaranteed storage result. Camera count, recording schedule, video settings and available storage affect what is practical. If the retention period is undecided, explain when you expect to review footage.

Technical reference: Axis: Video bitrate and storage (opens in a new tab)

Separate the cameras being added from those being replaced, and identify each area. Explain why replacement is needed: a failed image, poor night view or a changed scene can lead to different work. For example, "replace two driveway cameras and add one stockroom view" gives a useful scope. If the cause of a failure is unknown, report the symptom rather than deciding the camera itself must be replaced.

Describe existing cable routes, power, mounting points and access restrictions. Reusing a cable or mount depends on its condition and compatibility with the proposed equipment, so "existing, needs checking" is a valid answer. Mention outdoor locations, high mounting positions and finished walls. This helps distinguish a straightforward fit from work that also needs new cabling, mounting preparation or site approval.

Separate live-view problems from missing recordings or playback failures. Note how many cameras are affected, which viewing devices still work and when the issue began. "Two of eight cameras lose video overnight, but the local monitor shows the others" narrows the investigation. List relevant changes and checks already completed without repeating disruptive tests. If no other monitor or device is available, say that; it is a useful limitation, not a missing diagnosis.

List the phones or computers, the viewing app and whether viewing is needed at the property, away from it or both. Say whether this is a first setup or something that previously worked. A new phone, account change or replacement router is useful context. Remote viewing depends on the system and its approved access method, so compatibility and account ownership need checking. Do not include passwords or assume that opening router ports is required.

Identify someone authorized to reach the recorder, cameras where safely accessible, and relevant viewing devices. An IT or camera provider may also need to join for account or network changes. For example, a manager can provide property access while the provider approves configuration. If no one can attend yet, say that an appointment or access contact must be arranged so the work can be scoped realistically.

List the lights, thermostat, doorbell or other devices and approximate quantities, whether you already own them and what you want them to do. Include models when known, especially when connecting existing products. "Four lights controlled together and doorbell alerts on my phone" describes a useful outcome. If you have not chosen devices, describe the rooms and actions first so compatibility can be considered before purchase.

Name the app, voice assistant, hub or bridge you use or want to keep, along with the home network involved. Devices that work in their own apps do not necessarily support every shared platform or routine. For example, lights may use a dedicated bridge while a doorbell uses Wi-Fi. If you do not know the hub or model, describe how you control the devices now and mark compatibility for review.

Say whether devices are physically installed and powered or whether installation is still required. Mention room access, high fixtures, apartment or property approvals, and when someone can check devices and the hub. This separates app setup from physical work and helps review any specialist requirements. If power or mounting is uncertain, describe the current state; do not treat a configuration request as approval for electrical changes.

Describe which devices work independently, which are already linked and which are offline. Summarize pairing attempts and what happened, such as a hub finding lights but not blinds. Physical-button control and app control are useful separate observations. If the devices have never been connected together, say that; the next step is to review the existing models and platform rather than assume a fault or universal compatibility.

Describe what should happen, what starts it, participating devices and the app or hub that should run it. Include exceptions such as weekends, guests or manual override, and whether each device works on its own. "Dim living-room lights at sunset except when guest mode is on" defines behavior. If a device already fails individually, describe that separately so a routine is not built around an unresolved device issue.

Identify the devices, rooms and apps affected, frequency and what still works. Note when the problem began and changes such as a router replacement, update or edited routine. "Kitchen lights stop responding each evening, but their switches work" is a useful observation. If the pattern is unknown, give the most recent example and distinguish the intended routine from the actual result without guessing the cause.

List display quantities, approximate sizes and locations, and what supplies the picture: a player, app, computer or TV source. State what equipment is owned or selected, including mounts and players where relevant. Describe priorities such as readable menus, daylight visibility or easier content updates. If the choice is open, provide the viewing distance and intended use; these help frame equipment review and installation work.

Describe mounting readiness, known wall or support details, power and signal or network connections, and access to screens and content systems. Include high positions, finished walls, trading hours and the person who can authorize testing. "Mounts are present; cable route behind the counter needs checking" identifies a useful dependency. If readiness is uncertain, flag the items to inspect rather than assuming existing mounts suit new screens.

Give room counts and seating capacity, the tasks people need to perform, and meeting apps and laptop types. Describe how users should connect and any existing screens, audio equipment, cables, room echo or layout constraints. For example, a six-person room may need laptop presentation and video calls with shared audio. If no connection method is chosen, explain the user experience you want so options can be reviewed.

Separate missing picture, failed playback and sound problems, then identify affected screens or rooms and what still works. Name the display, source, player or app if known and note when the fault appears, recent changes and checks already completed. "One menu board is blank after overnight shutdown; two others play normally" gives useful context. If the source is unknown, describe how content normally reaches the screen.

Give screen and site counts, the parts being retained or replaced and how ready the rollout standard is. Identify variations in mounting, cabling, power and access, then state timing, content ownership and acceptance checks. For example, marketing may load approved content and each manager confirms playback. If a standard is not finalized, describe the desired change and the owner who can approve a pilot or final specification.