Learn what Veyviz does and how to use it.

The product in one sentence

Veyviz connects compatible camera video to one place that spots an agreed event, adds the site details, alerts the right person, records the response and keeps proof of the result.

Where you can use Veyviz

Web console

Watch, review, search and report.

Mobile and tablet

Respond while away from a desk.

Message alerts

WhatsApp, SMS and email.

Camera connector

Use supported cameras and recorders.

Sites and maps

Find the exact place quickly.

Actions and reports

Follow up, record and improve.

What a normal day looks like

1. Events arrive

   Only chosen event types appear, with the site, camera, time, importance and video.

2. A person takes responsibility

   The operator receives the alert. If nobody replies, Veyviz sends it to the backup contact.

3. The site responds

   The responsible person follows the suggested action, records what happened and adds supporting information if needed.

4. The issue is finished

   The team confirms the result and Veyviz keeps the event history for later review.

Start in the right place

• Operations teams: define the business result and the person who should respond.
• IT teams: review cameras, video feeds, network access and user access.
• Security teams: agree who can see records, how long they stay and which systems can connect.
• Site teams: practise receiving, responding to and finishing one real alert.

A useful first setup starts with one clear event—not every camera and every possible alert at once.

Choose the channel by urgency

WhatsApp

Picture, place and next action.

SMS

Short urgent backup alert.

Email

More detail and summaries.

Configure one alert route

1. Select the event and site

   For example, queue threshold exceeded at Store 12 during opening hours.

2. Name the primary owner

   Use a role such as duty manager rather than depending on one permanent individual.

3. Add operating schedules

   Route weekday, weekend and out-of-hours alerts to the people actually on duty.

4. Set acknowledgement time

   Define how long the primary owner has before the alert moves to a backup.

5. Define escalation

   Specify the second contact, supervisor and final unresolved-event path.

6. Send a controlled test

   Confirm message delivery, link access, acknowledgement and recorded timestamps.

What every message should contain

• Plain-language event name and priority.
• Site, zone, camera and time.
• A still image or evidence link when appropriate.
• The required action and expected closure condition.
• Acknowledge, view details and escalate options.

Avoid too many alerts

Do not send every event to every manager. Adjust the alert level, group repeated events, send alerts based on work schedules and review ignored alerts each week. If people regularly dismiss an alert, change the rule, recipient or response instruction.

Test who receives alerts whenever opening hours, staff schedules, phone numbers or backup responsibilities change.

Use a simple hierarchy

A zone should match the language the site team uses—Loading Bay 3, Billing Zone or North Entrance—not a technical recorder channel number.

Build the structure

1. Create the site

   Add name, address, timezone, operating hours and primary contacts.

2. Add buildings and floors

   Use only the levels needed to locate an event without slowing navigation.

3. Define zones

   Mark operational areas such as entrances, tills, restricted rooms, production cells or parking bays.

4. Place cameras

   Assign each camera to one primary zone and use a clear display name.

5. Upload a floor map

   Place camera markers, entrances and key response points so an unfamiliar operator can orient quickly.

6. Create camera groups

   Group by responsibility or workflow, such as “night perimeter” or “checkout operations.”

Naming standard

Keep site codes short, make zone names human-readable and use the same format everywhere.

Quality check

• Every alert shows a meaningful site and zone.
• Camera names match labels used by local teams.
• Maps reflect current walls, doors and operational areas.
• User permissions follow the same site hierarchy.
• Closed or replaced cameras are removed from active groups.

Supported connection paths

Information to collect

• Manufacturer, model, firmware and camera count.
• Recorder manufacturer, model and channel mapping where applicable.
• Available stream method, codec, resolution, frame rate and bitrate.
• Dedicated read-only credentials and credential owner.
• Network ranges, VLANs, firewall owner and outbound connectivity policy.
• Sample day and night footage from the intended camera view.

Run a controlled compatibility test

1. Select one representative camera

   Choose the same model and environment used across the wider site.

2. Validate stream stability

   Check continuous access, timestamps, resolution, frame rate and reconnect behaviour.

3. Review the scene

   Confirm lighting, angle, distance, obstructions and whether the event is visually distinguishable.

4. Confirm network impact

   Measure expected bandwidth and make sure the route follows site security policy.

