Search Knowledge Base Articles

Support Ticket Intake, Triage and Prioritization

CE-SOP-002 — SUPPORT TICKET INTAKE, TRIAGE & PRIORITIZATION

Department: Engineering – Electrical Controls & Automation
Document Type: Standard Operating Procedure
Document ID: CE-SOP-002
Revision: Rev. 1.0
Status: Active Standard
Process Owner: Electrical Controls Engineering
Related Documents: CE-SOP-001 – Controls Engineering Project Lifecycle

1. PURPOSE

The purpose of this Standard Operating Procedure is to establish a consistent process for receiving, documenting, evaluating, prioritizing, assigning, tracking, and closing requests for Electrical Controls Engineering support.

This procedure establishes a single controlled entry point for Controls Engineering work.

The objective is to prevent Controls Engineering from operating primarily through:

Hallway conversations
Verbal requests
Text messages
Emails
Teams messages
Sticky notes
Memory
Untracked production requests
Uncontrolled "quick changes"

A verbal conversation may begin a request.

It should not become the permanent record of the request.

IF WORK IS REQUESTED, THE WORK SHOULD BE TRACKED.

2. OBJECTIVE

Every Controls Engineering request should answer:

WHO is requesting the work?

WHAT is the problem?

WHERE is the problem?

WHEN did it begin?

WHAT is the current impact?

WHAT outcome is desired?

HOW urgent is it?

WHAT controls systems are affected?

WHAT is the next action?

This information allows Controls Engineering to prioritize work based on actual risk and business impact rather than simply responding to whoever asks most recently or most urgently.

3. SCOPE

This procedure applies to requests involving:

PLC troubleshooting
PLC programming
HMI troubleshooting
HMI modifications
SCADA systems
Machine controls
Electrical controls
Sensors
Photo eyes
Proximity switches
Valves
Solenoids
Motors
VFDs
Servo systems
Remote I/O
Industrial networks
EtherNet/IP
PROFINET
Modbus
Controls communication
Control panels
I/O additions
Alarm additions
Alarm troubleshooting
Sequence modifications
Interlocks
Permissives
Data collection
Trending
Hardware replacement
Hardware upgrades
Software upgrades
Obsolescence
Controls documentation
Controls-related production improvements
Vendor/integrator support

4. SUPPORT TICKET VS. PROJECT

Not every Controls Engineering request requires a full engineering project.

However, every significant request should be tracked.

SUPPORT TICKET

A Support Ticket is generally appropriate when the work is:

Troubleshooting
Diagnostic
Limited in scope
Short duration
Low complexity
Existing-system support
Documentation correction
Minor configuration adjustment
Known repair
Minor HMI correction
Simple component replacement

Example:

Line 5 photo eye is not detecting cans consistently.

CONTROLS PROJECT

A Controls Project is generally appropriate when the request involves:

New functionality
PLC logic modification
Significant HMI modification
New I/O
New hardware
Electrical design
Network modification
Process sequence modification
Multiple departments
Planned downtime
Purchasing
Significant testing
Capital expenditure
Safety review
Vendor involvement
Multiple engineering phases
Significant documentation

Example:

Add an automatic jam detection system using the Line 5 infeed photo eye to activate the Can Stop after five seconds and provide operator reset and alarm functionality.

5. TICKET-TO-PROJECT CONVERSION

A Support Ticket may begin as troubleshooting and later become an engineering project.

Example:

Initial Ticket:

Line 5 repeatedly jams at the infeed.

Troubleshooting determines:

No automatic jam detection exists.

Recommended corrective action:

Add PLC logic, HMI diagnostics, timer, alarm, and Can Stop control.

The ticket should then be converted or linked to:

Controls Project CE-2026-####

The original Support Ticket remains part of the history.

6. SUPPORT TICKET NUMBERING

Every ticket shall receive a unique identifier.

Recommended:

CE-ST-YYYY-####

Example:

CE-ST-2026-0087

Controls Projects may use:

CE-YYYY-####

Example:

CE-2026-0047

This creates clear separation between:

Support Work

and

Engineering Projects

while allowing them to be linked.

7. SUPPORT TICKET INTAKE

Every ticket should contain the following information.

REQUESTOR INFORMATION

Requestor Name
Department
Contact Information
Manager/Supervisor
Date Requested
Time Requested

8. EQUIPMENT INFORMATION

Record:

