Chapter 4 · ProjectVIEW ERP Master SaaS Framework Support is delivered by the Provider Service Desk through an embedded in-application ticketing system, a dedicated WhatsApp Business group, telephone and email, all available 24×7×365 and aligned with ITIL 4. Chapter 4 covers the ticket lifecycle, four-level technical escalation, preventive maintenance, change management (Standard, Normal, Emergency) and release management — from sprint releases to major-version upgrades. 24×7×365service desk channels 4support channels L1–L4technical escalation levels ITIL 4process alignment 4.1 Overview This Section defines the operational support framework through which the Provider delivers day-to-day support services for the Platform. It establishes the structure, processes, and responsibilities for incident management, ticket lifecycle management, preventive maintenance, technical escalation, and operational change control. All support processes align with ITIL 4 best-practice guidelines and leverage the Provider’s omnichannel support model to ensure rapid, traceable, and context-rich service delivery across all communication channels. Support services apply to the Production Environment and, where explicitly agreed in the Commercial Contract, the Staging Environment. The Provider shall maintain documented support procedures and make them available to the Customer upon reasonable request. All support activities are recorded and tracked through the Platform’s embedded ticketing system, providing end-to-end visibility for both the Provider and the Customer. 4.2 Provider Service Desk (PSD) The Provider Service Desk (PSD) is the single point of contact for recording, managing, and resolving all technical support-related tickets, including Incidents, Service Requests, Problems, and Change Requests raised by the Customer. The PSD operates an omnichannel support model that unifies formal ticketing, real-time messaging, and traditional communication channels into a single, traceable support workflow. The PSD coordinates with the Customer’s designated IT liaison for all support and maintenance services. 4.2.1 Embedded Ticketing System The Platform incorporates a native embedded ticketing system within the ProjectVIEW ERP application itself. This integrated ITSM capability allows Authorised Users to raise, track, and manage support tickets directly from within the Platform without leaving the ERP environment. The embedded ticketing system provides: (a) In-Application Ticket Logging: Users raise tickets directly within the ProjectVIEW ERP interface, with automatic capture of contextual information including the active module, screen, user role, and any associated data records; (b) Real-Time Status Tracking: A unified dashboard within the ERP displays all open, in-progress, and resolved tickets with full lifecycle visibility, SLA countdown timers, and priority indicators; (c) Bi-Directional Communication: Threaded conversations between the Customer and the assigned support engineer occur within the ticket itself, maintaining a complete chronological audit trail; (d) Attachment & Evidence Capture: Users attach screenshots, error logs, documents, and screen recordings directly to tickets, eliminating context loss during escalation; (e) SLA Metrics & Reporting: Built-in SLA tracking with automated alerts when response or resolution targets approach threshold, along with real-time reporting on ticket volumes, categories, and resolution performance; (f) Knowledge Base Integration: The ticketing system links to the Provider’s embedded knowledge base (wiki), surfacing relevant articles and known solutions during ticket creation to enable self-service resolution; (g) Automated Notifications: Email and in-application notifications are triggered at each ticket state transition (logged, acknowledged, assigned, updated, resolved, closed), keeping all stakeholders informed. The embedded ticketing system serves as the system of record for all support interactions. Regardless of the channel through which an issue is initially reported (telephone, email, WhatsApp, or in-application), all tickets must be formalised within the embedded ticketing system to ensure SLA measurement, auditability, and compliance. 4.2.2 Omnichannel Support Channels The Provider shall provide the Customer with access to the PSD through the following channels: Channel Availability Ticket Types Use Case Embedded Ticketing (In-Application) 24 × 7 × 365 All types Primary channel. Authorised Users raise tickets directly within ProjectVIEW ERP with automatic context capture. Recommended for all non-emergency issues. WhatsApp Business (Dedicated Group) 24 × 7 × 365 P3, P4, Enquiries Shared WhatsApp group between the Customer’s key users and the Provider’s assigned consultants for expedient informal communication, quick enquiries, and ad-hoc guidance. Messages requiring formal action are escalated to the embedded ticketing system. Telephone 24 × 7 × 365 P1, P2 Priority-1 (Critical) and Priority-2 (Urgent) incidents requiring immediate attention. The Customer shall report P1 and P2 incidents by telephone to ensure prompt escalation. Email 24 × 7 × 365 All types Formal ticket logging for all ticket types. Emails sent to the designated PSD address are automatically ingested into the embedded ticketing system and assigned a ticket reference. 4.2.3 WhatsApp Business Support Channel The Provider establishes a dedicated WhatsApp Business group for each Customer, connecting the Customer’s designated key users with the Provider’s assigned consultants. This channel operates as an expedient informal communication layer to complement the formal ticketing system. The WhatsApp channel is governed by the following rules: (a) Scope: Quick enquiries, usage guidance, clarification of functionality, informal discussion of potential change requests, and preliminary reporting of non-critical issues. The WhatsApp channel is not a substitute for formal ticket logging; (b) Formalisation Rule: Any issue communicated via WhatsApp that requires formal tracking, SLA measurement, code change, configuration modification, or escalation must be logged as a ticket in the embedded ticketing system by the Provider consultant within 4 hours of identification. The Customer shall be notified of the ticket reference; (c) SLA Exclusion: SLA response and resolution timers commence upon formalisation of the ticket in the embedded ticketing system, not upon initial WhatsApp communication; (d) Data Protection: Participants shall not share Personal Data, credentials, database content, or Confidential Information via WhatsApp. The Provider shall brief all participants on data handling obligations under the applicable Data Protection Laws (ref. Section 17); (e) Retention: WhatsApp messages are retained in accordance with the Provider’s data retention policy. For auditability purposes, any substantive technical discussion or decision made via WhatsApp shall be summarised in the corresponding ticket record; (f) Group Membership: Group membership is managed jointly. The Provider shall update group membership within 2 Business Days of any personnel change. The Customer shall notify the Provider of any changes to its designated key users. 4.2.4 PSD Operating Hours & Availability The PSD operates 24 hours per day, 7 days per week, 365 days per year for ticket logging across all channels. Resolution activities follow the operation windows defined in the SLA Response & Resolution Matrix (Section 3.6). UAE/Greece/Philippines Government public holidays are excluded from Business Day calculations but P1 incidents are attended to regardless of public holiday schedules. 4.2.5 PSD Responsibilities The PSD shall: (a) Record all Customer-reported incidents and service requests in the embedded ticketing system, assigning a unique ticket reference number with automatic contextual metadata capture; (b) Agree with the Customer the priority level to be allocated to each ticket in accordance with the Incident Priority Classification defined in Section 3.5; (c) Provide the Customer with acknowledgement of e-ticket post receipt; (d) Manage all necessary escalations to restore the Services within the applicable Service Level targets; (e) Provide the Customer with regular progress updates via the ticketing system, telephone, email, or WhatsApp at mutually agreed intervals; (f) Advise the Customer upon ticket resolution, including a brief description of the root cause, corrective action taken, and whether the ticket is to be closed or requires further action; (g) Where possible, first attempt to resolve tickets remotely. Where remote resolution is not feasible, the Provider shall dispatch a qualified engineer to the Customer’s premises as required; (h) Formalise any issues initially communicated via WhatsApp or telephone into the embedded ticketing system within 4 hours; (i) Maintain a complete audit trail of all ticket interactions, status changes, and resolution activities within the embedded ticketing system. 4.3 Ticket Lifecycle Management All support interactions follow a structured ticket lifecycle managed through the Platform’s embedded ticketing system to ensure traceability, accountability, and compliance with the SLA targets. The lifecycle applies to all ticket types: Incidents, Service Requests, Problems, and Change Requests, regardless of the channel through which the issue was initially reported. 4.3.1 Ticket Logging When a ticket is logged by the Customer, the following minimum information shall be provided to the PSD: (a) Customer name and contract reference ( auto-populated when tickets are raised via the embedded ticketing system); (b) Name and contact details of the person reporting the issue; (c) A clear description of the issue, including steps to reproduce (for incidents) or the nature of the request (for service requests); (d) The affected module(s) and number of impacted Authorised Users; (e) Any diagnostics, screenshots, or error messages obtained by the Customer; (f) The Customer’s proposed priority level for the ticket. 4.3.2 Ticket Processing Workflow The following procedure defines the method by which a ticket is processed from initial logging through to closure: Step Action Responsibility 1 Customer logs a ticket via the embedded ticketing system (in-application), email, telephone, or WhatsApp. Tickets raised via the embedded system automatically capture module context, screen, user role, and related data records. Customer 2 PSD receives the ticket in the embedded ticketing system (or formalises it from telephone/WhatsApp within 4 hours), assigns a unique ticket number, and allocates the ticket to the appropriate support engineer based on module expertise and priority. PSD 3 PSD acknowledges the ticket via the embedded ticketing system and email, containing: ticket reference number, assigned engineer name, priority classification, and expected response time. PSD 4 The assigned engineer contacts the Customer within the applicable response time, confirms the issue details, and begins diagnosis. Remote troubleshooting is attempted first. Support Engineer 5 The engineer provides the Customer and PSD with an estimated time to resolution or, if applicable, confirms the ticket has been resolved remotely. Support Engineer 6 Upon resolution, the engineer completes a Service Report detailing: ticket reference, time taken, root cause analysis, corrective action, and any preventive recommendations. Support Engineer 7 PSD notifies the Customer of resolution via email, provides the Service Report, and requests confirmation to close the ticket or flags any required follow-up actions. PSD 8 Customer confirms resolution or requests further action. Ticket is closed in the embedded ticketing system with full audit trail preserved. Customer / PSD Ticket Reopening: If the Customer reports that the same issue recurs within 5 Business Days of ticket closure, the original ticket shall be reopened with the same priority classification within the embedded ticketing system. Reopened tickets are counted as a single incident for SLA measurement purposes. 4.3.3 Ticket Classification Tickets are classified into the following categories: Ticket Type Definition Examples Incident An unplanned interruption or reduction in quality of the Platform or a component thereof. System unavailable, module crash, data not saving, report generation failure, login errors. Service Request A formal request from the Customer for something to be provided, changed, or actioned that is not an incident. New user creation, password reset, access permission change, report configuration, data export. Problem The underlying root cause of one or more incidents, identified through trend analysis or post-incident review. Recurring timeout errors traced to database indexing, repeated memory overflow from specific module. Change Request A formal request for modification to the Platform’s configuration, functionality, or integration. New field addition, workflow modification, API integration, report customisation, module enhancement. 4.4 Technical Escalation The Provider maintains a structured technical escalation matrix to ensure that tickets are escalated to the appropriate level of expertise and management authority when resolution is not achieved within the applicable Service Level targets or when the severity of the issue requires senior intervention. 4.4.1 Escalation Levels Level Escalation Trigger Escalated To Target Action Level 1 First Response Ticket logged and assigned. Initial diagnosis and remote troubleshooting. PSD Support Engineer Diagnose, apply known fix, or escalate within response time. Level 2 Specialist Level 1 unable to resolve within MTTR target, or issue requires deep module expertise. Senior Support Engineer / Module Specialist In-depth analysis, code-level debugging, configuration review, hotfix development. Level 3 Engineering Level 2 unable to resolve, or issue involves core platform architecture, database, or infrastructure. Development Team Lead / Principal Engineer Code modification, database remediation, architectural intervention, patch release. Level 4 Management Resolution exceeds 2× MTTR target, or P1 incident not resolved within 8 hours, or Customer requests management escalation. Service Delivery Manager / CTO Resource reallocation, executive communication, recovery plan activation, post-incident review. 4.4.2 Customer-Initiated Escalation The Customer may escalate a ticket at any time by contacting the PSD and requesting escalation. The Provider shall update the Escalation Contact Matrix at least annually or upon any change in personnel, and shall provide the current matrix to the Customer within 5 Business Days of any update. The Escalation Contact Matrix shall include name, designation, direct contact numbers, and email address for each escalation level. For P1 (Critical) incidents, the Provider shall automatically escalate to Level 2 within 30 minutes if the initial response has not identified a resolution path, and to Level 3 within 2 hours if the incident remains unresolved. The Customer’s designated IT liaison and the Service Delivery Manager shall be notified of all P1 escalations in real time. 4.5 Preventive Maintenance The Provider shall perform monthly preventive maintenance on all Platform components within the Customer’s dedicated private sovereign environment. Preventive maintenance is conducted proactively to identify and remediate potential issues before they impact service availability or performance. 4.5.1 Preventive Maintenance Scope Monthly preventive maintenance shall include, but is not limited to: (a) Infrastructure Health Checks: Virtual machine performance monitoring, disk utilisation, memory allocation, CPU load analysis, and network latency assessment; (b) Database Maintenance: Index rebuilding, statistics updates, transaction log management, integrity checks (DBCC CHECKDB), and storage optimisation; (c) Security Patching: Review and application of operating system, middleware, and database security patches in accordance with the Provider’s patch management policy (see Section 3.2.3 for maintenance windows); (d) Backup Verification: Validation of backup job completion, backup integrity testing, and restore drill execution (quarterly); (e) Application Health: Module-level functional checks, API endpoint validation, integration monitoring, and error log review across all active ProjectVIEW ERP modules; (f) SSL/TLS Certificate Management: Certificate expiry monitoring, renewal, and rotation; (g) Capacity Review: Assessment of current resource utilisation against provisioned capacity, with proactive scaling recommendations where utilisation exceeds 75% threshold. 4.5.2 Preventive Maintenance Reporting Upon completion of each preventive maintenance cycle, the Provider’s maintenance engineer shall submit a Preventive Maintenance Report to the Customer within 3 Business Days. The report shall include: Date and duration of maintenance activity; Components inspected and actions performed; Identified risks or anomalies with recommended remediation; Current vs. provisioned resource utilisation metrics; Upcoming patch and update schedule; Confirmation of backup verification results. 4.6 Change Management All modifications to the Platform’s configuration, functionality, or infrastructure are governed by a formal Change Management process designed to minimise risk to the Production Environment. Changes are classified and managed in accordance with ITIL Change Management best practices. 4.6.1 Change Classification Change Type Definition Approval Deployment Path Standard Pre-authorised, low-risk changes with established procedures (e.g., user account creation, routine configuration). Pre-approved Direct to Staging → UAT → Production Normal Non-routine changes requiring assessment, planning, and approval (e.g., new module configuration, API integration, workflow modification). Change Advisory Board (CAB) or Service Delivery Manager Development → Staging → UAT → Customer Sign-off → Production Emergency Urgent changes required to restore service or address a critical security vulnerability. Bypasses standard CAB review. Service Delivery Manager with post-implementation CAB review Development → Production (with retrospective UAT and documentation) 4.6.2 Change Management Workflow All Normal and Emergency changes follow this workflow: (a) Request: The Customer or Provider submits a Change Request via the PSD with description, business justification, affected modules, and requested implementation date; (b) Assessment: The Provider performs an impact assessment covering: technical risk, affected users, rollback plan, estimated effort, and dependencies; (c) Approval: The Change Advisory Board (or Service Delivery Manager for emergency changes) reviews and approves or rejects the change; (d) Implementation: The change is developed and deployed to the Staging Environment; (e) UAT: The Customer performs Universal User Acceptance Testing in the Staging Environment. A minimum of 5 Business Days is provided for UAT. Written sign-off is required (ref. Section 3.3.1); (f) Deployment: Upon Customer UAT sign-off, the change is deployed to Production during an agreed maintenance window; (g) Post-Implementation Review: The Provider monitors the change for 5 Business Days post-deployment and provides a closure report to the Customer. Rollback: Every Normal and Emergency change shall include a documented rollback plan. If the change causes an unplanned service degradation, the Provider shall execute the rollback within 2 hours of identifying the issue and notify the Customer immediately. 4.6.3 Change Auditability All changes to the Platform’s configuration, codebase, and infrastructure are logged in the Provider’s Change Management System. Each change record includes: requester, description, risk assessment, approval chain, implementation date, implementing engineer, test results, and post-implementation status. Change logs are available to the Customer upon request and are included in the Quarterly Service Review (ref. Section 3.10.2). 4.7 Software Release Management The Provider manages all software deliveries through a controlled release management process that distinguishes between two fundamentally different delivery types: Releases/Updates (incremental, client-specific, frequent) and Upgrades (major version, product-wide, annual). This distinction ensures that day-to-day agile delivery for the Customer does not conflict with the Provider’s broader product roadmap. 4.7.1 Releases & Updates (Incremental – e.g. v11.xx) Releases and updates are incremental deliveries within the current major version of the Platform (e.g., v11.01, v11.02, v11.15). They address change requests, bug fixes, configuration adjustments, and minor functional enhancements specific to the Customer’s implementation. Releases are delivered using an Agile execution methodology tailored to the operational cadence of the Customer. Agile Sprint Methodology: The Provider operates in short-cycle sprints averaging 3 Business Days per sprint. Each sprint delivers a defined set of change requests, bug fixes, or configuration changes agreed with the Customer at sprint planning. The sprint cycle is as follows: Phase Duration Activities Responsibility Sprint Planning 0.5 day Provider and Customer review the backlog, prioritise items, and agree on the sprint scope. Items are drawn from: open tickets, change requests, bug reports, and Customer-requested enhancements. Provider + Customer Development 1.5–2 days The Provider’s development team implements the agreed changes on the Customer’s dedicated client branch in the Git repository. Unit testing is performed by DANAOS Support Engineers who are subject-matter experts within their domain. Provider Staging Deployment 0.25 day Completed sprint items are deployed to the Staging Environment via the Provider’s CI/CD pipeline for Customer validation. Provider UAT & Sign-Off Per Section 3.3.1 The Customer performs Universal User Acceptance Testing on the sprint deliverables. Written sign-off is required before production deployment. Minimum 5 Business Days for UAT. Customer Production Deployment 0.25 day Upon UAT sign-off, the sprint release is deployed to Production during an agreed maintenance window. Post-deployment monitoring is active for 2 Business Days. Provider Sprint Retrospective Ad hoc Brief review of sprint outcomes, issues encountered, and process improvements. Findings feed into the CSI register (ref. Section 4.10). Provider + Customer Release Versioning: Each incremental release is assigned a semantic version number within the current major version (e.g., v11.01, v11.02… v11.xx). The version number increments sequentially with each sprint delivery. The Provider maintains a release log accessible to the Customer through the Platform. Release Category Description Frequency Notice Period Hotfix / Patch Critical bug fixes and security patches addressing specific production issues or vulnerabilities. Deployed outside the normal sprint cycle. As required Emergency: ASAP Planned: 5 Business Days Sprint Release (Client-Specific) Bundled change requests, bug fixes, and minor enhancements delivered at the end of each sprint. Specific to the Customer’s client branch. Every 3–5 Business Days (per sprint cycle) Sprint planning provides advance visibility Maintenance Release COTS updates (OS, database, middleware patches), security hardening, and infrastructure optimisation. Applied across all Customer environments. 3–4 per year 10 Business Days 4.7.2 Upgrades (Major Version – e.g. v11 → v12) Upgrades represent a new major version of the Platform (e.g., v11 → v12, v12 → v13). Upgrades are product-wide releases that encompass significant functional enhancements, new modules, UI/UX redesigns, new APIs/SDKs, architectural improvements, and major COTS version upgrades (e.g.,.NET framework, SQL Server engine). Upgrades are released approximately once per year and represent a new software version number. Major Upgrades typically include: New Functional Enhancements: Feature additions, new module capabilities, and workflow improvements driven by the Provider’s product roadmap and Customer Advisory Board feedback; UI/UX Improvements: Interface redesigns, usability enhancements, accessibility improvements, and responsive design updates; API & SDK Extensions: New integration endpoints, enhanced Web API capabilities, and updated Software Development Kits; COTS Platform Upgrades: Migration to new versions of underlying technologies (.NET, SQL Server, IIS) as part of the Provider’s technology currency commitment; Security Enhancements: Implementation of new security standards, encryption upgrades, and compliance with emerging regulatory requirements. 4.7.3 Integrated Release Management & Deployment Process All releases (incremental) and upgrades (major version) are managed through the Platform Release Centre, which serves as the central release management and distribution platform. The Platform provides the following capabilities: (h) Release Catalogue: A complete catalogue of all available releases for each Customer, organised by application and version. Each release entry includes the release date, version number, and detailed release notes describing new features, fixes, and known issues; (i) Credential-Based Access: Access to the Platform is secured via unique credentials assigned to the Customer’s designated administrators. Access rights determine visibility of releases applicable to the Customer’s licensed modules; (j) Release Notes & Change Logs: Each release is accompanied by semantic and contextual comments describing the latest features, functionalities, and bug fixes, reviewed and approved by the Provider’s Reviewer before publication; (k) On-Demand Availability: Releases are available for download on-demand, subject to Customer administrator acceptance. The Provider notifies the Customer when a new release is available; (l) Audit Trail: The Platform maintains a complete record of which releases have been made available, downloaded, and deployed for each Customer environment. SaaS Deployment Model: In the SaaS delivery model, the Provider manages all deployments to the Customer’s dedicated sovereign environment. The Customer does not self-install releases. The deployment process is as follows: Step Action Channel 1. Notification Provider publishes the release within the Platform and notifies the Customer’s designated administrator via email and, where applicable, the WhatsApp Business Channel. Portal + Email + WhatsApp 2. Release Review Customer reviews the release notes, change log, and impact assessment within the Platform. Customer may raise questions or concerns via the embedded ticketing system or WhatsApp. Portal + Ticketing 3. Staging Deployment Provider deploys the release to the Customer’s Staging Environment. For sprint releases, this occurs automatically at the end of each sprint. Provider-managed 4. UAT Customer performs Universal User Acceptance Testing. Minimum 5 Business Days. Results are documented in the embedded ticketing system. Staging Environment 5. Sign-Off Customer provides written UAT sign-off via the embedded ticketing system or email. No production deployment occurs without sign-off (except Emergency Hotfixes). Ticketing + Email 6. Production Deploy Provider deploys the approved release to Production during an agreed maintenance window (ref. Section 3.2.3). Deployment is executed via the Provider’s CI/CD pipeline. Provider-managed 7. Verification Provider performs post-deployment verification checks and monitors for 2 Business Days. Customer is notified of successful deployment via the Platform and email. Portal + Email + Ticketing 4.7.4 End-of-Life & Version Transition The Provider’s End-of-Life (EOL) policy, version-transition lifecycle, migration services, re-training programme, data-return procedures, and subscription-cessation processes are comprehensively defined in Chapter 10 — End-of-Life, Version Transition & Subscription Cessation. Chapter 10 governs all aspects of version lifecycle management from General Availability (GA) through EOL Announcement, End of Engineering (EOE), End of Life, and optional Extended Support. For purposes of this Chapter, the following summary applies: the Provider shall give the Customer a minimum of twelve (12) months’ written notice before a major version reaches End of Life. Upgrade assistance, including migration planning, data migration, integration adoption, re-training, and UAT support, is included within the Subscription Term at no additional cost. Full terms, timelines, and procedures are set out in Sections 10.1 through 10.14. 4.7.5 Version Control & Source Code Escrow The Provider maintains all source code in a Git-based version control system that incorporates: Master Branch: The standard DANAOS application ("Vanilla Version") representing the current generally available release; Client Branches: Customer-specific configurations and customisations maintained as dedicated branches. Sprint releases are developed on the client branch; Working Clones: Developer working copies that are merged under stable conditions to incorporate new functionalities into the Master and Client branches. All code changes are subject to peer review via Pull Requests, automated testing, and compliance with the Provider’s Programming Guidelines covering code quality, business logic, and security best standards. Upon executing Commit and Push, and after any Pull Request review, application versions are fully justified by the responsible programmer (or Agile Team) with semantic and contextual comments. Reviewers accept or reject changes based on the Provider’s Programming Guidelines. Business logic is additionally verified by DANAOS Support Engineers who are subject-matter experts within their domain. The Provider practices Continuous Integration / Continuous Delivery (CI/CD) for software deployment where appropriate. The CI/CD pipeline automates build, test, and deployment stages from the Git repository through to the Staging Environment, ensuring consistency and reducing manual deployment errors. The Provider shall maintain a Source Code Escrow arrangement with an independent third-party Escrow Agent. The comprehensive terms governing the escrow deposit contents, update frequency, annual verification, release conditions, and Customer rights upon release are defined in Section 9.14 (Source Code Escrow). The costs of the escrow arrangement, including the Escrow Agent’s fees, shall be borne by the Customer (see § 9.14.4). 4.8 IMAC/RD Services The Provider delivers Install, Move, Add, Change, Remove, and Dispose (IMAC/RD) services for the Platform as part of ongoing operational support. IMAC/RD activities are managed as Standard or Normal changes (ref. Section 4.6.1) and are subject to the following scope: Type Scope Description Install Initial deployment Installation and deployment of software applications, initial environment configuration, and integration setup for the Customer’s dedicated sovereign environment. Move Relocation Migration of workstation configurations, reassignment of user profiles, environment relocation (e.g., data centre migration), or transfer of services between environments. Add Configuration change Addition or modification of software configurations, module customisation, user permission updates, installation of approved software updates, and integration of new API endpoints. Change Modification Modification of existing configurations, workflow adjustments, report customisation, and platform parameter changes as agreed with the Customer. Remove Decommission Controlled decommissioning of modules, features, or integrations. Includes secure data deletion where applicable, with deletion reports provided to the Customer. Dispose End-of-life Environmentally responsible disposal of decommissioned hardware (if applicable), data carrier sanitisation in accordance with NIST SP 800-88, and disposal certification. IMAC/RD activities that fall outside the scope of the Subscription Term shall be quoted separately on a per-manday basis, agreed in writing between the parties before commencement of work. 4.9 Enterprise Architecture Guidance The Provider shall advise the Customer on enterprise architecture matters relating to the Platform, including system integration, data flow design, and technology alignment. This includes: (a) Integration Architecture: Guidance on connecting ProjectVIEW ERP with the Customer’s existing enterprise systems (e.g., SAP, Oracle, banking platforms, HR systems) via the Platform’s native Web API (ref. Section 2.5); (b) Data Architecture: Advisory on data flow, data migration planning, master data management, and reporting architecture within the Customer’s dedicated sovereign environment; (c) Security Architecture: Guidance on network security, access control policies, encryption standards, and alignment with the security framework detailed in Part B of this Framework; (d) Scalability Planning: Proactive recommendations for environment scaling based on user growth projections, data volume trends, and module activation plans. Enterprise architecture guidance is provided as an advisory service and does not extend to the design, development, or support of third-party systems. Implementation of architectural recommendations is subject to separate scoping and costing as agreed between the parties. 4.10 Continual Service Improvement (CSI) The Provider operates a Continual Service Improvement (CSI) programme aligned with ITIL 4 practices and contemporary AIOps methodologies to drive ongoing improvements in service quality, operational efficiency, and Customer satisfaction. The CSI programme includes: AI-Assisted Trend Analysis: Monthly analysis of incident volumes, categories, recurring issues, and resolution times using pattern recognition and anomaly detection to identify systemic improvements proactively; Root Cause Elimination: Problem Management activities targeting the elimination of recurring incidents through permanent fixes, informed by cross-ticket correlation analysis; Process Optimisation: Regular review of support processes, ticket workflows, escalation procedures, and omnichannel support effectiveness to reduce resolution times and improve Customer experience; Customer Feedback & Experience Management: Incorporation of Customer satisfaction survey results, Quarterly Service Review feedback, and WhatsApp channel effectiveness metrics into the CSI register; Technology Refresh: Proactive identification of COTS updates, security enhancements, and platform optimisations that benefit the Customer; Knowledge Management: Continuous enrichment of the embedded knowledge base with solutions from resolved tickets, enabling higher self-service resolution rates and reducing repeat incident volumes. The CSI register is maintained by the Service Delivery Manager and reviewed during each Quarterly Service Review (ref. Section 3.10.2). All CSI initiatives are tracked from identification through implementation with measurable outcomes. Where the Provider adopts AI-assisted tools in support operations, their use shall comply with applicable governance frameworks including the EU AI Act and the NIST AI Risk Management Framework (AI RMF 1.0). Reference URLs: ITIL 4 Foundation – PeopleCert / Axelos ProjectVIEW ERP Ticketing System – DANAOS Projects WhatsApp Business Platform – Meta Azure Service Health – Microsoft NIST SP 800-88 Media Sanitization Guidelines NIST AI Risk Management Framework (AI RMF 1.0) EU AI Act – European Commission 4.11 Process Register The following table summarises the service support and operational processes established in this Chapter, including responsible roles, expected outcomes, and cross-references to related processes in other Chapters. Role Legend: P = Provider | C = Customer | PSD = Provider Service Desk | SDM = Service Delivery Manager | CAB = Change Advisory Board | SC = Steering Committee 4.11.1 Process Registry Ref Process Trigger Handler Approver Expected Outcome Cross-Ref P-4.01 Ticket Logging Issue or request raised via any channel PSD — Ticket created in Embedded Ticketing System (system of record) § 4.3.1, § 3.5 P-4.02 Ticket Lifecycle Mgmt Ticket created PSD / Engineering Customer (closure) Resolved and closed ticket with documented resolution § 4.3.2 P-4.03 WhatsApp Formalisation Issue raised via WhatsApp channel PSD — Formal ticket created within 4 hours § 4.2.3 P-4.04 Technical Escalation Resolution time exceeded or complexity warrants L1 → L2 → L3 → L4 SDM (L3+) Issue escalated to appropriate expertise level § 4.4 P-4.05 Preventive Maintenance Monthly schedule Provider (Infra) SDM Health report delivered within 3 BD § 4.5, § 3.2.3 P-4.06 Change Management Change Request submitted Provider / CAB CAB (Normal/Emergency) Change deployed via UAT gate § 4.6 P-4.07 Sprint Release Deployment Sprint completion (~3 BD cycle) Provider (Dev) Customer (UAT sign-off) Release v11.xx deployed to Production § 4.7.1, § 3.3.1 P-4.08 Major Version Upgrade Annual product release Provider (Product) Steering Committee Customer upgraded to new major version § 4.7.2, Ch. 10 P-4.09 IMAC/RD Service Delivery Customer service request Provider (assigned team) Customer IT Liaison Service delivered; billed per manday pricing § 4.8, § 6 P-4.10 CSI Cycle Quarterly Service Review SDM Steering Committee CSI register updated; improvement actions tracked § 4.10, § 3.10.3 4.11.2 RACI Matrix Process (Ref) Provider PSD Customer SDM CAB/SC P-4.01 Ticket Logging — R C I — P-4.02 Ticket Lifecycle R R A I — P-4.03 WhatsApp Formalise — R I I — P-4.04 Escalation R R I A — P-4.05 Prev. Maintenance R I I A — P-4.06 Change Mgmt R C C C A P-4.07 Sprint Release R I A C I P-4.08 Major Upgrade R I C R A P-4.09 IMAC/RD R C A I — P-4.10 CSI Cycle C I C R A R = Responsible (executes) | A = Accountable (sign-off) | C = Consulted | I = Informed | — = Not Involved 4.11.3 Process Flow — Support & Operations Lifecycle Stage Activity Role Output ① Raise Issue raised via Embedded Ticketing, WhatsApp, phone, or email Customer / PSD Ticket in system of record ② Triage PSD classifies (Incident / Service Request / Problem / Change) and assigns priority PSD Classified ticket → § 3.5 ③ Resolve Engineering resolves per MTTR; escalation if needed (L1→L4) Provider Engineering Resolution / workaround ④ Change Gate If change required: RFC → CAB review → approval Provider / CAB Approved change → § 4.6 ⑤ Sprint / Build Development in 3-day Agile sprint; CI/CD to Staging Provider (Dev) Release in Staging → § 4.7.1 ⑥ UAT Customer validates in Staging; written sign-off required Customer UAT sign-off → § 3.3.1 ⑦ Deploy Production deployment via Platform Release Centre Provider (Ops) Live in Production → § 4.7.3 ⑧ Close & Learn Ticket closed; knowledge base updated; CSI input PSD / SDM Closed ticket; CSI register → § 4.10 ← PreviousService Level Agreement (SLA)Next →Software Quality & Testing See how ProjectVIEW ERP runs in a dedicated cloud environment for your projects. Book a Demo →
Chapter 4 · ProjectVIEW ERP Master SaaS Framework Support is delivered by the Provider Service Desk through an embedded in-application ticketing system, a dedicated WhatsApp Business group, telephone and email, all available 24×7×365 and aligned with ITIL 4. Chapter 4 covers the ticket lifecycle, four-level technical escalation, preventive maintenance, change management (Standard, Normal, Emergency) and release management — from sprint releases to major-version upgrades. 24×7×365service desk channels 4support channels L1–L4technical escalation levels ITIL 4process alignment 4.1 Overview This Section defines the operational support framework through which the Provider delivers day-to-day support services for the Platform. It establishes the structure, processes, and responsibilities for incident management, ticket lifecycle management, preventive maintenance, technical escalation, and operational change control. All support processes align with ITIL 4 best-practice guidelines and leverage the Provider’s omnichannel support model to ensure rapid, traceable, and context-rich service delivery across all communication channels. Support services apply to the Production Environment and, where explicitly agreed in the Commercial Contract, the Staging Environment. The Provider shall maintain documented support procedures and make them available to the Customer upon reasonable request. All support activities are recorded and tracked through the Platform’s embedded ticketing system, providing end-to-end visibility for both the Provider and the Customer. 4.2 Provider Service Desk (PSD) The Provider Service Desk (PSD) is the single point of contact for recording, managing, and resolving all technical support-related tickets, including Incidents, Service Requests, Problems, and Change Requests raised by the Customer. The PSD operates an omnichannel support model that unifies formal ticketing, real-time messaging, and traditional communication channels into a single, traceable support workflow. The PSD coordinates with the Customer’s designated IT liaison for all support and maintenance services. 4.2.1 Embedded Ticketing System The Platform incorporates a native embedded ticketing system within the ProjectVIEW ERP application itself. This integrated ITSM capability allows Authorised Users to raise, track, and manage support tickets directly from within the Platform without leaving the ERP environment. The embedded ticketing system provides: (a) In-Application Ticket Logging: Users raise tickets directly within the ProjectVIEW ERP interface, with automatic capture of contextual information including the active module, screen, user role, and any associated data records; (b) Real-Time Status Tracking: A unified dashboard within the ERP displays all open, in-progress, and resolved tickets with full lifecycle visibility, SLA countdown timers, and priority indicators; (c) Bi-Directional Communication: Threaded conversations between the Customer and the assigned support engineer occur within the ticket itself, maintaining a complete chronological audit trail; (d) Attachment & Evidence Capture: Users attach screenshots, error logs, documents, and screen recordings directly to tickets, eliminating context loss during escalation; (e) SLA Metrics & Reporting: Built-in SLA tracking with automated alerts when response or resolution targets approach threshold, along with real-time reporting on ticket volumes, categories, and resolution performance; (f) Knowledge Base Integration: The ticketing system links to the Provider’s embedded knowledge base (wiki), surfacing relevant articles and known solutions during ticket creation to enable self-service resolution; (g) Automated Notifications: Email and in-application notifications are triggered at each ticket state transition (logged, acknowledged, assigned, updated, resolved, closed), keeping all stakeholders informed. The embedded ticketing system serves as the system of record for all support interactions. Regardless of the channel through which an issue is initially reported (telephone, email, WhatsApp, or in-application), all tickets must be formalised within the embedded ticketing system to ensure SLA measurement, auditability, and compliance. 4.2.2 Omnichannel Support Channels The Provider shall provide the Customer with access to the PSD through the following channels: Channel Availability Ticket Types Use Case Embedded Ticketing (In-Application) 24 × 7 × 365 All types Primary channel. Authorised Users raise tickets directly within ProjectVIEW ERP with automatic context capture. Recommended for all non-emergency issues. WhatsApp Business (Dedicated Group) 24 × 7 × 365 P3, P4, Enquiries Shared WhatsApp group between the Customer’s key users and the Provider’s assigned consultants for expedient informal communication, quick enquiries, and ad-hoc guidance. Messages requiring formal action are escalated to the embedded ticketing system. Telephone 24 × 7 × 365 P1, P2 Priority-1 (Critical) and Priority-2 (Urgent) incidents requiring immediate attention. The Customer shall report P1 and P2 incidents by telephone to ensure prompt escalation. Email 24 × 7 × 365 All types Formal ticket logging for all ticket types. Emails sent to the designated PSD address are automatically ingested into the embedded ticketing system and assigned a ticket reference. 4.2.3 WhatsApp Business Support Channel The Provider establishes a dedicated WhatsApp Business group for each Customer, connecting the Customer’s designated key users with the Provider’s assigned consultants. This channel operates as an expedient informal communication layer to complement the formal ticketing system. The WhatsApp channel is governed by the following rules: (a) Scope: Quick enquiries, usage guidance, clarification of functionality, informal discussion of potential change requests, and preliminary reporting of non-critical issues. The WhatsApp channel is not a substitute for formal ticket logging; (b) Formalisation Rule: Any issue communicated via WhatsApp that requires formal tracking, SLA measurement, code change, configuration modification, or escalation must be logged as a ticket in the embedded ticketing system by the Provider consultant within 4 hours of identification. The Customer shall be notified of the ticket reference; (c) SLA Exclusion: SLA response and resolution timers commence upon formalisation of the ticket in the embedded ticketing system, not upon initial WhatsApp communication; (d) Data Protection: Participants shall not share Personal Data, credentials, database content, or Confidential Information via WhatsApp. The Provider shall brief all participants on data handling obligations under the applicable Data Protection Laws (ref. Section 17); (e) Retention: WhatsApp messages are retained in accordance with the Provider’s data retention policy. For auditability purposes, any substantive technical discussion or decision made via WhatsApp shall be summarised in the corresponding ticket record; (f) Group Membership: Group membership is managed jointly. The Provider shall update group membership within 2 Business Days of any personnel change. The Customer shall notify the Provider of any changes to its designated key users. 4.2.4 PSD Operating Hours & Availability The PSD operates 24 hours per day, 7 days per week, 365 days per year for ticket logging across all channels. Resolution activities follow the operation windows defined in the SLA Response & Resolution Matrix (Section 3.6). UAE/Greece/Philippines Government public holidays are excluded from Business Day calculations but P1 incidents are attended to regardless of public holiday schedules. 4.2.5 PSD Responsibilities The PSD shall: (a) Record all Customer-reported incidents and service requests in the embedded ticketing system, assigning a unique ticket reference number with automatic contextual metadata capture; (b) Agree with the Customer the priority level to be allocated to each ticket in accordance with the Incident Priority Classification defined in Section 3.5; (c) Provide the Customer with acknowledgement of e-ticket post receipt; (d) Manage all necessary escalations to restore the Services within the applicable Service Level targets; (e) Provide the Customer with regular progress updates via the ticketing system, telephone, email, or WhatsApp at mutually agreed intervals; (f) Advise the Customer upon ticket resolution, including a brief description of the root cause, corrective action taken, and whether the ticket is to be closed or requires further action; (g) Where possible, first attempt to resolve tickets remotely. Where remote resolution is not feasible, the Provider shall dispatch a qualified engineer to the Customer’s premises as required; (h) Formalise any issues initially communicated via WhatsApp or telephone into the embedded ticketing system within 4 hours; (i) Maintain a complete audit trail of all ticket interactions, status changes, and resolution activities within the embedded ticketing system. 4.3 Ticket Lifecycle Management All support interactions follow a structured ticket lifecycle managed through the Platform’s embedded ticketing system to ensure traceability, accountability, and compliance with the SLA targets. The lifecycle applies to all ticket types: Incidents, Service Requests, Problems, and Change Requests, regardless of the channel through which the issue was initially reported. 4.3.1 Ticket Logging When a ticket is logged by the Customer, the following minimum information shall be provided to the PSD: (a) Customer name and contract reference ( auto-populated when tickets are raised via the embedded ticketing system); (b) Name and contact details of the person reporting the issue; (c) A clear description of the issue, including steps to reproduce (for incidents) or the nature of the request (for service requests); (d) The affected module(s) and number of impacted Authorised Users; (e) Any diagnostics, screenshots, or error messages obtained by the Customer; (f) The Customer’s proposed priority level for the ticket. 4.3.2 Ticket Processing Workflow The following procedure defines the method by which a ticket is processed from initial logging through to closure: Step Action Responsibility 1 Customer logs a ticket via the embedded ticketing system (in-application), email, telephone, or WhatsApp. Tickets raised via the embedded system automatically capture module context, screen, user role, and related data records. Customer 2 PSD receives the ticket in the embedded ticketing system (or formalises it from telephone/WhatsApp within 4 hours), assigns a unique ticket number, and allocates the ticket to the appropriate support engineer based on module expertise and priority. PSD 3 PSD acknowledges the ticket via the embedded ticketing system and email, containing: ticket reference number, assigned engineer name, priority classification, and expected response time. PSD 4 The assigned engineer contacts the Customer within the applicable response time, confirms the issue details, and begins diagnosis. Remote troubleshooting is attempted first. Support Engineer 5 The engineer provides the Customer and PSD with an estimated time to resolution or, if applicable, confirms the ticket has been resolved remotely. Support Engineer 6 Upon resolution, the engineer completes a Service Report detailing: ticket reference, time taken, root cause analysis, corrective action, and any preventive recommendations. Support Engineer 7 PSD notifies the Customer of resolution via email, provides the Service Report, and requests confirmation to close the ticket or flags any required follow-up actions. PSD 8 Customer confirms resolution or requests further action. Ticket is closed in the embedded ticketing system with full audit trail preserved. Customer / PSD Ticket Reopening: If the Customer reports that the same issue recurs within 5 Business Days of ticket closure, the original ticket shall be reopened with the same priority classification within the embedded ticketing system. Reopened tickets are counted as a single incident for SLA measurement purposes. 4.3.3 Ticket Classification Tickets are classified into the following categories: Ticket Type Definition Examples Incident An unplanned interruption or reduction in quality of the Platform or a component thereof. System unavailable, module crash, data not saving, report generation failure, login errors. Service Request A formal request from the Customer for something to be provided, changed, or actioned that is not an incident. New user creation, password reset, access permission change, report configuration, data export. Problem The underlying root cause of one or more incidents, identified through trend analysis or post-incident review. Recurring timeout errors traced to database indexing, repeated memory overflow from specific module. Change Request A formal request for modification to the Platform’s configuration, functionality, or integration. New field addition, workflow modification, API integration, report customisation, module enhancement. 4.4 Technical Escalation The Provider maintains a structured technical escalation matrix to ensure that tickets are escalated to the appropriate level of expertise and management authority when resolution is not achieved within the applicable Service Level targets or when the severity of the issue requires senior intervention. 4.4.1 Escalation Levels Level Escalation Trigger Escalated To Target Action Level 1 First Response Ticket logged and assigned. Initial diagnosis and remote troubleshooting. PSD Support Engineer Diagnose, apply known fix, or escalate within response time. Level 2 Specialist Level 1 unable to resolve within MTTR target, or issue requires deep module expertise. Senior Support Engineer / Module Specialist In-depth analysis, code-level debugging, configuration review, hotfix development. Level 3 Engineering Level 2 unable to resolve, or issue involves core platform architecture, database, or infrastructure. Development Team Lead / Principal Engineer Code modification, database remediation, architectural intervention, patch release. Level 4 Management Resolution exceeds 2× MTTR target, or P1 incident not resolved within 8 hours, or Customer requests management escalation. Service Delivery Manager / CTO Resource reallocation, executive communication, recovery plan activation, post-incident review. 4.4.2 Customer-Initiated Escalation The Customer may escalate a ticket at any time by contacting the PSD and requesting escalation. The Provider shall update the Escalation Contact Matrix at least annually or upon any change in personnel, and shall provide the current matrix to the Customer within 5 Business Days of any update. The Escalation Contact Matrix shall include name, designation, direct contact numbers, and email address for each escalation level. For P1 (Critical) incidents, the Provider shall automatically escalate to Level 2 within 30 minutes if the initial response has not identified a resolution path, and to Level 3 within 2 hours if the incident remains unresolved. The Customer’s designated IT liaison and the Service Delivery Manager shall be notified of all P1 escalations in real time. 4.5 Preventive Maintenance The Provider shall perform monthly preventive maintenance on all Platform components within the Customer’s dedicated private sovereign environment. Preventive maintenance is conducted proactively to identify and remediate potential issues before they impact service availability or performance. 4.5.1 Preventive Maintenance Scope Monthly preventive maintenance shall include, but is not limited to: (a) Infrastructure Health Checks: Virtual machine performance monitoring, disk utilisation, memory allocation, CPU load analysis, and network latency assessment; (b) Database Maintenance: Index rebuilding, statistics updates, transaction log management, integrity checks (DBCC CHECKDB), and storage optimisation; (c) Security Patching: Review and application of operating system, middleware, and database security patches in accordance with the Provider’s patch management policy (see Section 3.2.3 for maintenance windows); (d) Backup Verification: Validation of backup job completion, backup integrity testing, and restore drill execution (quarterly); (e) Application Health: Module-level functional checks, API endpoint validation, integration monitoring, and error log review across all active ProjectVIEW ERP modules; (f) SSL/TLS Certificate Management: Certificate expiry monitoring, renewal, and rotation; (g) Capacity Review: Assessment of current resource utilisation against provisioned capacity, with proactive scaling recommendations where utilisation exceeds 75% threshold. 4.5.2 Preventive Maintenance Reporting Upon completion of each preventive maintenance cycle, the Provider’s maintenance engineer shall submit a Preventive Maintenance Report to the Customer within 3 Business Days. The report shall include: Date and duration of maintenance activity; Components inspected and actions performed; Identified risks or anomalies with recommended remediation; Current vs. provisioned resource utilisation metrics; Upcoming patch and update schedule; Confirmation of backup verification results. 4.6 Change Management All modifications to the Platform’s configuration, functionality, or infrastructure are governed by a formal Change Management process designed to minimise risk to the Production Environment. Changes are classified and managed in accordance with ITIL Change Management best practices. 4.6.1 Change Classification Change Type Definition Approval Deployment Path Standard Pre-authorised, low-risk changes with established procedures (e.g., user account creation, routine configuration). Pre-approved Direct to Staging → UAT → Production Normal Non-routine changes requiring assessment, planning, and approval (e.g., new module configuration, API integration, workflow modification). Change Advisory Board (CAB) or Service Delivery Manager Development → Staging → UAT → Customer Sign-off → Production Emergency Urgent changes required to restore service or address a critical security vulnerability. Bypasses standard CAB review. Service Delivery Manager with post-implementation CAB review Development → Production (with retrospective UAT and documentation) 4.6.2 Change Management Workflow All Normal and Emergency changes follow this workflow: (a) Request: The Customer or Provider submits a Change Request via the PSD with description, business justification, affected modules, and requested implementation date; (b) Assessment: The Provider performs an impact assessment covering: technical risk, affected users, rollback plan, estimated effort, and dependencies; (c) Approval: The Change Advisory Board (or Service Delivery Manager for emergency changes) reviews and approves or rejects the change; (d) Implementation: The change is developed and deployed to the Staging Environment; (e) UAT: The Customer performs Universal User Acceptance Testing in the Staging Environment. A minimum of 5 Business Days is provided for UAT. Written sign-off is required (ref. Section 3.3.1); (f) Deployment: Upon Customer UAT sign-off, the change is deployed to Production during an agreed maintenance window; (g) Post-Implementation Review: The Provider monitors the change for 5 Business Days post-deployment and provides a closure report to the Customer. Rollback: Every Normal and Emergency change shall include a documented rollback plan. If the change causes an unplanned service degradation, the Provider shall execute the rollback within 2 hours of identifying the issue and notify the Customer immediately. 4.6.3 Change Auditability All changes to the Platform’s configuration, codebase, and infrastructure are logged in the Provider’s Change Management System. Each change record includes: requester, description, risk assessment, approval chain, implementation date, implementing engineer, test results, and post-implementation status. Change logs are available to the Customer upon request and are included in the Quarterly Service Review (ref. Section 3.10.2). 4.7 Software Release Management The Provider manages all software deliveries through a controlled release management process that distinguishes between two fundamentally different delivery types: Releases/Updates (incremental, client-specific, frequent) and Upgrades (major version, product-wide, annual). This distinction ensures that day-to-day agile delivery for the Customer does not conflict with the Provider’s broader product roadmap. 4.7.1 Releases & Updates (Incremental – e.g. v11.xx) Releases and updates are incremental deliveries within the current major version of the Platform (e.g., v11.01, v11.02, v11.15). They address change requests, bug fixes, configuration adjustments, and minor functional enhancements specific to the Customer’s implementation. Releases are delivered using an Agile execution methodology tailored to the operational cadence of the Customer. Agile Sprint Methodology: The Provider operates in short-cycle sprints averaging 3 Business Days per sprint. Each sprint delivers a defined set of change requests, bug fixes, or configuration changes agreed with the Customer at sprint planning. The sprint cycle is as follows: Phase Duration Activities Responsibility Sprint Planning 0.5 day Provider and Customer review the backlog, prioritise items, and agree on the sprint scope. Items are drawn from: open tickets, change requests, bug reports, and Customer-requested enhancements. Provider + Customer Development 1.5–2 days The Provider’s development team implements the agreed changes on the Customer’s dedicated client branch in the Git repository. Unit testing is performed by DANAOS Support Engineers who are subject-matter experts within their domain. Provider Staging Deployment 0.25 day Completed sprint items are deployed to the Staging Environment via the Provider’s CI/CD pipeline for Customer validation. Provider UAT & Sign-Off Per Section 3.3.1 The Customer performs Universal User Acceptance Testing on the sprint deliverables. Written sign-off is required before production deployment. Minimum 5 Business Days for UAT. Customer Production Deployment 0.25 day Upon UAT sign-off, the sprint release is deployed to Production during an agreed maintenance window. Post-deployment monitoring is active for 2 Business Days. Provider Sprint Retrospective Ad hoc Brief review of sprint outcomes, issues encountered, and process improvements. Findings feed into the CSI register (ref. Section 4.10). Provider + Customer Release Versioning: Each incremental release is assigned a semantic version number within the current major version (e.g., v11.01, v11.02… v11.xx). The version number increments sequentially with each sprint delivery. The Provider maintains a release log accessible to the Customer through the Platform. Release Category Description Frequency Notice Period Hotfix / Patch Critical bug fixes and security patches addressing specific production issues or vulnerabilities. Deployed outside the normal sprint cycle. As required Emergency: ASAP Planned: 5 Business Days Sprint Release (Client-Specific) Bundled change requests, bug fixes, and minor enhancements delivered at the end of each sprint. Specific to the Customer’s client branch. Every 3–5 Business Days (per sprint cycle) Sprint planning provides advance visibility Maintenance Release COTS updates (OS, database, middleware patches), security hardening, and infrastructure optimisation. Applied across all Customer environments. 3–4 per year 10 Business Days 4.7.2 Upgrades (Major Version – e.g. v11 → v12) Upgrades represent a new major version of the Platform (e.g., v11 → v12, v12 → v13). Upgrades are product-wide releases that encompass significant functional enhancements, new modules, UI/UX redesigns, new APIs/SDKs, architectural improvements, and major COTS version upgrades (e.g.,.NET framework, SQL Server engine). Upgrades are released approximately once per year and represent a new software version number. Major Upgrades typically include: New Functional Enhancements: Feature additions, new module capabilities, and workflow improvements driven by the Provider’s product roadmap and Customer Advisory Board feedback; UI/UX Improvements: Interface redesigns, usability enhancements, accessibility improvements, and responsive design updates; API & SDK Extensions: New integration endpoints, enhanced Web API capabilities, and updated Software Development Kits; COTS Platform Upgrades: Migration to new versions of underlying technologies (.NET, SQL Server, IIS) as part of the Provider’s technology currency commitment; Security Enhancements: Implementation of new security standards, encryption upgrades, and compliance with emerging regulatory requirements. 4.7.3 Integrated Release Management & Deployment Process All releases (incremental) and upgrades (major version) are managed through the Platform Release Centre, which serves as the central release management and distribution platform. The Platform provides the following capabilities: (h) Release Catalogue: A complete catalogue of all available releases for each Customer, organised by application and version. Each release entry includes the release date, version number, and detailed release notes describing new features, fixes, and known issues; (i) Credential-Based Access: Access to the Platform is secured via unique credentials assigned to the Customer’s designated administrators. Access rights determine visibility of releases applicable to the Customer’s licensed modules; (j) Release Notes & Change Logs: Each release is accompanied by semantic and contextual comments describing the latest features, functionalities, and bug fixes, reviewed and approved by the Provider’s Reviewer before publication; (k) On-Demand Availability: Releases are available for download on-demand, subject to Customer administrator acceptance. The Provider notifies the Customer when a new release is available; (l) Audit Trail: The Platform maintains a complete record of which releases have been made available, downloaded, and deployed for each Customer environment. SaaS Deployment Model: In the SaaS delivery model, the Provider manages all deployments to the Customer’s dedicated sovereign environment. The Customer does not self-install releases. The deployment process is as follows: Step Action Channel 1. Notification Provider publishes the release within the Platform and notifies the Customer’s designated administrator via email and, where applicable, the WhatsApp Business Channel. Portal + Email + WhatsApp 2. Release Review Customer reviews the release notes, change log, and impact assessment within the Platform. Customer may raise questions or concerns via the embedded ticketing system or WhatsApp. Portal + Ticketing 3. Staging Deployment Provider deploys the release to the Customer’s Staging Environment. For sprint releases, this occurs automatically at the end of each sprint. Provider-managed 4. UAT Customer performs Universal User Acceptance Testing. Minimum 5 Business Days. Results are documented in the embedded ticketing system. Staging Environment 5. Sign-Off Customer provides written UAT sign-off via the embedded ticketing system or email. No production deployment occurs without sign-off (except Emergency Hotfixes). Ticketing + Email 6. Production Deploy Provider deploys the approved release to Production during an agreed maintenance window (ref. Section 3.2.3). Deployment is executed via the Provider’s CI/CD pipeline. Provider-managed 7. Verification Provider performs post-deployment verification checks and monitors for 2 Business Days. Customer is notified of successful deployment via the Platform and email. Portal + Email + Ticketing 4.7.4 End-of-Life & Version Transition The Provider’s End-of-Life (EOL) policy, version-transition lifecycle, migration services, re-training programme, data-return procedures, and subscription-cessation processes are comprehensively defined in Chapter 10 — End-of-Life, Version Transition & Subscription Cessation. Chapter 10 governs all aspects of version lifecycle management from General Availability (GA) through EOL Announcement, End of Engineering (EOE), End of Life, and optional Extended Support. For purposes of this Chapter, the following summary applies: the Provider shall give the Customer a minimum of twelve (12) months’ written notice before a major version reaches End of Life. Upgrade assistance, including migration planning, data migration, integration adoption, re-training, and UAT support, is included within the Subscription Term at no additional cost. Full terms, timelines, and procedures are set out in Sections 10.1 through 10.14. 4.7.5 Version Control & Source Code Escrow The Provider maintains all source code in a Git-based version control system that incorporates: Master Branch: The standard DANAOS application ("Vanilla Version") representing the current generally available release; Client Branches: Customer-specific configurations and customisations maintained as dedicated branches. Sprint releases are developed on the client branch; Working Clones: Developer working copies that are merged under stable conditions to incorporate new functionalities into the Master and Client branches. All code changes are subject to peer review via Pull Requests, automated testing, and compliance with the Provider’s Programming Guidelines covering code quality, business logic, and security best standards. Upon executing Commit and Push, and after any Pull Request review, application versions are fully justified by the responsible programmer (or Agile Team) with semantic and contextual comments. Reviewers accept or reject changes based on the Provider’s Programming Guidelines. Business logic is additionally verified by DANAOS Support Engineers who are subject-matter experts within their domain. The Provider practices Continuous Integration / Continuous Delivery (CI/CD) for software deployment where appropriate. The CI/CD pipeline automates build, test, and deployment stages from the Git repository through to the Staging Environment, ensuring consistency and reducing manual deployment errors. The Provider shall maintain a Source Code Escrow arrangement with an independent third-party Escrow Agent. The comprehensive terms governing the escrow deposit contents, update frequency, annual verification, release conditions, and Customer rights upon release are defined in Section 9.14 (Source Code Escrow). The costs of the escrow arrangement, including the Escrow Agent’s fees, shall be borne by the Customer (see § 9.14.4). 4.8 IMAC/RD Services The Provider delivers Install, Move, Add, Change, Remove, and Dispose (IMAC/RD) services for the Platform as part of ongoing operational support. IMAC/RD activities are managed as Standard or Normal changes (ref. Section 4.6.1) and are subject to the following scope: Type Scope Description Install Initial deployment Installation and deployment of software applications, initial environment configuration, and integration setup for the Customer’s dedicated sovereign environment. Move Relocation Migration of workstation configurations, reassignment of user profiles, environment relocation (e.g., data centre migration), or transfer of services between environments. Add Configuration change Addition or modification of software configurations, module customisation, user permission updates, installation of approved software updates, and integration of new API endpoints. Change Modification Modification of existing configurations, workflow adjustments, report customisation, and platform parameter changes as agreed with the Customer. Remove Decommission Controlled decommissioning of modules, features, or integrations. Includes secure data deletion where applicable, with deletion reports provided to the Customer. Dispose End-of-life Environmentally responsible disposal of decommissioned hardware (if applicable), data carrier sanitisation in accordance with NIST SP 800-88, and disposal certification. IMAC/RD activities that fall outside the scope of the Subscription Term shall be quoted separately on a per-manday basis, agreed in writing between the parties before commencement of work. 4.9 Enterprise Architecture Guidance The Provider shall advise the Customer on enterprise architecture matters relating to the Platform, including system integration, data flow design, and technology alignment. This includes: (a) Integration Architecture: Guidance on connecting ProjectVIEW ERP with the Customer’s existing enterprise systems (e.g., SAP, Oracle, banking platforms, HR systems) via the Platform’s native Web API (ref. Section 2.5); (b) Data Architecture: Advisory on data flow, data migration planning, master data management, and reporting architecture within the Customer’s dedicated sovereign environment; (c) Security Architecture: Guidance on network security, access control policies, encryption standards, and alignment with the security framework detailed in Part B of this Framework; (d) Scalability Planning: Proactive recommendations for environment scaling based on user growth projections, data volume trends, and module activation plans. Enterprise architecture guidance is provided as an advisory service and does not extend to the design, development, or support of third-party systems. Implementation of architectural recommendations is subject to separate scoping and costing as agreed between the parties. 4.10 Continual Service Improvement (CSI) The Provider operates a Continual Service Improvement (CSI) programme aligned with ITIL 4 practices and contemporary AIOps methodologies to drive ongoing improvements in service quality, operational efficiency, and Customer satisfaction. The CSI programme includes: AI-Assisted Trend Analysis: Monthly analysis of incident volumes, categories, recurring issues, and resolution times using pattern recognition and anomaly detection to identify systemic improvements proactively; Root Cause Elimination: Problem Management activities targeting the elimination of recurring incidents through permanent fixes, informed by cross-ticket correlation analysis; Process Optimisation: Regular review of support processes, ticket workflows, escalation procedures, and omnichannel support effectiveness to reduce resolution times and improve Customer experience; Customer Feedback & Experience Management: Incorporation of Customer satisfaction survey results, Quarterly Service Review feedback, and WhatsApp channel effectiveness metrics into the CSI register; Technology Refresh: Proactive identification of COTS updates, security enhancements, and platform optimisations that benefit the Customer; Knowledge Management: Continuous enrichment of the embedded knowledge base with solutions from resolved tickets, enabling higher self-service resolution rates and reducing repeat incident volumes. The CSI register is maintained by the Service Delivery Manager and reviewed during each Quarterly Service Review (ref. Section 3.10.2). All CSI initiatives are tracked from identification through implementation with measurable outcomes. Where the Provider adopts AI-assisted tools in support operations, their use shall comply with applicable governance frameworks including the EU AI Act and the NIST AI Risk Management Framework (AI RMF 1.0). Reference URLs: ITIL 4 Foundation – PeopleCert / Axelos ProjectVIEW ERP Ticketing System – DANAOS Projects WhatsApp Business Platform – Meta Azure Service Health – Microsoft NIST SP 800-88 Media Sanitization Guidelines NIST AI Risk Management Framework (AI RMF 1.0) EU AI Act – European Commission 4.11 Process Register The following table summarises the service support and operational processes established in this Chapter, including responsible roles, expected outcomes, and cross-references to related processes in other Chapters. Role Legend: P = Provider | C = Customer | PSD = Provider Service Desk | SDM = Service Delivery Manager | CAB = Change Advisory Board | SC = Steering Committee 4.11.1 Process Registry Ref Process Trigger Handler Approver Expected Outcome Cross-Ref P-4.01 Ticket Logging Issue or request raised via any channel PSD — Ticket created in Embedded Ticketing System (system of record) § 4.3.1, § 3.5 P-4.02 Ticket Lifecycle Mgmt Ticket created PSD / Engineering Customer (closure) Resolved and closed ticket with documented resolution § 4.3.2 P-4.03 WhatsApp Formalisation Issue raised via WhatsApp channel PSD — Formal ticket created within 4 hours § 4.2.3 P-4.04 Technical Escalation Resolution time exceeded or complexity warrants L1 → L2 → L3 → L4 SDM (L3+) Issue escalated to appropriate expertise level § 4.4 P-4.05 Preventive Maintenance Monthly schedule Provider (Infra) SDM Health report delivered within 3 BD § 4.5, § 3.2.3 P-4.06 Change Management Change Request submitted Provider / CAB CAB (Normal/Emergency) Change deployed via UAT gate § 4.6 P-4.07 Sprint Release Deployment Sprint completion (~3 BD cycle) Provider (Dev) Customer (UAT sign-off) Release v11.xx deployed to Production § 4.7.1, § 3.3.1 P-4.08 Major Version Upgrade Annual product release Provider (Product) Steering Committee Customer upgraded to new major version § 4.7.2, Ch. 10 P-4.09 IMAC/RD Service Delivery Customer service request Provider (assigned team) Customer IT Liaison Service delivered; billed per manday pricing § 4.8, § 6 P-4.10 CSI Cycle Quarterly Service Review SDM Steering Committee CSI register updated; improvement actions tracked § 4.10, § 3.10.3 4.11.2 RACI Matrix Process (Ref) Provider PSD Customer SDM CAB/SC P-4.01 Ticket Logging — R C I — P-4.02 Ticket Lifecycle R R A I — P-4.03 WhatsApp Formalise — R I I — P-4.04 Escalation R R I A — P-4.05 Prev. Maintenance R I I A — P-4.06 Change Mgmt R C C C A P-4.07 Sprint Release R I A C I P-4.08 Major Upgrade R I C R A P-4.09 IMAC/RD R C A I — P-4.10 CSI Cycle C I C R A R = Responsible (executes) | A = Accountable (sign-off) | C = Consulted | I = Informed | — = Not Involved 4.11.3 Process Flow — Support & Operations Lifecycle Stage Activity Role Output ① Raise Issue raised via Embedded Ticketing, WhatsApp, phone, or email Customer / PSD Ticket in system of record ② Triage PSD classifies (Incident / Service Request / Problem / Change) and assigns priority PSD Classified ticket → § 3.5 ③ Resolve Engineering resolves per MTTR; escalation if needed (L1→L4) Provider Engineering Resolution / workaround ④ Change Gate If change required: RFC → CAB review → approval Provider / CAB Approved change → § 4.6 ⑤ Sprint / Build Development in 3-day Agile sprint; CI/CD to Staging Provider (Dev) Release in Staging → § 4.7.1 ⑥ UAT Customer validates in Staging; written sign-off required Customer UAT sign-off → § 3.3.1 ⑦ Deploy Production deployment via Platform Release Centre Provider (Ops) Live in Production → § 4.7.3 ⑧ Close & Learn Ticket closed; knowledge base updated; CSI input PSD / SDM Closed ticket; CSI register → § 4.10 ← PreviousService Level Agreement (SLA)Next →Software Quality & Testing See how ProjectVIEW ERP runs in a dedicated cloud environment for your projects. Book a Demo →