Control the core
One source of truth for current and future capacity, with clear ownership and freshness.
Build the operational backbone before scale makes the current risk larger.
SPYRE's business depends on matching high-value capacity requirements with fast-changing global inventory. The current workbook contains valuable intelligence, but the surrounding process relies on manual updates, disconnected opportunity tracking and individual employee knowledge.
Proposal vision
Transform SPYRE's spreadsheet-driven inventory process into an AI-powered Data Centre Capacity Intelligence Platform that centralises inventory, connects opportunity management, automates proposal generation and provides real-time business intelligence for scalable growth.
✓
Recommended decision
Proceed with a platform-first Phase 1 focused on inventory, intake, search, lifecycle control, approvals, analytics and outputs. Keep Salesforce integration as a supported adapter, then activate it after the operational data model is validated.
Protect revenue
Approval-controlled reservations and lifecycle states prevent the same capacity being committed twice.
Create optionality
A broader platform supports future contracts, portal, CRM and intelligence without a re-platforming exercise.
The challenge is fragmented operations, not Excel itself.
The supplied workbook contains seven operating views, including a 48-column master site tab, supplier outreach tracking and custom opportunity lists. The future system must respect how operators actually share information while replacing manual coordination risk.
Demonstration data reconciliation
The working import stages 199 operational source rows, produces 156 canonical inventory records and isolates one incomplete stray source cell as an error rather than silently guessing its meaning.
Canonical inventory
156 sites
Master and unmatched list records available through one data model.
Availability detail
342 schedules
Quarter-specific MW values extracted from the supplied workbook.
Supplier network
93 operators
Including 27 supplier-contact records with outreach context.
Existing working views
5 custom lists
Every non-master client tab retained as a reusable curated list.
Manual inventory updates
→Capacity changes are entered by hand and can become stale quickly.
Guided import, validation and freshness controls
Workbook upload, row preview, source traceability, stale alerts and controlled commit.
Inconsistent names and formats
→Misspellings and mixed conventions reduce search reliability.
Canonical data model
Normalised operators, locations, lifecycle values and quarterly capacity schedules.
Tribal knowledge
→Important opportunity and inventory context is held by individuals.
Shared activity history
Ownership, opportunity shortlists, notes, approvals and audit history stay with the record.
Disconnected sales process
→Inventory and Salesforce continue independently after a match is found.
Connected opportunity workflow
Search, shortlist, reserve, propose and place capacity in one flow, with Salesforce adapter support.
No controlled lifecycle
→Available, reserved, LOI, sold and released capacity are not consistently enforced.
Database-protected lifecycle
Exclusive active reservation and manager approval reduce double-offer risk.
Manual proposal creation
→Teams copy, redact and format the same information repeatedly.
Versioned output generation
Print-ready briefs use an approved shortlist and capture the exact data/redaction snapshot.
Turn capacity intelligence into repeatable operating leverage.
Value will be measured against a discovery baseline. The platform is designed to reduce avoidable risk and manual effort while keeping SPYRE's relationship-led advantage.
No silent double commitment
One active reservation per site, controlled transitions and approval evidence.
Faster requirement-to-shortlist flow
Natural-language assisted search and reusable filters reduce spreadsheet scanning.
Less dependency on individual memory
Opportunity history, sources, ownership and actions become visible to authorised users.
Growth without repeating the same manual work
Structured intake, analytics and outputs support the planned team and customer growth.
Proposed value scorecard
Inventory currency
Freshness coverage
Percentage of active records verified within the agreed age threshold.
Operational speed
Intake turnaround
Time from receiving an update to an approved structured record.
Sales productivity
Shortlist cycle time
Time from requirement capture to a saved, reviewable site shortlist.
Output efficiency
Proposal preparation time
Time to generate a redacted brief from approved opportunity inventory.
Risk
Reservation conflicts
Conflicting exclusive reservation attempts blocked and explained by the system.
Governance
Audit coverage
Percentage of material lifecycle and output actions attributable to a named user.
One connected flow from operator update to placed capacity.
The system works with unstructured, relationship-sourced information. It does not require operators to adopt standard APIs before SPYRE gains operational control.
1
Receive
Email, PDF, spreadsheet, call or text update enters the intake queue.
2
Extract & review
Fields are proposed, normalised and reviewed by a SPYRE team member.
3
Publish
Approved data updates the central record with source and change history.
4
Match & control
Sales searches, shortlists and requests a reservation; manager approves.
5
Propose & connect
Versioned output is generated and opportunity status can synchronise with Salesforce.
→
Controlled inventory lifecycle
Available → Under Review → Under LOI → Reserved → Sold → Released. Each transition is validated; reservations require an opportunity; Sales requests are Manager-approved; and the database blocks a second active reservation against the same inventory.
Inventory foundation with the workflows required for daily use.
Phase 1 is designed as an operational product, not a visual mock-up. The working demonstration included with this proposal implements the core flow using the shared workbook.
Intake and normalisation
- XLSX, XLSM and CSV upload
- Multi-sheet parsing
- Field mapping and date normalisation
- Warnings, errors and duplicate preview
- Manager-controlled commit
Central inventory
- Operators, sites and 30+ attributes
- Quarterly MW schedules
- Source sheet and row traceability
- Manual create/update workflow
- Spreadsheet export
Lifecycle and approvals
- Available → Under Review → Under LOI → Reserved → Sold → Released
- Ownership and activity history
- Exclusive reservation protection
- Manager approval/rejection
- Sold/withdrawn exclusion
Search and shortlists
- Multi-attribute filters
- Natural-language assisted search
- Fit and freshness ranking
- Saved opportunity shortlists
- Imported custom lists retained
Analytics and alerts
- Capacity by geography/operator
- Quarterly availability curve
- Lifecycle distribution
- Freshness and data quality watch
- Team activity visibility
Proposal outputs
- Branded HTML capacity briefs
- Internal, commercial and anonymous profiles
- Field-level masking
- Output version and data snapshot
- Print/PDF-ready layout
TEDRA assistant
- Manager and Sales role-aware chat
- Answers grounded in permitted ERP data
- Capacity, opportunity and data-quality analysis
- Confirmed proposal and workflow actions
- Small, medium, full-screen and minimised modes
Phase 1 boundaries
| Included | Deferred / dependency |
|---|---|
| Web platform, responsive UI, backend API, PostgreSQL schema, two internal roles, imports, workflow, analytics, HTML outputs, audit and deployment package. | Production email/PDF/call transcription connectors require mailbox/source access and a confirmed AI service configuration. |
| Salesforce-ready integration configuration and object mapping view. | Live bi-directional Salesforce sync requires OAuth credentials, object definitions, sandbox access and Phase 3 approval. |
| Future CLM integration boundary and status model. CLM means Contract Lifecycle Management: supplier agreement stage, effective date, renewal and expiry. | Live CLM connection is Phase 2 and requires the product/API or structured export to be confirmed. |
| Internal manager and sales access. | External customer portal is Phase 2 and requires legal/security confirmation of operator confidentiality rules. |
Two internal views with clear permission boundaries.
Manager view
- View all inventory and sensitive operational fields
- Approve/reject inventory and lifecycle requests
- Commit or reject spreadsheet imports
- Configure integrations and users
- Access the complete audit trail
- Generate internal or redacted outputs
Sales view
- Search approved inventory
- Manage only assigned opportunities
- Create shortlists and outputs
- Submit inventory changes for approval
- Request reservation/lifecycle transitions
- No user, integration or audit administration
!
Role workshop required
The supplied scope keeps internal visibility definitions open. During discovery, SPYRE should confirm whether commercial rates, operator contacts and notes need additional field-level restrictions by user, team or opportunity.
Cloud-neutral services with a protected operational data layer.
The demonstration runs with Docker Compose. Production can use the same containers on a managed cloud platform with managed PostgreSQL, object storage, identity provider, monitoring and automated backups.
Source boundaryRelationship-sourced information
Excel / CSVCurrent workbook and external lists
Email / PDFPhase 1 connector after access
Call / Text notesManual or transcription input
Manual formDirect operational entry
Application trust boundaryAuthenticated and role controlled
Responsive web UIManager and sales workspaces
API & RBACSessions, validation and permissions
Workflow servicesImport, search, approval, reservation, output
TEDRA orchestrationGrounded query, evidence and confirmed actions
Audit & observabilityEvents, errors, metrics and alerts
Data boundaryEncrypted at rest and in transit in production
PostgreSQLInventory, opportunities, approvals and audit
Object storageSource files and generated outputs
Cache / job queueProduction asynchronous processing
Backup & recoveryPoint-in-time recovery policy
External integration boundaryAdapters with least-privilege credentials
SalesforceAccount, Contact, Opportunity, Revenue Line
CLMRead-only agreement status and dates
Identity providerSSO/MFA for production
BI / exportsApproved reporting interfaces
Plain-English flow: a user uploads or enters an update → the system extracts and validates fields → a human confirms the proposed changes → approved data is written to PostgreSQL with source and audit evidence → users search and shortlist → manager-approved reservation locks the inventory → outputs and optional CRM updates are generated from the same controlled data.
Technology selection
| Layer | Proposed technology | Why |
|---|---|---|
| Web application | Responsive HTML/CSS/JavaScript | Fast, accessible interface with no dependency on browser plugins. |
| Backend API | Python FastAPI | Strong validation, clear APIs, asynchronous capability and easy AI/data integration. |
| Operational database | PostgreSQL | Reliable concurrent transactions, JSON flexibility, row locking and reporting support. |
| File storage | S3-compatible object storage | Source traceability and versioned documents without placing files in database rows. |
| Deployment | Docker / managed container platform | Consistent local, test and production packaging with environment-based configuration. |
| Integration | REST/webhooks and scheduled jobs | Supports Salesforce, CLM and future systems without tight coupling. |
TEDRA turns operational data into answers and controlled action.
TEDRA — ThirdEye Data AI Assistant is available in both Manager and Sales views. It uses the signed-in user’s permissions, cites operational evidence, refuses unsupported answers and asks for confirmation before it changes ERP data or creates an output.
Ask and analyse
Capacity, schedules, suppliers, opportunities, approvals and data quality are queried within the user’s permitted view.
Ground and explain
Plain-English questions become transparent database filters. Results include evidence and matching inventory cards.
Confirm and act
TEDRA can create opportunities, shortlist sites, request or apply lifecycle changes, decide approvals and generate proposals—after confirmation.
TEDRA role and action matrix
| Capability | Sales view | Manager view | Control |
|---|---|---|---|
| Search and explain inventory | Approved permitted records | All approved operational records | Database evidence displayed |
| Opportunity and shortlist actions | Assigned opportunities | All opportunities | User confirmation + audit event |
| Lifecycle change | Creates approval request | Applies a valid transition | Transition rules + reservation lock |
| Approval decision | Not permitted | Approve or reject pending request | Manager role + confirmation |
| Proposal generation | Assigned opportunity shortlist | Any permitted opportunity | Versioned snapshot + redaction profile |
| Web research | Optional public research | Optional public research | External source is labelled; no ERP write |
Evaluation and control framework
| Control | How it works | Acceptance evidence |
|---|---|---|
| Representative data | Use SPYRE spreadsheets, PDFs, emails and notes representing common and difficult operator formats. | Agreed test set and field-level ground truth. |
| Field-level accuracy | Measure each extracted attribute separately; do not report a single unclear AI accuracy number. | Precision/recall or exact-match by critical field. |
| Confidence handling | Low-confidence, conflicting or missing values remain in review rather than being auto-published. | Exception queue and reviewer decisions. |
| Source traceability | Retain original source reference and mapped values for audit and correction. | Record-to-source linkage in UAT. |
| Drift monitoring | Track rejection/correction patterns when operator formats change. | Monthly quality trend and retraining rule. |
i
Grounding and hallucination control
The included TEDRA and Smart Match services use deterministic parsing, governed database queries and explicit evidence, so the demo works without an external model key. Unsupported questions are not guessed. Optional web research is isolated, labelled and never treated as SPYRE inventory evidence. Production can add an approved model provider behind the same retrieval, permission and confirmation controls.
Salesforce integration vs developing SPYRE’s own in-house system.
Option A — SPYRE-owned Capacity ERP
- SPYRE owns the specialist operational system of record
- Inventory schema evolves independently of CRM limitations
- Approvals, reservations, TEDRA, outputs and audit remain together
- Salesforce receives relevant account, opportunity and revenue data through an adapter
- Future CLM, portal and intelligence modules reuse the same foundation
Option B — Salesforce-led custom system
- Salesforce objects become the primary workflow surface
- Fewer systems for some sales users
- Specialist inventory, ingestion and reservation rules require custom objects/components
- Capacity product release cycle becomes dependent on CRM governance and licences
- Potentially higher coupling for future non-CRM capabilities
Recommendation rationale
| Decision factor | SPYRE-owned ERP | Salesforce-led custom system |
|---|---|---|
| Inventory data complexity and 30+ changing fields | Strong fit — purpose-built schema and UI | Possible with significant customisation |
| Unstructured intake and human review | Strong fit — native workflow | Requires custom intake/orchestration |
| High-ACV sales continuity | Connected by adapter | Strong fit — native opportunity process |
| Future CLM, portal and market intelligence | Strong fit — common platform services | More cross-cloud and custom component dependency |
| Long-term optionality | Higher | Lower if CRM customisation becomes the core |
Phase 1 production path — proposed 16 weeks.
This is a planning proposal, not a committed schedule. It should be confirmed after discovery, source-system access, security review and agreement on acceptance baselines.
MobiliseWeeks 1–2
Workshops, process maps, field dictionary, role matrix, success baseline.
UX & architectureWeeks 2–3
Wireframes, data model, security and integration design.
Data & intake foundationWeeks 3–6
Migration tooling, workbook parsing, validation, source traceability and review queue.
Inventory & workflowWeeks 5–9
Central records, lifecycle, approvals, reservations, ownership and audit.
Search, analytics & outputsWeeks 8–12
Smart Match, dashboards, saved lists, redaction and proposal generation.
Hardening & integrationsWeeks 11–14
Performance, security, monitoring, backup and adapter readiness.
UAT & go-liveWeeks 14–16
Migration rehearsal, user acceptance, training, release and hypercare start.
Phase gates
Gate 1 · Design
Field dictionary, workflows, roles, redaction rules and acceptance baseline approved.
Design sign-offGate 2 · Foundation
Representative workbook imports with traceability, validation and no unexplained record loss.
Data sign-offGate 3 · Workflow
Search-to-shortlist-to-reservation flow passes functional and concurrency tests.
Feature sign-offGate 4 · UAT
Agreed users complete end-to-end scenarios and all critical issues are closed.
UAT sign-offGate 5 · Release
Production environment, backup, monitoring, training and handover are complete.
Go-live approvalA focused cross-functional team with clear SPYRE ownership.
PM
Program / Project Manager
Scope, plan, risks, governance, stakeholder communication and acceptance tracking.
PO
Business Analyst / Product Owner
Requirements, field dictionary, process maps, backlog and UAT scenarios.
SA
Solution Architect
Technical design, security, integrations, scalability and engineering governance.
DE
Data Engineer
Migration, ingestion, quality rules, canonical model and data reconciliation.
AI
AI Engineer
Extraction/query services, evaluation, confidence and human-review controls.
BE
Backend Engineers
APIs, workflow, concurrency, database, integrations and audit services.
FE
Frontend Engineer / UX
Responsive application, usability, accessibility and role-based experiences.
QA
QA Engineer
Functional, integration, regression, performance, security and UAT support.
DO
DevOps / Security Engineer
CI/CD, environments, monitoring, backup, secrets and production readiness.
Proposed governance cadence
| Forum | Cadence | Purpose | Participants |
|---|---|---|---|
| Delivery stand-up | 3 times weekly | Progress, blockers and next actions | Delivery team |
| Product working session | Weekly | Workflow, field rules, demo and backlog decisions | SPYRE product/operations + ThirdEye |
| Steering review | Fortnightly | Scope, risks, dependencies, timeline and phase decisions | Sponsors and delivery leads |
| UAT triage | Daily during UAT | Defect priority, evidence and retest ownership | UAT leads, QA and engineers |
Acceptance is based on observable business behaviour.
Migration and import
- All agreed worksheets parsed
- Row totals reconciled with source
- Warnings/errors visible before commit
- Source link retained
- Duplicate handling evidenced
Lifecycle and approvals
- Role restrictions enforced
- Sales changes require approval
- Conflicting active reservation blocked
- Sold/withdrawn excluded from active results
- Every material change audited
Discovery and analytics
- Structured filters return expected records
- Natural-language interpretation is transparent
- Freshness affects ranking/alerts
- Totals reconcile to central data
- No unauthorised field exposure
Proposal generation
- Selected sites only
- Correct redaction profile
- Versioned snapshot retained
- Print layout is clean
- Changed inventory does not alter old output evidence
Non-functional test areas
| Area | Test focus | Target definition |
|---|---|---|
| Performance | Dashboard, search, imports, concurrent updates and output generation | Final thresholds agreed after production volume/concurrency discovery. |
| Availability | Health checks, restart behaviour, database failover and recovery | Service objective agreed for the selected hosting tier. |
| Security | Authentication, authorisation, secrets, injection, file upload, audit and backup access | No open critical/high issue at go-live. |
| Usability | Non-technical manager and sales workflows | Named UAT users complete agreed scenarios without engineering assistance. |
Confidential capacity data requires defence in depth.
Identity and access
SSO/MFA in production, role and field controls, session security, de-provisioning and least privilege.
Data protection
TLS, encrypted managed storage, secrets manager, restricted file access, backup and recovery testing.
Audit and monitoring
Named user events, central logs, application metrics, alerts, vulnerability and dependency review.
Deployment profiles
| Profile | Included | Use |
|---|---|---|
| Local demonstration | Docker Compose, application, PostgreSQL, Nginx and seeded workbook. | Evaluation, workshops and controlled demonstration. |
| Non-production cloud | Container service, managed database, object storage, central logs, test identity and CI/CD. | Development, integration, QA and UAT. |
| Production | Private networking, managed database HA, encrypted object storage, SSO/MFA, secrets, monitoring, backups, WAF/reverse proxy and release controls. | Daily multi-user operation. |
!
Production readiness boundary
The included Docker package is a functional demonstration and deployment baseline. Production release still requires environment-specific SSO, TLS/domain, secret rotation, vulnerability scanning, backup/restore testing, monitoring, capacity testing and final security approval.
Extend only after the Phase 1 data and redaction model prove reliable.
| Phase | Scope direction | Proposed planning range | Entry condition |
|---|---|---|---|
| Phase 2 — Contract & customer visibility | Read-only CLM status/dates, record linkage, alerts, isolated external portal, authorised documents and inherited redaction. | 10–12 weeks, subject to detailed scope | Phase 1 production validation; CLM API/export confirmed; legal/security decision on external exposure. |
| Phase 3 — Salesforce & extended intelligence | Bi-directional Account/Contact/Opportunity/Revenue Line sync, commission continuity, advanced analytics, proactive matching, mobile and market intelligence evaluation. | 10–14 weeks, subject to detailed scope | Salesforce sandbox/object model and integration ownership confirmed; Phase 1/2 data contracts stable. |
Important: These ranges are directional planning assumptions, not commitments. The supplied scope also states that Phase 2 and Phase 3 may change based on Phase 1 outcomes.
Make uncertainty visible before it becomes scope or delivery risk.
Inconsistent and incomplete source dataHighProfile the workbook, agree field criticality, keep exceptions visible, use human review and phase migration.
Rapid inventory stalenessHighVerification dates, aging thresholds, owner notifications and automatic exclusion rules for sold/withdrawn items.
Operator confidentiality exposureHighField-level redaction, role matrix, output profiles, legal review and Phase 2 isolation testing.
Salesforce or CLM API constraintsMediumValidate APIs/sandbox early, use adapter pattern, support export-based fallback and avoid core workflow dependency.
AI extraction over-trustMediumConfidence thresholds, source evidence, mandatory human confirmation and field-level evaluation.
User adoption and parallel spreadsheetsMediumImport/export remains easy, pilot with real users, make platform flow faster than manual work and retire the master gradually.
Concurrent reservation conflictControlledDatabase-level unique active reservation, transactional approval and clear conflict response.
Key assumptions and dependencies
- SPYRE remains the owner of inventory definitions, field rules, source files and acceptance decisions.
- Operators will continue sharing data in manual and semi-structured formats.
- The master workbook remains authoritative until migration and UAT sign-off.
- Named subject-matter users are available for weekly decisions and UAT.
- Production hosting, region, SSO, retention and compliance requirements will be confirmed in discovery.
- Salesforce object architecture remains stable before Phase 3 mapping begins.
- CLM system and integration method will be confirmed before Phase 2 scope is baselined.
- Commercially sensitive and personal data will be handled under the signed NDA and agreed access policy.
Price the confirmed work breakdown, not an assumed top-down number.
No budget, rates, hosting tier or licence selection was supplied. This proposal therefore does not invent a commercial commitment. A detailed effort and cost schedule should be issued after the discovery baseline and deployment choices are confirmed.
| Commercial component | Basis | Acceptance linkage |
|---|---|---|
| Discovery and solution baseline | Workshops, field dictionary, architecture, backlog, test baseline and delivery plan. | Gate 1 design sign-off. |
| Phase 1 implementation | Work-breakdown estimate by data, backend, frontend, AI, QA, DevOps, PM and architecture role. | Gates 2 and 3 feature/data sign-off. |
| Production deployment | Environment setup, security hardening, migration, training and release. | Gates 4 and 5 UAT/go-live approval. |
| Cloud and licences | Selected region, scale, availability, storage, AI usage, Salesforce/CLM licences and monitoring. | Actual third-party service selection. |
| Hypercare and support | Proposed four-week hypercare followed by agreed support/AMC tier. | Support plan and service levels. |
₹
Next commercial deliverable
After the discovery workshop, ThirdEye Data can provide a scope-linked estimate showing one-time implementation, recurring infrastructure/licence costs, support, payment milestones, assumptions and optional Phase 2/3 items.
17 · RECOMMENDED NEXT STEPS
Validate the working flow, then lock the Phase 1 baseline.
The attached Docker package is designed to make the next discussion concrete. SPYRE can test the manager and sales views, import a new workbook, create an opportunity, shortlist sites, request a reservation, approve it and generate a redacted capacity brief.
Prepared from: SPYRE Capacity Examples workbook; SPYRE Capacity Platform Scope & Requirements dated 17 July 2026; Technology & AI Roadmap dated 6 May 2026; and the supplied meeting summary/problem statement. Proposed timelines, team structure and delivery approach require joint confirmation.