Docket_DOCKET · CHECKLIST

Digital Signage Change Management Checklist

Use this checklist to make screen updates consistent, reviewable, and easy to account for.

How to structure a screen change request

Give reviewers and operators enough information to act without guessing.

State the change type: new artwork up, old artwork down, schedule change, or removal.
Name the campaign, message, or business purpose.
Define the exact scope: screens, locations, regions, or groups.
State the reach: how many screens and locations are affected.
Link to or attach the final content or artwork, with its version.
Record go-up and come-down dates and times, including local time zones where needed.
Identify the requester and a contact method for questions.
Flag dependencies and high exposure, including promotion dates, pricing, legal language, regulated products, or national campaigns.

Set the approvers and their order in advance, then use the same process for comparable requests.

Have a content or brand owner confirm the message and creative.
Have a business owner confirm the campaign, offer, pricing, and timing.
Add legal, compliance, or regional review for legal, financial, regulatory, or reputational exposure.
Separate creator, approver, and deployer roles when independent review is warranted.
Put specialist review before final operational sign-off.
Show every approver the actual content, exact scope and reach, and go-up and come-down dates.
Require an explicit approve, reject, or send-back decision; silence is not approval.
On rejection, record the reason and return the request to the requester; allow no silent edits and require a new request for material changes.

Treat deployment as a controlled handoff from an approved decision to a verified live result.

Confirm final approval is on record before deploying.
Confirm the content version and exact scope match the approval.
Check go-live timing against store hours, local conditions, and promotion start dates.
Pilot one screen or location before a broad or high-risk rollout when practical.
Have the assigned human operator deploy the approved change in the CMS.
Confirm it appears on the intended target screens, not just in the CMS configuration.
Spot-check screens across relevant locations, screen types, and regions.
Confirm no unapproved local override altered the content, and that the come-down is scheduled, assigned, or complete.

A dependable record makes every update answerable long after it has gone live.

Record who requested, approved, and deployed the change.
Preserve the exact request, content reference, scope, reach, and locations.
Preserve timestamps for submission, approvals, deployment, and verification.
Record rejection reasons, returns for revision, exceptions, and corrective actions.
Seal records after submission so history cannot be quietly rewritten.
Require a new request when content, scope, dates, or intent changes instead of editing history.
Use the record to demonstrate authorization for compliance and brand questions.
Use it to resolve disputes quickly and improve templates, ownership, and permission controls.

Docket is a read-only layer on MagicINFO built for this workflow, with human-verified deployment and sealed request records.