AI Opportunity Pipeline

AI Strategy
ISYS6020
Business Case
A register of candidate AI use-cases at CloudCore Networks, scored on value, effort, risk and data-readiness to support a defensible ‘should we?’ AI-strategy business case.

ISYS6020 — AI in Business Strategy (Semester 1, 2027)

This register is the front-end of the AI-strategy decision pipeline. Its job is not to pick a winner — it is to make the candidate set, the scoring criteria, and the assumptions visible and challengeable before any capital is committed.

The CEO’s AI Readiness Assessment request (Board Memo DOC-EXEC-012, 15-01-2026) frames the question this work feeds: “Is CloudCore Networks ready to successfully implement AI, and what organisational changes would be required?”

1. Why a pipeline, not a wish-list

CloudCore is a ~$45M AUD managed-cloud provider with roughly 47 staff, ~500 clients, and a product portfolio of DataVault (storage & backup), Analytics Pro (BI), and CloudSync (file sync), delivered across the Cloud Hosting, Managed Services and Security & Compliance service lines. The leadership appetite for AI is real — enterprise clients now ask about an “AI roadmap” — but so is the caution: industry research cited by the CEO puts the enterprise-AI project failure rate at 70–85%, and the failures are rarely technical.

A disciplined pipeline forces four disciplines that a wish-list does not:

  1. State the problem before the tool. Every entry starts with a measurable business pain, not a model.
  2. Score on consistent criteria so opportunities are comparable rather than championed by whoever shouts loudest.
  3. Make data-readiness explicit. An opportunity with no usable data is not an opportunity yet — it is a data programme.
  4. Separate “should we?” from “can we?” A high-value, low-effort idea that breaches governance is still a “no”.

2. Scoring framework

Each opportunity is scored on a 1–5 scale across five lenses. The composite Priority is a heuristic for sequencing, not an investment decision — it deliberately cannot capture strategic fit or risk appetite, which the cost–benefit and governance pages handle.

Dimension 1 (Low) 3 (Medium) 5 (High)
Strategic value (V) Nice-to-have; marginal revenue/cost impact Material to one service line or KPI Moves a company-level KPI (margin, churn, NPS)
Implementation effort (E) >9 months, deep platform change 3–9 months, cross-team <3 months, single team, buy/configure
Confidence in benefit (C) Anecdotal Pilot evidence in comparable firms Proven in our own data
Data readiness (D) No usable dataset; large clean-up Exists but fragmented/dirty Clean, governed, in one place
Governance risk (R) Low — internal, explainable, reversible Medium — client-touching or regulated data High — automated decisions on personal data

Reading the composite. Priority ≈ \((V \times C \times D) / E\), with R acting as a modifier rather than an input: a risk score of 5 caps any opportunity at “Pilot only” regardless of its headline score. This mirrors the CEO’s own framing — value without readiness is the most expensive kind of failure.

The register below is ordered by Priority. Effort is scored “high number = hard”, so a low-effort, high-value, well-data-backed idea floats to the top.

3. The register

3.1 Support-ticket triage & intelligent routing

Problem. The support dataset (data/cloudcore_support_tickets.csv, 400 tickets) shows wide resolution-time variance by priority: Critical tickets close in 2.8 hours, High in 5.2 hours, but Low-priority tickets drift to 33.3 hours on average and Medium to 12.1 hours. Each ticket also carries a free-text ticket_text field that is currently read by a human and never used to auto-route, classify or suggest a resolution.

  • Value (V = 5). Text-based triage classifies and routes each ticket on creation, compressing first-touch time on Critical/High cases and surfacing the long-tail Low tickets for deliberate handling; it directly defends the 99.9% uptime SLA the company markets. Mis-routed urgent cases are the ones that escalate into churn.
  • Effort (E = 2). Triage/classification is a mature, well-understood task; configurable off-the-shelf (Zendesk AI, Freshdesk Freddy, or a classifier on the existing ticket schema).
  • Risk (R = 2). Internal operational use; a human agent still owns the response. Low personal-data exposure provided ticket bodies are masked.
  • Data available (D = 4). Category, Subcategory, Priority, Product, Outcome, Resolution_Hours and Customer_Segment are all present and structured. Six months is thin for seasonality but adequate for a routing model.
  • Confidence (C = 4). Proven pattern across the industry; CloudCore’s own labels make supervised training straightforward.