Facility
Area
Department
Production Line
Machine
System
Asset Number
Equipment Manufacturer

Where applicable:

PLC
HMI
VFD
Network
Control Panel
Field Device

9. PROBLEM DESCRIPTION

The requestor should describe:

WHAT IS HAPPENING?

Avoid vague descriptions such as:

"PLC isn't working."

Better:

"Line 5 will not start automatically after the operator presses Start."

Better still:

"Line 5 will not start in Auto. HMI indicates Ready, but conveyor output does not energize after Start is pressed."

The ticket should describe the observable problem before assuming the technical cause.

10. CURRENT CONDITION

Document the current machine/process condition.

Examples:

Machine completely stopped
Machine running manually
Machine running at reduced rate
Intermittent problem
Alarm active
Production continuing
Temporary workaround being used
Equipment bypassed
Hardware failed
HMI unavailable
PLC faulted
Communication lost

11. EXPECTED CONDITION

Document:

WHAT SHOULD BE HAPPENING?

Example:

Current:

Valve AV19 remains closed while RO Skid is operating.

Expected:

AV19 should remain open while the RO Skid is operating under the specified operating conditions.

This distinction helps separate:

Observed Behavior

from

Expected Behavior

12. WHEN DID THE PROBLEM BEGIN?

Record:

Date first observed
Approximate time
Shift
Product/SKU if relevant
Operating mode
Recent maintenance
Recent program change
Recent power outage
Recent hardware replacement
Recent network change

This information may significantly shorten troubleshooting time.

13. FREQUENCY

Classify the issue as:

Constant
Intermittent
Random
Once
Every cycle
Certain products only
Startup only
Shutdown only
Auto only
Manual only
Specific shift
Specific operating condition

14. PRODUCTION IMPACT

Record:

NONE

No production impact.

LOW

Minor inconvenience.

MODERATE

Reduced production rate or repeated operator intervention.

HIGH

Significant production loss.

CRITICAL

Production completely stopped.

Where possible, record:

Estimated downtime
Units affected
Line speed reduction
Frequency of interruption

15. SAFETY IMPACT

Ask:

Does this issue create or potentially create a safety concern?

Options:

None known
Low
Moderate
High
Immediate concern

If an immediate safety concern exists:

MAKE THE EQUIPMENT SAFE FIRST.

The ticket process shall never delay necessary safety actions.

16. QUALITY IMPACT

Determine whether the issue could affect:

Product quality
Reject rate
Fill quantity
Temperature
Pressure
Timing
Packaging
Product identification
Recipe
Traceability
Process consistency

Quality-impacting controls issues may require escalation even when production remains operational.

17. WORKAROUND

Document whether a temporary workaround exists.

Record:

Workaround Description
Who Implemented It
Date
Risk
Production Impact
Required Removal Date

A workaround does not mean the problem is resolved.

18. REQUEST TYPE

Every ticket should be classified.

Recommended categories:

BREAKDOWN / EMERGENCY

TROUBLESHOOTING

PLC LOGIC

HMI

ELECTRICAL

SENSOR / FIELD DEVICE

NETWORK / COMMUNICATION

VFD / MOTOR CONTROL

ALARM

DATA / TRENDING

HARDWARE

SOFTWARE

DOCUMENTATION

UPGRADE

OBSOLESCENCE

CONTINUOUS IMPROVEMENT

NEW PROJECT

VENDOR SUPPORT

OTHER

19. PRIORITY SYSTEM

Controls Engineering shall use four primary priorities.

P1 — CRITICAL

Immediate response required.

Examples:

Immediate safety concern
Complete production outage
Critical PLC failure
Multiple production lines affected
Critical automation network failure
Critical controls hardware failure with no workaround

TARGET RESPONSE

Immediate

Normal project work may be interrupted.

20. P2 — HIGH

Significant operational impact.

Examples:

Major production degradation
Frequent machine stoppage
Significant quality concern
Repeated controls fault
Critical device showing signs of imminent failure
Temporary workaround creating significant operational risk

TARGET RESPONSE

Same day or next available engineering opportunity depending on plant conditions.

21. P3 — NORMAL

Standard engineering/support work.

Examples:

Minor PLC modification
HMI improvement
Alarm modification
New sensor
Planned troubleshooting
Documentation correction
Minor sequence change
Non-critical hardware replacement

TARGET RESPONSE

Scheduled according to engineering workload and production availability.

22. P4 — IMPROVEMENT / BACKLOG

