1. Report the issue

  1. Check Help and guides.

    Use a safe workspace guide first when it covers the exact symptom. Create a ticket when the issue remains or the guide says to escalate.

  2. Choose the correct location.

    This controls visibility, directory contacts, access notes, routing, and reports.

  3. Write for the next person.

    State what is wrong, its operational impact, when it started, and what was already tried.

  4. Add context.

    Select category, equipment, and priority when known. Attach clear photos or files; the app keeps camera originals on the device and uploads optimized copies.

Urgent is for operational or safety impact.

Do not wait for a perfect report when there is smoke, flooding, electrical risk, food-safety risk, or an assigned emergency.

Phone ticket queue organized by location, status, priority, and assignee.
Location appears before the ticket title so supervisors can scan where the work is, not only what happened.

2. Route and coordinate

Responsibility profiles can send category-specific work to the right supervisor without filling every supervisor's queue. The coordinator can assign a technician, use an eligible field team, and designate an evidence reviewer.

  • Assign: the named technician becomes responsible for field work.
  • Claim: an eligible person takes responsibility from an open queue.
  • Request follow-up: records that somebody must return with an answer or action.
  • Reassign: transfers current responsibility without erasing earlier assignments.

3. Perform and document the work

  1. Start the shift when appropriate.

    This records availability and can suppress routine notifications outside shift hours.

  2. Mark On the way.

    The ticket records travel intent; assigned emergencies may bypass notification silence.

  3. Record arrival.

    When location logging is enabled, Workdesk stores a snapshot for the event, not continuous tracking.

  4. Add evidence as work happens.

    Use notes, multiple photos, files, equipment updates, materials, expenses, invoices, and follow-up reminders.

  5. Protect the financial record.

    Classify material as supplied or purchased. Purchased material and other expenses can include receipt evidence plus optional XML and PDF invoices.

Ticket activity timeline showing assignment, travel, and the original report.
Each transition remains attributed and ordered in the activity timeline.

4. Pause and return another day

Use Postpone when the visit cannot finish. Add a short free-text reason such as incomplete material, access unavailable, equipment in use, weather, or safety conditions.

The ticket returns to an actionable state and can repeat On the way and arrival on the next visit. The previous visit remains in the timeline.

Do not create a second ticket for the same unfinished job.

Resume the original so reporting, materials, travel, and completion remain one record.

Diagnostics before continuing

Updated Android workflow preview

This guide demonstrates Android 0.18.1. Google Play distribution of these controls has not been confirmed; your installed build may differ. Summary and report creation are Android features, not Desk Mode or portal features.

An ordinary note does not replace a structured diagnostic when evidence is needed to decide how to continue.

  1. An operational member can Request diagnostic and record the question or test scope. The request does not change status.
  2. Only the current assignee, from Work in progress, can Submit diagnostic for review. Complete summary, tests, findings, conclusion, operability and recommended action.
  3. Synchronize the submission. The ticket enters Diagnostic review; an owner or supervisor decides on the latest synchronized submission and records the rationale.
  4. The decision may continue repair or testing, pause, route to a specialist, plan replacement, or close without repair or because no fault was found. It does not claim a repair or replace completion approval.

Full diagnostic and reporting guide

Watch the updated video

5. Close, review, or resolve remotely

  • Work reported complete: the technician submits the outcome and required evidence.
  • Closure approved: the authorized location member or reviewer accepts the result.
  • On-site signature: when enabled by the owner, the technician can hand the device to the person who inspected the work. Their name, optional position or organization, acknowledgement, signature, and time become part of the closure record.
  • Reopened: the result is incomplete or the problem returned.
  • Confirmed remote resolution: an owner or supervisor records that guided action solved the issue when another approval step would add no value.

Workspace settings decide whether a closure photo or on-site signature is required. If nobody is available to sign, record the exception instead of inventing a reviewer. Remote resolution should be limited to states where the outcome can be confirmed safely.

Capture an on-site signature

The workspace owner can enable Require on-site sign-off in Workspace settings and save the change. Leave it off when normal completion review is sufficient. This setting controls the evidence collected before the technician submits completed work.

  1. Complete the work and its evidence.

    In the ticket, record the work performed and any required closure photo. Use the on-site acceptance form when sign-off is enabled.

  2. Hand the device to the person who inspected the result.

    They do not need a Workdesk account. Enter their name in Reviewer name; Position or organization (optional) can explain their relationship to the location.

  3. Let the reviewer draw their own signature.

    Ask them to read the acknowledgement and sign in the pad after checking the work. Use Clear signature if they need to try again. Do not sign for another person.

  4. Submit the completion for review.

    Check the information and required evidence, then select Submit for approval. The signature supports the closure record; it does not replace the separate approval decision by an authorized account.

Operational acceptance, not identity verification.

The record shows what was entered and submitted, by which account and when. A typed name and drawn signature do not verify legal identity and are not a general identity or payment signature.

Actual English emulator form with a fictional Demo Reviewer and DEMO strokes on the signature pad.
Actual emulator capture using fictional demo data. DEMO illustrates the pad; it was not submitted as a real person's signature.

If nobody is available or willing to sign

Select Nobody is available or willing to sign and enter the actual reason in Reason sign-off could not be obtained. For example, record that no reviewer was available at the location only if that is what happened. Do not invent a name, signature, or acceptance statement.

Submit the completion with its required evidence and exception reason. The recorded exception gives the authorized reviewer context for the next decision; it is not proof that someone accepted the work.

Actual English emulator form with the no-signer checkbox selected and a clearly labeled fictional demo reason.
Fictional example of the exception path. In a real ticket, record the actual reason.

Watch the on-site signature guide (EN-21)

6. Remove a wrong or obsolete ticket

Authorized owners or supervisors can remove a ticket created in error, orphaned by organizational change, or tied to a location that no longer exists. Removal deletes ticket media and leaves an audit entry showing who removed it, when, and why.

Removal is not a substitute for closure.

If work occurred or the record has operational value, close it with the real outcome instead.