5. Run the target event

   Test the actual detection and workflow, not only whether a video tile loads.

6. Document the result

   Record approved settings, limitations and actions required before expansion.

Common causes of poor results

Low light, excessive compression, unstable timestamps, a view that is too wide, moving cameras, blocked sightlines and inconsistent network access can all reduce reliability. Correct the source condition before compensating with more alerts.

Compatibility is confirmed by model, firmware, stream and scene—not manufacturer name alone. Veyviz can work with cameras from leading suppliers, including Bosch, subject to technical validation.

Phase 1: define the result

Write one measurable statement: “When checkout queue occupancy exceeds the agreed threshold, the duty manager is alerted within one minute, opens capacity and verifies recovery.” Name the owner, the action and the evidence required to close.

Phase 2: prove the workflow

1. Select 1–3 cameras

   Use representative scenes with stable video and an engaged local team.

2. Record a baseline

   Measure how often the event occurs and how the team responds today.

3. Configure and tune

   Connect cameras, set the event rule, route alerts and adjust thresholds.

4. Run live operations

   Use the workflow for an agreed period and review false, missed and ignored alerts.

5. Measure the result

   Compare response time, ownership, completed actions and repeat events with the baseline.

Phase 3: create a site template

• Approved camera and stream settings.
• Site, zone and camera naming standard.
• Event threshold and operating schedule.
• Primary owner, backup and escalation path.
• Closure evidence and reporting cadence.
• Local training and support contacts.

Phase 4: expand deliberately

Roll out in waves. Validate each new site against the template, allow for local differences and require an owner sign-off before moving to the next wave. Review performance centrally, but keep response ownership close to the site.

Do not use camera count as the only measure of rollout progress. A connected camera without a clear owner and closure workflow is not operational value.

Where partners add value

Recommended project steps

1. Understand the need

   List the customer’s goal, visible event, sites, cameras, response team and timing.

2. Check the cameras

   Prepare the camera list, network details, sample video feeds and site limits.

3. Plan the setup

   Agree how cameras connect, who can use Veyviz, how long proof is kept and where alerts are sent.

4. Run a first test

   Connect a small set of cameras and prove that an alert leads to a completed response.

5. Approve the result

   Record results, settings, responsibilities, limits and the support handover.

6. Expand

   Repeat the approved setup and review customer results at agreed times.

Handoff pack

• As-built camera and network inventory.
• Approved stream and event settings.
• Site contacts and escalation ownership.
• User access and administrator ownership.
• Support boundaries and incident route.
• Training record and customer acceptance.

Good partner conversations

Lead with the customer’s operating problem, not AI terminology. Explain what will be detected, who will act, what evidence remains and how success will be measured. This makes technical scope and business value easier to agree.

Identity and access

• Who creates, approves and removes users?
• Which roles can view live video, evidence, reports and configuration?
• Can access be limited by organization, site or responsibility?
• How are administrator and integration credentials protected?
• What is the joiner, mover and leaver process?

Data and retention

• Which video, images, event metadata and audit records are needed?
• What retention period is required for each record type?
• Who can export, share or delete evidence?
• Where do backups or downstream copies exist?
• What happens when a customer account, site or camera is removed?

Network and integrations

1. Map the data path

   Document cameras, recorder or edge connector, network boundaries, Veyviz and every downstream service.

2. Minimize access

   Use dedicated credentials, required ports and the least network reach needed for the approved connection.

3. Review integrations

   Confirm authentication, permitted actions, transferred fields, failure behaviour and credential rotation.

4. Test resilience

   Check reconnect, alert delivery and operator behaviour during camera, network or service interruptions.

Operations and audit

Confirm that important actions—alert creation, acknowledgement, assignment, configuration change and closure—can be traced to a user and time. Agree who reviews unusual access, repeated failures and unresolved alerts.

Use the detailed security documentation and your organization’s own risk process for final approval. This guide is a review structure, not a substitute for customer security policy.

Two different data contexts

Operational privacy checklist

• Write the purpose for every enabled camera event.
• Confirm who is responsible for the camera operation and local notices.
• Limit views and alerts to people who need them.
• Choose retention based on the operational and legal requirement.
• Avoid collecting unrelated views, audio or information.
• Document export, access-request and deletion procedures.