No immediate production requirement.

Examples:

HMI cosmetic improvements
Future optimization
Documentation improvements
Data collection ideas
Future hardware upgrades
Obsolescence planning
Nice-to-have functionality

TARGET RESPONSE

Engineering backlog / future planning.

23. PRIORITY DECISION MATRIX

Priority should be based primarily on:

SAFETY

PRODUCTION

QUALITY

RELIABILITY

BUSINESS IMPACT

Priority shall not be based solely on:

Who requested it

How loudly it was requested.

24. PRIORITY OVERRIDE

Controls Engineering may adjust the requested priority after technical review.

Example:

Requestor selects:

Engineering determines:

Production is running.
No safety concern exists.
Workaround exists.
Change is an improvement.

Engineering may reclassify:

The reason should be documented.

Management may be consulted where priority conflicts exist.

25. EMERGENCY REQUESTS

Emergency situations do not require someone to complete an extensive form before Controls Engineering responds.

For P1 events:

RESPOND FIRST.

Then document.

Minimum initial information:

Equipment
Problem
Current condition
Safety condition
Production condition

After stabilization:

Create/update ticket
Document root cause
Document actions
Document temporary changes
Document permanent corrective action

26. VERBAL REQUESTS

If someone verbally requests Controls Engineering work:

SMALL IMMEDIATE QUESTION

May be answered without a formal ticket.

ACTUAL ENGINEERING WORK

Create a ticket.

Recommended response:

"I'll get that added to the Controls Engineering queue so we can track it."

This keeps the process professional without creating unnecessary bureaucracy.

27. EMAIL / TEAMS / TEXT REQUESTS

If an email, Teams message, or text requires significant engineering action:

Convert it into a Support Ticket.

Attach or reference the original communication where useful.

Do not allow the messaging application to become the only project record.

28. WALK-UP REQUESTS

When someone approaches Controls Engineering with:

"Can you take a quick look at something?"

Determine:

Is production stopped?

If yes:

Respond according to priority.

Is there a safety concern?

If yes:

Respond immediately.

Is this actual project work?

If yes:

Create a ticket.

Is it truly a two-minute question?

Handle appropriately without creating unnecessary administrative burden.

Use professional judgment.

29. TICKET TRIAGE PROCESS

New tickets should be reviewed using:

STEP 1 — SAFETY

Is anyone at risk?

STEP 2 — PRODUCTION

Is production stopped or degraded?

STEP 3 — QUALITY

Could product quality be affected?

STEP 4 — WORKAROUND

Can production safely continue?

STEP 5 — CONTROLS SCOPE

Is this actually a Controls Engineering issue?

STEP 6 — COMPLEXITY

Support Ticket or Project?

STEP 7 — PRIORITY

P1, P2, P3, or P4?

STEP 8 — OWNER

Who owns the next action?

30. TICKET OWNERSHIP

Every active ticket shall have:

Assigned Owner

Possible owners:

Controls Engineering
Electrical Maintenance
Mechanical Maintenance
IT
Operations
Engineering
Vendor
OEM
Integrator
Management
Other

Controls Engineering should not retain ownership of work that clearly belongs elsewhere.

31. CONTROLS ENGINEERING ACCEPTANCE

Before accepting ownership, determine:

Is the problem controls-related?

Examples of likely controls issues:

PLC fault
PLC logic
HMI issue
Sensor signal
Output signal
Communication
Drive control
Sequence
Alarm
Interlock
I/O

Possible non-controls issues:

Mechanical binding
Broken belt
Air pressure
Failed bearing
Product obstruction
Mechanical alignment

Controls Engineering may assist in diagnosis without automatically becoming the permanent owner.

32. SUPPORT TICKET STATUS

Recommended ticket statuses:

NEW

Ticket submitted but not reviewed.

TRIAGE

Controls Engineering reviewing request.

ASSIGNED

Owner identified.

INVESTIGATING

Troubleshooting underway.

WAITING FOR INFORMATION

Additional information required.

WAITING FOR PRODUCTION

Machine access required.

WAITING FOR PARTS

Hardware required.

WAITING FOR VENDOR

External support required.

WAITING FOR APPROVAL

Management authorization required.

PROJECT CREATED

Ticket converted to engineering project.

MONITORING

Corrective action implemented and being observed.

RESOLVED

Technical issue corrected.

CLOSED

Documentation complete and ticket finalized.

CANCELLED