Priority: High. Recommended first pilot — high value, low effort, clean data, low risk.

3.2 Customer churn prediction & retention targeting

Problem. The customer dataset (data/cloudcore_customers.csv, 400 clients) shows 148 clients (37%) carry churn_flag = 1 — an at-risk pool worth roughly $14.6M in annualised recurring revenue. Churned clients look measurably different before they leave: lower satisfaction (avg 2.49 vs 2.92 for retained), higher support load (4.2 tickets/6mo vs 3.1), and lower MRR ($8,210 vs $10,825).

  • Value (V = 5). Retention is the single highest-leverage financial lever at a ~$45M ARR business: recovering even a tenth of the at-risk cohort protects ~$1.5M in annualised revenue.
  • Effort (E = 3). A churn model needs feature engineering, a labelled outcome, and — critically — a retention workflow (offers, outreach) that does not yet exist as a managed process.
  • Risk (R = 3). Uses customer attributes (industry, size, tenure, usage) which may be personal/business-sensitive; predictions must inform outreach, not auto-cancel services.
  • Data available (D = 4). satisfaction_score, support_tickets_6m, tenure_months, industry, region, monthly_recurring_revenue, plus an explicit labelled churn_flag — a near-ideal supervised-learning schema, further enrichable by joining the free-text support and review (data/cloudcore_reviews.csv) datasets.
  • Confidence (C = 4). Strong label, strong correlates; main uncertainty is whether a retention action converts a prediction into saved revenue.

Priority: High. Strong candidate, but gated on building the retention workflow alongside the model.

3.4 Automated compliance evidence collection

Problem. CloudCore is pursuing ISO 27001 certification (the public site overclaims “certified” — an inconsistency to treat as a finding, not a feature). Evidence collection across access reviews, change logs, vendor attestations and policy currency is largely manual, slow, and audit-painful.

  • Value (V = 4). Compresses audit preparation time, reduces evidence gaps, and accelerates the certification timeline the business case for ISO 27001 depends on.
  • Effort (E = 4). Requires integration with multiple systems (IAM, ticketing, change management, asset register) and a defensible audit trail for the evidence itself.
  • Risk (R = 3). The output of this system is itself evidence presented to an auditor — the automation must be more reliable than the manual process it replaces, or it undermines the certification case.
  • Data available (D = 3). Source artefacts exist (policies, logs, registers) but are scattered across formats and not machine-correlated.
  • Confidence (C = 3). Valuable, but the integration breadth makes this a programme, not a pilot.

Priority: Medium. High strategic value but heavier lift — sequence after a successful pilot proves delivery discipline.

3.5 Log anomaly & threat detection

Problem. The September 2025 breach (~250,000 records, detected 12-09-2025) exposed delayed detection as a contributing factor. Security operations rely on rule-based alerting and human review of logs.

  • Value (V = 5). Directly addresses the highest-impact event in the company’s recent history; security is a marketed service line, so detection quality is both defence and product.
  • Effort (E = 4). Requires log centralisation, baseline behaviour modelling, alert tuning, and a SOC workflow to act on output.
  • Risk (R = 4). False positives create alert fatigue; false negatives are catastrophic. Automated response would be high-risk; automated detection with human response is the sane scope.
  • Data available (D = 3). Logs exist but the post-breach review suggests completeness, retention and correlation gaps that precede any model.
  • Confidence (C = 3). Mature domain, but effectiveness depends entirely on log quality that is not yet confirmed.

Priority: Medium. Strategically essential, but must follow log-quality remediation — see the technology landscape gap analysis.

3.6 Infrastructure cost forecasting

Problem. CloudCore carries real infrastructure cost (servers, workstations, networking, software suites — see data/cost_analysis_2026.csv) and quarterly budgets (data/budget_2026.csv) that are set discretely rather than modelled continuously. Capacity and licence costs scale with client growth.

  • Value (V = 3). Improves margin discipline and budget accuracy; useful but not transformative at current scale.
  • Effort (E = 2). Forecasting on structured financial time-series is a standard analytics task; achievable with existing tools or lightweight ML.
  • Risk (R = 1). Internal, low-stakes, explainable; a wrong forecast is corrected next quarter.
  • Data available (D = 3). Budget, cost-analysis and forecast datasets exist but are coarse (few categories, short horizon) and would benefit from enrichment before modelling.
  • Confidence (C = 3). Pattern is sound; granularity of current financial data limits accuracy.