Configure with privacy in mind

1. Limit the scene

   Use the camera angle and zone needed for the event.

2. Limit the event

   Enable only detections connected to a defined purpose and response.

3. Limit recipients

   Route evidence to approved roles and avoid uncontrolled forwarding.

4. Limit retention

   Set the shortest period that still meets the agreed operational requirement.

5. Review regularly

   Reassess when the site, use case, camera view or operating process changes.

Questions to document

Who decides the purpose? Who can access the information? Where is it processed? How long is it retained? Which vendors or integrations receive it? How can a concern be raised? Record the answers before the workflow goes live.

Handle an alert in five steps

1. Read the event

   Check priority, site, zone, camera, time and event description before acting.

2. Review the evidence

   Use the available image, clip and event details to confirm that the situation requires attention.

3. Take ownership

   Assign the event to yourself or the correct site owner so everybody knows who is responding.

4. Record the action

   Follow the recommended response and add a concise note describing what was done.

5. Verify closure

   Confirm the closure condition from evidence or site feedback before marking the event complete.

Decide what to do

Write a useful record

A good note states what the operator observed, who was contacted, what action occurred and how closure was confirmed. Avoid notes such as “done” or “handled” that cannot support a later review.

Example: “Queue confirmed at 14:07. Duty manager Priya acknowledged and opened counter 4. Count returned below threshold at 14:11; closure verified from Camera D4.”

Before ending a shift

• No high-priority event is unassigned.
• Open events have a current owner and next action.
• Closures include a reason or evidence.
• Repeated issues are handed to the next shift or manager.

Start with four questions

Run a weekly review

1. Choose what to review

   Select the sites, event type and opening hours you want to check.

2. Find problems first

   Open late, unassigned, passed-on and reopened events first.

3. Read the timeline

   Review a sample from the first alert to the confirmed fix. Averages can hide individual failures.

4. Group the causes

   Separate camera quality, alert settings, staffing, responsibility and physical site problems.

5. Assign improvement work

   Name a responsible person, due date and clear expected result.

6. Check the next report

   Confirm whether the action reduced repeat problems or response time.

Interpret metrics carefully

More alerts do not automatically mean a worse site; the site may have more cameras, longer hours or a newly enabled rule. Compare like with like, examine rates and verify whether the business outcome improved.

Manager checklist

• Every late response has an explained cause.
• Every repeated problem has someone responsible for improving it.
• False or unhelpful alerts are adjusted.
• Strong-performing sites share what works.
• Actions are checked in the next report.

Use the four-part test

1. Visible

   Can a fixed camera reliably see the event or condition?

2. Actionable

   Is there a named person who can do something useful within a defined time?

3. Verifiable

   Can the team confirm that the situation changed or the required procedure occurred?

4. Valuable

   Does improvement affect safety, service, throughput, loss, compliance or another business result?

Examples by environment

Write the use case

Use this format: “When visible condition happens at site or zone, alert role within time. They will action. Close when evidence condition is met. Review business metric after period.”

Reject weak candidates

• No person owns the response.
• The camera cannot reliably see the condition.
• There is no agreed closure condition.
• The event is interesting but does not change an operating result.
• The proposed scope needs many sites before it can be measured.

Write the evaluation hypothesis

Example: “If Veyviz alerts the duty manager when queue pressure exceeds the agreed level, the store can open capacity faster and reduce time above threshold.” This connects technology, action and result.

Define the scope

Run the evaluation

1. Baseline

   Measure current event frequency, response and outcome before changing the process.

2. Connect

   Validate stream stability, scene quality, user access and alert delivery.

3. Rehearse

   Run controlled events with the actual operators and escalation path.

4. Operate

   Use the workflow during normal conditions for the agreed period.

5. Review

   Compare results, inspect exceptions and record technical or process changes.

6. Decide

   Proceed, adjust and retest, or stop—with evidence supporting the decision.

Agree success before starting

• Representative cameras remain connected and stable.
• Target events are detected at an agreed quality level.
• Alerts reach the correct on-duty owner.
• Response and closure are recorded consistently.
• The selected business measure improves or the evaluation explains why it did not.

A proof of value should be small enough to learn quickly and complete enough to test the real operating process.