From Service Request to Completed Work Order

FaciliWorks Faciliworks 8i
1

FaciliWorks 8i gives organizations multiple paths from a Service Request (SR) to a Work Order (WO), so teams can match the system to how maintenance actually operates.

Step 1: Service Request (SR) Is Created

Service Requests can be submitted by:

  • Maintenance users with module rights

  • Non-maintenance staff using the optional Service Request module

Once submitted:

  • The request is immediately in the system

  • No emails, phone calls, or sticky notes

  • Status is visible to both requestors and maintenance

Typical SR data includes:

  • Issue description (Problem)

  • Location or asset (if known)

  • Priority

  • Comments or attachments (if enabled)

Step 2: Review, Approval, or Direct Action

This is where FaciliWorks 8i becomes flexible.

Option A: Two-Step Process (SR → Approval → WO)

If approvals are enabled:

  • Maintenance reviews the SR

  • Comments entered here carry forward to the WO

  • If no comments exist, the problem description transfers automatically

  • SR is approved, then converted to a WO

Best for:

  • Regulated environments

  • Budget or safety oversight

  • Centralized planning

Option B: Create a Work Order Directly from the SR Page

If enabled, users can:

  • Create a Work Order directly from the Service Request page

  • Bypass the two-step approval process

  • Bypass converting the SR via the Edit SR menu

This means:

  • SR → WO in one action

  • No additional navigation

  • No approval bottleneck

Best for:

  • Fast-response teams

  • Emergency or reactive maintenance

  • Lean maintenance operations

The Service Request still remains linked—only the path changes.

Step 3: Edit the Service Request (If Needed)

Before conversion (or direct WO creation), maintenance can:

  • Assign or correct the asset

  • Assign a task (repair or PM-related)

  • Adjust priority

  • Cancel duplicate or invalid requests

This ensures the Work Order starts with clean, usable data.

Step 4: Work Order Is Created

Regardless of the path:

  • The Work Order becomes the execution record

  • The Service Request remains linked as the origin

  • Status tracking stays intact

Key distinction:

The SR explains why the work exists.
The WO records how the work was done.

Step 5: Execute the Work Order

Technicians can now:

  • Perform the work

  • Log labor time

  • Record parts usage

  • Add completion notes

  • Attach photos or documents through Attachments

This is where accurate history is built.

Step 6: Complete the Work Order

When the WO is completed:

  • The WO is closed

  • The linked SR is automatically resolved

  • Records are preserved for reporting, audits, and KPIs

Now you can measure:

  • Response time

  • Labor and material costs

  • On-time completion

  • Repeat failures

Why FaciliWorks Separates SRs and WOs

This design:

  • Eliminates “lost” requests

  • Supports both controlled and fast-response workflows

  • Preserves accountability without slowing work

  • Gives management clean data without burdening technicians

You’re not forced into one workflow—you configure the one you need.

  • Do you allow direct WO creation from SRs?

  • When does a two-step approval actually add value?

  • Where do SRs slow your team down today?

  • What data do you wish requestors always included?

Drop your workflow below—every facility runs differently, and that’s the point

1 Like