Priority: Medium. Low-risk, low-effort — a good “quick win” to build analytics muscle, but modest standalone value.

3.7 Predictive capacity & maintenance forecasting

Problem. The two data centres (Perth primary at 4 Millrose Drive, Malaga; Sydney DR) and client workloads need capacity planning. Unplanned capacity exhaustion or hardware failure risks SLA breach; the CEO flagged “predictive maintenance” in the board memo.

  • Value (V = 4). Protects the 99.9% uptime SLA and avoids both over-provisioning (cost) and under-provisioning (reputation).
  • Effort (E = 4). Requires telemetry/SCADA-style sensor or utilisation data that is not currently exposed as a clean dataset.
  • Risk (R = 2). Internal operations; human-in-the-loop on any provisioning decision.
  • Data available (D = 2). The customer dataset captures monthly_recurring_revenue and support_tickets_6m at the client level, but there is no published infrastructure-telemetry dataset (utilisation, capacity, hardware health) to model against yet.
  • Confidence (C = 2). Conceptually strong, data-blocked today.

Priority: Low (now) → Medium (after telemetry). A genuine opportunity that is gated on a data source that does not yet exist as an analysable artefact.

3.8 Sales lead scoring & demand forecasting

Problem. The sales dataset (data/cloudcore_sales.csv, 180 quarter-product-region records) shows a lopsided portfolio — DataVault $18.2M, Analytics Pro $13.6M, CloudSync $10.5M — with regional performance mixed. Lead prioritisation is currently rep-led rather than model-led.

  • Value (V = 3). Focuses sales effort on high-conversion leads and declining-but-recoverable regions; useful incremental lift.
  • Effort (E = 3). Needs a CRM with structured lead data (currently partial) and a defined “converted” outcome label.
  • Risk (R = 2). Internal commercial use; modest personal-data exposure on prospect records.
  • Data available (D = 3). Sales history is structured but lead-level attributes (source, engagement, firmographics) are thinner than ideal.
  • Confidence (C = 3). Proven pattern; benefit depends on CRM data maturity that is still maturing (see the systems-analysis workstream).

Priority: Low–Medium. Valuable once CRM data matures; deprioritise until that baseline exists.

4. Priority matrix

The quadrant below plots strategic value against implementation effort, with marker size reflecting data-readiness. The upper-left (high value, low effort) is where pilots should begin.

quadrantChart
    title AI opportunity portfolio — value vs effort
    x-axis Low effort --> High effort
    y-axis Low value --> High value
    quadrant-1 Strategic bets (sequence carefully)
    quadrant-2 Prioritise for pilots
    quadrant-3 Avoid / defer
    quadrant-4 Tempting traps
    Support-ticket triage: [0.25, 0.92]
    Churn prediction: [0.45, 0.95]
    RAG policy search: [0.30, 0.78]
    Compliance evidence: [0.70, 0.72]
    Log anomaly detection: [0.72, 0.90]
    Cost forecasting: [0.28, 0.52]
    Predictive maintenance: [0.78, 0.74]
    Lead scoring: [0.50, 0.50]

5. Summary scoreboard

# Opportunity Value Effort Confidence Data Risk Priority
3.1 Support-ticket triage 5 2 4 4 2 High
3.2 Churn prediction 5 3 4 4 3 High
3.3 RAG policy search 4 2 4 5 3 High
3.4 Compliance evidence 4 4 3 3 3 Medium
3.5 Log anomaly detection 5 4 3 3 4 Medium
3.6 Cost forecasting 3 2 3 3 1 Medium
3.7 Predictive maintenance 4 4 2 2 2 Low (data-gated)
3.8 Lead scoring 3 3 3 3 2 Low–Medium

6. From register to business case

This register answers “what could we do?”. Three of the eight opportunities are carried forward to a worked cost–benefit analysis: support-ticket triage, churn prediction, and RAG policy search — chosen because together they span buy vs build, operational vs commercial value, and low vs medium governance risk, making them a representative portfolio for the strategy decision.

Two further lenses shape the final “should we?”:

A note on what this register is not. It is not a forecast of benefits, a budget, or a procurement decision. Every “High” above is permission to analyse further — not permission to spend. The CEO’s explicit caution is that a premature $500K commitment that fails on readiness is the failure mode to avoid.