IG
IIG Ticketing Prototype
Internet Gateway Ops Case Study
IIG • 2014
● IIG • NOC • Incident Tracking

Prototyping a Ticketing & Email Notification System for IIG Stakeholders

Built a prototype ticketing system with email notifications for ticket stakeholders using PHP on top of osTicket, demonstrating how an Internet Gateway (IIG) operator could streamline incident tracking and communication across NOC and partner teams.

Experience Software Engineer – IIG Tools
Domain International Internet Gateway (IIG)
Stack PHP • osTicket • Email

At an IIG, stable connectivity and fast incident response are critical. Between 2012 and 2014, I designed and implemented a ticketing prototype on top of osTicket that connected NOC events with the right stakeholders via automated email notifications, serving as a demonstration of how more structured incident management could work for the gateway.

Problem → Solution → Impact

Problem

  • Incident updates were ad-hoc emails with little traceability.
  • Stakeholders (NOC, upstreams, customers) lacked timely visibility.
  • No lightweight system to prove structured incident handling.

Solution

  • osTicket-based prototype tailored to IIG network events.
  • Email-triggered notifications tied to ticket lifecycle.
  • Configured flows for routing, updates, and accountability.

Impact

  • Incidents became trackable with owners and status.
  • Stakeholders received timely, automated updates.
  • Proof of concept for a full incident system at the gateway.
Incident visibility
Before: inbox chaos After: tickets + timelines
Routing & updates
Before: manual forwarding After: automated notifications
Closure clarity
Before: unclear resolutions After: structured ticket states
Map NOC communication

Document how incidents were escalated and where updates got lost.

Configure osTicket

Tailor categories, roles, and email hooks for IIG-specific events.

Demo & iterate

Show NOC and management how structured tickets improve response.

Impact spotlight
  • Network events no longer vanish in inbox threads.
  • Stakeholders know owners, status, and next steps sooner.
  • Foundation laid for a production-grade incident system.
Overview

Introduction

Internet Gateways carry international traffic for ISPs and enterprises. When something goes wrong — fibre cuts, routing issues, capacity problems — many stakeholders need to know: NOC engineers, upstream providers, enterprise customers, management.

I built a prototype ticketing system on top of osTicket using PHP, configured specifically for IIG-style incidents. It served as a live demonstration of how structured tickets and email notifications could replace scattered spreadsheets and ad-hoc email chains.

Background

Context

Prior to this work, incident handling for the IIG environment relied heavily on:

  • Generic email threads for outage reports and updates.
  • Manual tracking of who needed to be notified for which incident.
  • Limited visibility into incident history for management and post-mortems.

Off-the-shelf ticketing tools existed, but many were not tailored to the specific needs of an IIG NOC: link-centric incidents, upstream/downstream parties, and regulatory visibility. A prototype was needed to show what a customised system could look like.

Challenge

Problem

The key question was:

“Can we make IIG incidents trackable, auditable, and automatically communicated to the right people without buying and integrating a heavy ITSM suite?”

Concretely, we needed:

  • A single place to open, update, and close incidents.
  • Automatic email notifications to relevant stakeholders on status changes.
  • A simple, adaptable system that could be demonstrated quickly to decision makers.
Operating Environment

Constraints & Requirements

  • Prototype-first: focus on a working demonstration rather than a multi-year IT project.
  • Reuse existing tools: leverage osTicket and PHP rather than building an entire system from scratch.
  • IIG-specific fields: support link IDs, circuits, providers, and impacted customers in the ticket model.
  • Low friction: NOC engineers should be able to use it with minimal training.
Execution

Implementation Highlights

1) Customising osTicket for IIG incidents

  • Installed and configured osTicket as the base ticketing platform, running on PHP.
  • Added custom fields for IIG context: link or circuit ID, upstream provider, customer group, and affected services.
  • Structured ticket categories and priorities around typical IIG events (link down, degradation, planned maintenance, capacity upgrades).

2) Email-based stakeholder notifications

  • Configured SMTP and email templates so ticket updates (open, update, resolve) triggered notifications to relevant stakeholders.
  • Used ticket properties (category, customer, provider) to decide who should be copied on each notification.
  • Ensured notifications included key incident details so recipients did not need to log in to see the essentials.

3) Lightweight workflows for NOC engineers

  • Simplified the ticket creation form to the fields NOC engineers actually needed to fill quickly during incidents.
  • Set default values and templates for common incident types to speed up creation.
  • Enabled email-to-ticket flow so some incidents could be opened by sending an email to a dedicated address.

4) Demonstration & iteration

  • Prepared sample incidents and notification scenarios to demo the system to operations and management.
  • Collected feedback on field names, categories, and email content to align with existing processes.
  • Showed how the system could be extended later for SLAs, reports, and deeper integration with monitoring tools.
The prototype proved that a relatively small amount of engineering on top of osTicket could create an IIG-aware incident tool with targeted stakeholder notifications — without needing a full-blown ITSM deployment.
Outcomes

Impact & Outcomes

As a prototype, the system’s primary impact was to demonstrate feasibility and shape expectations for a production-ready solution:

  • Showed how IIG incidents could be formalised into tickets with consistent fields and history.
  • Illustrated the value of automatic, structured email notifications vs ad-hoc mailing lists.
  • Helped operations and management visualise a path toward better incident visibility and reporting.
  • Established a technical baseline on top of osTicket that could be hardened and extended later.
Reflection

Key Learnings

  • Even a prototype can change how NOC teams think about incident management and communication.
  • Customising an existing open-source tool (osTicket) is often the fastest route to a working demo in infrastructure environments.
  • IIG-specific fields and flows matter: generic IT ticketing language doesn’t always fit network operations.
  • Automated, targeted notifications reduce noise: stakeholders get the right updates instead of massive CC lists.