Request no longer required.

33. DIFFERENCE BETWEEN RESOLVED AND CLOSED

These should not necessarily mean the same thing.

RESOLVED

The technical problem has been corrected.

CLOSED

The problem has been corrected and the required documentation has been completed.

Example:

Machine running:

RESOLVED

Final PLC uploaded, notes entered, root cause documented:

CLOSED

34. TROUBLESHOOTING INFORMATION

During investigation, record:

SYMPTOM

What was observed?

EXPECTED CONDITION

What should have occurred?

TESTS PERFORMED

What was checked?

FINDINGS

What was discovered?

ROOT CAUSE

What caused the problem?

CORRECTIVE ACTION

What fixed it?

VERIFICATION

How was the fix proven?

35. ROOT CAUSE CATEGORIES

Recommended:

PLC Logic
HMI Configuration
Sensor
Output Device
Wiring
Power
Network
Communication
Drive
Mechanical
Pneumatic
Hydraulic
Operator
Configuration
Hardware Failure
Software/Firmware
Documentation Error
Unknown
Other

This allows future reporting on recurring failures.

36. TEMPORARY FIX VS. PERMANENT FIX

Every resolution should identify:

TEMPORARY CORRECTIVE ACTION

What restored operation?

PERMANENT CORRECTIVE ACTION

What prevents recurrence?

Example:

Temporary:

Sensor repositioned to restore production.

Permanent:

Replace damaged mounting bracket and establish correct sensor alignment.

Do not allow:

Machine running

to automatically mean:

Problem permanently corrected.

37. CONTROLS PROGRAM CHANGES DURING SUPPORT

If troubleshooting requires a PLC/HMI modification, the ticket shall trigger the applicable requirements of:

CE-SOP-001 – Controls Engineering Project Lifecycle

At minimum:

☐ Pre-change backup
☐ Change description
☐ Risk consideration
☐ Testing
☐ Post-change backup
☐ Change log

Production emergencies may temporarily compress this sequence, but documentation shall be completed after stabilization.

38. SUPPORT TICKET REQUIRED ATTACHMENTS

Where applicable attach:

PLC screenshots
HMI screenshots
Photos
Electrical drawings
Trend screenshots
Alarm history
Error codes
Vendor documentation
Emails
Quotes
Program files
Commissioning results

The ticket should eventually tell the complete story.

39. SUPPORT TICKET ACTIVITY LOG

Each significant action should be recorded.

Recommended format:

Date / Time

Person

Action

Finding

Next Step

Example:

10/06/2026 – 10:15 AM

Controls Engineering inspected Line 5 infeed photo eye. PLC input changes correctly when sensor is manually blocked. Investigation continuing into downstream logic.

40. NEXT ACTION

Every open ticket should contain:

NEXT ACTION

Examples:

Inspect sensor
Review PLC logic
Contact vendor
Order replacement module
Schedule downtime
Obtain production approval
Test during next run
Convert to project
Monitor 24 hours

A ticket without a next action often becomes a forgotten ticket.

41. WAITING ON

Every blocked ticket should contain:

WAITING ON

Examples:

Production

Maintenance

Vendor

Manager

Parts

Purchase Order

Engineering

Requestor

This makes project-review meetings significantly more effective.

42. TARGET DATE

Every P2, P3, and planned P4 ticket should have a target date when practical.

The target date may change.

If changed, record why.

Examples:

Production unavailable
Parts delayed
Higher-priority emergency
Scope changed
Vendor delayed
Management requested hold

43. TICKET AGING

The web system should calculate:

Ticket Age = Current Date – Date Opened

Suggested indicators:

GREEN

Normal age for current status.

YELLOW

Ticket approaching expected completion or has been inactive.

RED

Ticket significantly overdue or blocked.

This helps prevent forgotten work.

44. STALE TICKET RULE

An open ticket should not remain untouched indefinitely.

Recommended:

Tickets with no meaningful activity for 7 business days should be reviewed.

Determine:

Still required?
Waiting on someone?
Needs escalation?
Should become project?
Should be closed?
Should be cancelled?

45. ESCALATION

Escalate when:

Safety concern exists
Production impact is significant
Quality risk exists
Multiple departments are affected
Critical hardware is unavailable
Obsolete equipment prevents repair
Required downtime cannot be obtained
Management decision is required
Cost exceeds expected limits
Vendor/OEM support is required
Ticket remains blocked
Requested work could create unacceptable controls risk

