Jonathan CapalboBusiness analysis, reporting & systems
Back to Selected projects

Self-directed portfolio case study · Hypothetical

A ticketing plan for five types of arcade issues.

The proposed process covers broken machines, game-card issues, refunds, prize-counter problems, and facility incidents at one fictional location.

Hypothetical and simulated The business and planning scenario are fictional. This is a process proposal, with no configured software, executed UAT, or measured results.
Review requirements and planned tests Compare the workflows
Project type
Self-directed analysis and planning for a hypothetical scenario
My contribution
Mapped the process, defined requirements and acceptance criteria, and planned UAT and rollout
Tools/platform
Process mapping and requirements documentation; ServiceNow is a conceptual mapping only
Deliverables/status
Process proposal and public evidence pack. No configured software; all planned tests remain Not Executed.

Problem and recommendation

Bring scattered issue reports into one clear ticketing process.

In the simulated current state, staff report issues through conversations, paper notes, phone calls, and messages. With information spread across several channels, it is hard to see who owns the work, what is urgent, and whether an issue was fully resolved.

The proposed pilot covers one location and five issue types, with shared routing, approvals, training, and reporting. Limiting the location keeps the operating boundary clear; including five issue types still introduces different approval and exception paths.

Process comparison · Hypothetical

From scattered reports to verified closure.

A visualization of the existing proposal, based on the evidence pack’s process comparison and status rules. No software was configured or tested.

Safety comes before ticket entry.For an emergency or immediate hazard, staff would secure the area and follow the emergency procedure first, then document the incident when safe.

Simulated current state

  1. Scattered intakeStaff use conversations, paper, calls, and messages.
  2. Informal handoffUrgency and responsibility depend on who hears the report.
  3. Work and decisionsUpdates and refund decisions may sit outside the original report.
  4. Verbal completionA verbal update may be the only evidence of a fix.

Scattered records make pending work, backlog, and completion measures difficult to reconcile.

Proposed future state

  1. NewStaff record category, location, description, and urgency.
  2. TriagedShift lead confirms impact and priority.
  3. AssignedShift lead assigns a team and named owner.
  4. In ProgressOwner investigates and records actions.
    ↔ PendingOptional dependency branch. Return here when work resumes.
  5. ResolvedOwner records action notes and a resolution code.
  6. VerifyShift lead checks completion.
    Fail → In ProgressRecord the reason; retain the owner.
    Pass → Closed
  7. ClosedRecord verifier and time; preserve history for reporting.
Boxes name ticket statuses except Verify, which is a decision between Resolved and Closed. Arrows show the proposed handoffs and return paths.

Refund approval is a separate decision.

The ticket stays In Progress while an authorized manager other than the requester decides. Approval allows fulfillment within the approved amount. Rejection requires a reason and customer communication, then resolution as declined.

Refund decision criteria

Pending retains the owner.

Parts, vendor, or customer input can block work. Record the reason, next action, and review date. The shift lead reviews overdue items. When the dependency arrives, return to In Progress.

Pending criteria

Verification controls closure.

Resolved remains in the open backlog. A failed check returns to In Progress; a passing check permits closure. A later recurrence creates a linked new ticket and preserves the closed record.

Verification criteria
Read the process as text

In the simulated current state, staff report through conversations, paper, calls, and messages. Priority and ownership depend on who hears the report. Work and refund decisions may occur outside it; completion may be verbal, leaving scattered records for reporting.

In the proposed future state, emergency response comes first for immediate hazards, followed by documentation when safe. Staff create a New ticket. The shift lead confirms impact and priority (Triaged), then a team and named owner (Assigned). Unclear routing stays with the shift lead.

The owner records work In Progress. Refunds require a separate manager decision before fulfillment; awaiting approval is still In Progress. Optional Pending requires a dependency reason, next action, review date, and retained owner; work resumes In Progress.

Action notes and a resolution code allow Resolved. Shift-lead verification either fails, returning to In Progress with a reason and the same owner, or passes, permitting Closed with verifier and timestamp recorded. Closed history is preserved; recurring issues receive linked new tickets.

Read the process table and exception rules

Worked example · Hypothetical

A repair is attempted, but the machine still fails.

This fictional request illustrates the proposed rules. It is not an implemented workflow or an executed test.

  1. Report and assign

    A staff member reports that the start button on Machine A-12 is unresponsive. The report includes the machine location and urgency. The shift lead confirms impact and priority, then assigns a named maintenance owner before work starts.

    REQ-03 · Ownership rule

  2. Resolve, then verify

    After an attempted repair, the owner records the action and marks the issue Resolved. Under the proposed closure rule, the shift lead must verify that the machine works before it can become Closed.

    REQ-06 · Closure ruleAC-06 · Acceptance criteria

  3. Plan the failure check

    The shift lead finds that the start button still fails. UAT-09 would first try recording failed verification without a reason, which should be rejected. With the reason entered, the ticket should return to In Progress with its owner retained. Test status: Not Executed.

    UAT-09 · Planned test

Why this rule matters: an attempted repair would remain in the open backlog until it passes verification. Closing a ticket would mean confirmed completion.

Public evidence pack

Review the decisions behind the ticketing plan.

I compared the proposed process with the simulated current state, defined ownership and exception rules, and linked requirements to acceptance criteria and planned tests.

These proposed artifacts expand the fictional scenario into reviewable rules and test scenarios. They have not been approved by real stakeholders or tested in a configured system.

  1. Process comparisonCurrent and proposed workflows, responsible roles, and exception paths.
  2. Requirements registerTen proposed requirements with rationale, priority, and review ownership.
  3. Acceptance criteriaGiven/When/Then scenarios linked to each requirement.
  4. Planned testsFourteen UAT scenarios with setup, actions, and expected results. All are Not Executed.
  5. Traceability sampleFollow a process need through its requirement, acceptance criteria, and planned tests.
Open the evidence packDownload the pack (HTML)

Planning methods

Business analysis methods used in this case study.

Stakeholder analysisCurrent and future-state mappingRequirements analysisBusiness rulesUser storiesAcceptance criteriaData definitionTraceabilityUAT planningImplementation planningProcedure writingKPI design

Methods and sources

References for the planning approach.

Business analysis structure

I used IIBA's standard to organize the work.

IIBA Business Analysis Standard
Acceptance criteria format

I wrote scenarios in Given/When/Then format.

Cucumber Gherkin reference
Public project summary

The summary notes describe the scope and methods. The public evidence pack above contains the proposed requirements and planned tests.

Read summary notes

Contact

Contact Jonathan.

I'm open to business analysis, reporting, operations, and business systems opportunities.

View LinkedIn profile
Resume (PDF) Email Jonathan GitHub