Service Guide
Brisk managed documentation
Tasks and Screens
Technician Leave Approvals
Technician Leave Approvals
Purpose and when to use this screen
Technician Leave Approvals lets authorized supervisors review pending service leave before it blocks dispatch capacity. The screen requires permission to change service leave and shows up to 50 pending requests plus 20 recently approved requests, optionally filtered to one active technician.
Process leave requests
- Filter by Technician when reviewing one person, or leave the filter open to work the shared pending queue.
- Confirm technician, leave type, start, end, notes, and whether the request overlaps another absence.
- Review the dispatch board, today/upcoming bookings, and working-hours coverage for the requested interval.
- If details are wrong or incomplete, use Edit and resolve the request with the technician. Do not approve it merely to remove it from the pending list.
- Select Approve once the operational decision is made. Brisk marks the request approved, records its modification time, and notifies the technician.
Understand scheduling impact
Approved leave communicates that the technician should not be treated as available during that interval. Existing bookings do not automatically become somebody else’s responsibility. Reassign or reschedule affected work deliberately and communicate customer-facing changes through the normal dispatch process.
Correcting an approval
The approval action is idempotent: selecting it again reports that the request is already approved. If approved dates or status need correction, use the supervisor-authorized leave record workflow rather than asking the technician to cancel it; technicians can cancel their own pending requests but cannot rewrite approved leave.
Approval controls
Apply the organization’s leave policy consistently, keep sensitive medical details out of general notes, and separate policy approval from dispatch coverage work. Never share supervisor credentials to make the Approve button appear.
Service Mobile Alerts
Service Mobile Alerts
Purpose and when to use this screen
Mobile Alerts registers the current browser for service dispatch and technician push notifications. Registration is per browser/device, not per phone number, and depends on browser push support, notification permission, a service worker, and server-side VAPID configuration.
Review mobile alerts
- Open the page on the device and browser that should receive alerts.
- Review Browser support, Permission, and Server status. If the server is not ready, an administrator must configure the push dependency and VAPID keys.
- Enter a meaningful Device Label, such as
Jason iPhone, so the subscription can be recognized later. - Select Enable Push on This Device and respond to the browser permission prompt.
- Select Send Test Notification and confirm the notification appears while the browser is both open and in the background.
Manage registered devices
The Registered Devices table shows label, last-seen time, and active/disabled state. Remove an old subscription after a phone is replaced, a browser profile is reset, or a device should no longer receive work information. Use Disable This Device when working on the currently registered browser.
Act on an alert
Open the linked Service Order or booking and verify the customer, equipment, priority, schedule, technician, and current status. A push alert may be stale after reassignment or completion; the service record is the source of truth.
Troubleshoot delivery
Use Run Push Debug to capture browser capability results. Check operating-system notification settings, browser permission, network access, active subscription status, and server readiness. Record the device label and debug output when escalating, but do not include customer or job details in an external support ticket unless authorized.
Technician Workspace
Technician Workspace
Purpose and when to use this screen
Technician Workspace is the signed-in technician’s daily service landing page. It combines today’s schedule, the actionable work queue, upcoming bookings, timer state, leave requests, and notification-device status. It is a working view of assigned records; the service order and booking remain the source of truth.
Use the technician workspace
Start with Today’s Jobs and the Work Queue. For each card, confirm customer, job reference, priority, status, scheduled time, and location. Read dispatch notes before traveling. Use Directions for navigation, then Open Job to review equipment, approved scope, parts, labor, notes, and customer context on the Service Order.
Update status and time as work happens
Use only the status actions offered on the booking, such as marking the next dispatch state. Do not advance status to remove a job from the queue when the underlying event has not occurred. Start the timer for the service order when billable or tracked work begins and stop it when that work pauses or ends. Only one active timer should represent the technician’s current job; resolve an unexpected running timer before starting another.
Review upcoming work and capacity
The next-seven-days metric and Upcoming Work table help the technician anticipate appointments, locations, and schedule conflicts. They are not a substitute for dispatch approval. If a job is missing, duplicated, assigned to the wrong technician, or scheduled at an impossible time, contact dispatch rather than editing unrelated records.
Manage leave and alerts
Use Request Leave to submit planned absence and track it as Pending until a supervisor acts. An approved request affects scheduling capacity; technicians cannot simply rewrite approved leave. Use Mobile Alerts to register or test the current device. Open the linked job from an alert and verify it is still current before acting.
If the workspace is empty or unavailable
Confirm the user is linked to an active Technician and Employee, the bookings are assigned to that technician, and the schedule/status is within the workspace scope. Dispatch-board and approval links appear only when the user has the corresponding permissions.