46. PROJECT CONVERSION CRITERIA

Consider converting a ticket to a project when any of the following apply:

☐ PLC logic modification
☐ Significant HMI modification
☐ New I/O
☐ New hardware
☐ Electrical design required
☐ Planned downtime required
☐ Purchasing required
☐ Multiple departments involved
☐ Vendor/integrator involved
☐ Significant testing required
☐ Safety review required
☐ Sequence of Operation required
☐ Multiple engineering days expected
☐ Formal commissioning required

When converted:

Create:

CE-YYYY-####

Link:

Original CE-ST-YYYY-####

Then follow:

CE-SOP-001

47. SUPPORT TICKET CLOSEOUT

Before closing:

☐ Problem identified
☐ Root cause documented where known
☐ Corrective action documented
☐ Permanent/temporary status identified
☐ Testing documented
☐ Production operation verified
☐ PLC/HMI backups completed if modified
☐ Change log updated if required
☐ Related project linked
☐ Knowledge Article linked/created where beneficial
☐ Requestor/stakeholder informed

48. SUPPORT TICKET CLOSURE SUMMARY

Every closed ticket should contain a short summary.

Use:

PROBLEM

What happened?

ROOT CAUSE

Why did it happen?

CORRECTIVE ACTION

What was done?

VERIFICATION

How was successful operation confirmed?

FOLLOW-UP

Is anything else required?

Example:

Problem: Line 5 Can Stop failed to activate during extended infeed jam.

Root Cause: Existing logic did not monitor prolonged blockage of the infeed photo eye.

Corrective Action: Support Ticket converted to Controls Project CE-2026-0047 for development of automatic jam detection and Can Stop control.

Verification: Project commissioning completed successfully.

Follow-Up: Monitor production performance for 72 hours.

49. KNOWLEDGE ARTICLE TRIGGER

At ticket closure ask:

COULD THIS PROBLEM HAPPEN AGAIN?

and

WOULD ANOTHER ENGINEER BENEFIT FROM KNOWING HOW THIS WAS SOLVED?

If YES:

Create or update a Knowledge Article.

Potential examples:

Communication faults
PLC faults
PanelView download problems
Drive faults
Sensor troubleshooting
Unusual equipment behavior
Firmware incompatibility
Network configuration
Program restoration

The Support Ticket solves today's problem.

The Knowledge Article helps solve tomorrow's problem faster.

50. REPEAT FAILURE RULE

If the same or similar ticket repeatedly occurs, do not continue treating every occurrence as an isolated problem.

After repeated occurrences:

Perform:

ROOT CAUSE REVIEW

Consider:

Engineering modification
Hardware upgrade
Preventive maintenance
Design improvement
Obsolescence replacement
Additional diagnostics
Alarm improvement
Operator training

Create a Controls Project when appropriate.

51. WEB SYSTEM — RECOMMENDED TICKET SECTIONS

The Support Ticket page should contain:

TAB 1 — REQUEST

Ticket ID
Date
Requestor
Department
Equipment
Description
Expected Condition

TAB 2 — IMPACT

Safety
Production
Quality
Reliability
Workaround
Priority

TAB 3 — TECHNICAL INFORMATION

PLC
HMI
Software
Network
Relevant I/O
Alarm
Error Code

TAB 4 — INVESTIGATION

Symptom
Tests
Findings
Root Cause
Attachments

TAB 5 — ACTIONS

Corrective Action
Temporary Fix
Permanent Fix
Assigned Owner
Next Action
Waiting On
Target Date

TAB 6 — PROGRAM CHANGE

PLC Changed?
HMI Changed?
PRECHANGE Backup
POSTCHANGE Backup
Revision
Change Log

TAB 7 — CLOSEOUT

Verification
Requestor Notification
Related Project
Related Knowledge Article
Closure Summary
Closed By
Close Date

52. WEB SYSTEM AUTOMATION RULES

Recommended automated behaviors:

IF SAFETY IMPACT = HIGH

Flag ticket:

SAFETY REVIEW REQUIRED

IF PRODUCTION IMPACT = CRITICAL

Recommend:

IF PLC CHANGED = YES

Require:

PRECHANGE BACKUP

and

POSTCHANGE BACKUP

IF HMI CHANGED = YES

Require:

PRECHANGE HMI BACKUP

and

POSTCHANGE HMI BACKUP

IF STATUS = WAITING

Require:

WAITING ON

IF STATUS = CLOSED

Require:

Root Cause
Corrective Action
Verification
Closure Summary

IF PROJECT CREATED = YES

Require:

Related Project ID

53. SUPPORT TICKET DASHBOARD

The Controls Engineering dashboard should show:

OPEN TICKETS

Total open.

P1

Critical tickets.

P2

High-priority tickets.

WAITING

Tickets blocked by others.

AGING

Oldest open tickets.

REPEAT FAILURES

Equipment with repeated tickets.

BY EQUIPMENT

Which machines generate the most Controls Engineering support.

BY ROOT CAUSE

What types of controls problems occur most often.

RESOLUTION TIME

Average time to resolution.

54. WEEKLY REVIEW

Support Tickets should feed directly into the weekly project review.

Discuss:

CRITICAL / HIGH PRIORITY

What requires immediate attention?

COMPLETED

What was resolved?

IN PROGRESS

What is being investigated?

BLOCKED

What are we waiting on?

PROJECT CONVERSION

Which support issues should become engineering projects?

REPEAT FAILURES

What problems continue returning?

UPGRADE OPPORTUNITIES

What aging hardware or software should be replaced?

This converts support data into engineering strategy.

55. CONTROLS ENGINEERING WORK QUEUE

Recommended order of attention:

1. SAFETY

↓

2. P1 PRODUCTION EMERGENCY

↓

3. P2 HIGH-IMPACT SUPPORT

↓

4. SCHEDULED COMMISSIONING

↓

5. ACTIVE ENGINEERING PROJECTS

↓

6. P3 SUPPORT

↓

7. DOCUMENTATION / PREVENTIVE WORK

↓

8. P4 IMPROVEMENTS

The exact order may change depending on business needs.

56. PROTECTING ENGINEERING TIME

The existence of a ticketing system does not mean every ticket requires immediate interruption.

Controls Engineering requires uninterrupted time for:

PLC development
HMI development
Electrical design
Documentation
Testing
Research
Project planning

P3 and P4 requests should normally enter the queue rather than continuously interrupt development work.

This becomes increasingly important while only one Controls Engineer is available.

57. SUPPORT TICKET QUALITY STANDARD

A good ticket allows another qualified engineer to answer:

What happened?

Where did it happen?

What should have happened?

What impact did it create?

What was investigated?

What was discovered?

What was done?

Did it work?

What happens next?

If the ticket cannot answer these questions, the record is incomplete.

58. QUICK-REFERENCE SUPPORT WORKFLOW

For everyday use:

1. CAPTURE IT

Create the ticket.

2. CLASSIFY IT

Determine request type.

3. PRIORITIZE IT

P1 / P2 / P3 / P4.

4. ASSIGN IT

Identify owner.

5. UNDERSTAND IT

Define symptom and expected behavior.

6. INVESTIGATE IT

Troubleshoot systematically.

7. CORRECT IT

Implement appropriate action.

8. TEST IT

Verify successful operation.

9. DOCUMENT IT

Record findings and corrective action.

10. ESCALATE IT

Convert to project when required.

11. LEARN FROM IT

Create a Knowledge Article when useful.

12. CLOSE IT

Complete the support record.

59. THE SUPPORT TICKET STANDARD

IF IT REQUIRES ENGINEERING WORK, TRACK IT.

IF IT CHANGES THE PROGRAM, CONTROL IT.

IF IT KEEPS HAPPENING, INVESTIGATE WHY.

IF YOU SOLVE SOMETHING DIFFICULT, DOCUMENT IT.

IF IT BECOMES A PROJECT, FOLLOW CE-SOP-001.

60. DEFINITION OF SUCCESS

CE-SOP-002 is successful when Controls Engineering can answer at any time:

What work is currently requested?
What is most important?
What is currently being worked on?
What is blocked?
Who are we waiting on?
What equipment repeatedly fails?
What controls problems consume the most time?
What work should become a project?
What hardware should be upgraded?
What work has been completed?
What value is Controls Engineering providing?

The Support Ticket system is not merely a place to store requests.

It is the historical record of the health, workload, recurring failures, and improvement opportunities of the plant's controls systems.

61. REVISION HISTORY

Rev. 1.0

Initial release of CE-SOP-002 – Support Ticket Intake, Triage & Prioritization.

Owner: Electrical Controls Engineering

Review Frequency: Annual or following significant changes to the Controls Engineering support process.