CLIDE Analyser Customisation and Change Request Policy

How we assess, design, build, test and release customer-specific changes

This policy explains how CLIDE Analyser handles requests to configure or customise the platform. It sets out the steps, approvals, responsibilities and commercial basis so that both parties have a shared understanding before work begins. Each request is assessed individually; work starts only after the scope, estimate, timeline and commercial terms have been documented and approved.

1. What this policy covers

A customisation or change request is a requested change to the standard CLIDE Analyser product, its workflows, screens, reports, integrations, data structures or other agreed functionality. Requests may include a new capability, a change to existing behaviour, a customer-specific workflow, or an integration or report not included in the subscribed standard service.

Routine use of existing features, standard configuration expressly included in a subscription, and correction of a reproducible defect in the standard product are handled under the applicable subscription and support terms. This policy applies to separately scoped customer-specific work unless the parties agree otherwise in writing.

2. The customisation lifecycle

Requirement gathering

The customer submits the business need, users affected, current process, desired outcome, examples, relevant data, acceptance criteria, priority and any security, compliance, integration or reporting constraints. CLIDE may hold workshops and ask follow-up questions. Requirements remain provisional until documented and approved.

Feasibility and solution assessment

CLIDE reviews the request for product fit, technical and operational feasibility, dependencies, risks and likely impact on the existing product and other customers. CLIDE may recommend standard configuration, an alternative approach, phased delivery, further discovery, or decline the request. Assessment does not guarantee feasibility or delivery.

BRD and estimate

For requests that proceed, CLIDE prepares a Business Requirements Document (BRD) describing the agreed objectives, in-scope requirements, assumptions, exclusions, deliverables, dependencies, acceptance criteria and proposed approach. CLIDE also provides an estimated effort in man-hours, commercial estimate and a proposed timeline or schedule assumptions. Estimates are based on the information available and may be revised through change control if the approved scope or assumptions change.

Customer review and approval

The customer reviews the BRD and estimate, resolves open questions, and confirms an authorised approver. The customer may request revisions before approval. Written approval of the BRD confirms the baseline scope and acceptance criteria; it does not by itself authorise commencement unless the purchase order and any required agreement are also in place.

UI/UX design

After the commencement gates are satisfied, CLIDE prepares the agreed user-interface and user-experience designs, such as screen layouts, prototypes or workflow representations. The customer reviews these within the agreed review window. Approved designs become the design baseline. A material change after approval may affect effort, cost and schedule and will be assessed through change control.

Development

CLIDE develops the approved functionality against the signed BRD and approved designs. Work is planned in increments or milestones where appropriate. The customer provides timely access to people, systems, sample data and decisions needed for development.

Quality assurance

CLIDE performs quality assurance testing appropriate to the agreed scope, including functional testing and, where applicable, regression or integration checks. CLIDE records and addresses reproducible issues against the agreed requirements before presenting the deliverable for customer acceptance testing. QA does not constitute independent certification or a guarantee that the solution is error-free in every environment.

User acceptance testing (UAT)

CLIDE makes the release candidate available in the agreed test environment and provides reasonable instructions for UAT. The customer tests against the BRD acceptance criteria, consolidates feedback, and submits either written acceptance or a sufficiently detailed list of material failures within the UAT window stated in the BRD or project plan. The default UAT window is ten business days from availability unless the BRD states another period.

Resolution and approval

CLIDE assesses reported items and classifies each as a defect, an enhancement, or an out-of-scope item under section 7. CLIDE corrects confirmed in-scope defects and may issue an updated build for re-test. Once the agreed acceptance criteria are met, the customer provides written acceptance or approval to roll out.

Rollout and handover

Following acceptance and any required rollout approval, CLIDE schedules production rollout, subject to the project plan and customer readiness. CLIDE communicates the release window and any customer actions. Handover may include agreed release notes, configuration details or user guidance. Any post-rollout support is governed by the subscription, support terms and the specific project agreement.

3. Commencement gates

CLIDE will commence billable customisation work only after all applicable items below are complete:

·       The customer has supplied the information reasonably required for discovery and estimation.

·       The customer has approved the final BRD, scope, acceptance criteria, estimated man-hours, pricing basis and applicable schedule assumptions in writing.

·       CLIDE has received a valid purchase order (PO) covering the approved work, where the customer uses or requires POs.

·       The parties have signed any project agreement, statement of work, data-processing terms or other document required for the engagement.

·       Required advance payment or other agreed payment milestone has been met.

·       Necessary customer access, environments, contacts and prerequisites are available.

The approved PO and signed project documents must accurately reflect the approved scope and commercials. A discussion, email request, draft estimate or unapproved BRD is not authorisation to begin work.

4. Timelines and resourcing

CLIDE will provide a proposed timeline after reviewing the requirements and dependencies. The timeline is set by CLIDE based on the approved scope, estimated effort, sequencing, resource availability, technical complexity, third-party dependencies and customer readiness. Unless expressly stated as a fixed commitment in a signed agreement, dates are estimates and may change when these factors change.

The standard delivery model uses shared resources allocated across projects. No dedicated development resource or team is included by default. Resource allocation and sequencing are managed by CLIDE. The customer will receive the agreed points of contact and planned checkpoints for the engagement.

A dedicated team may be agreed separately. The described five-member team comprises a subject matter expert (SME), a UI/UX resource, backend and/or frontend developer resource(s), a QA resource and a Project Manager. The exact staffing, allocation, duration and coverage must be set out in the project proposal or agreement. The stated hourly price is subject to confirmation as described in the publication review note accompanying this draft.

5. Commercial model

The applicable model, rate, estimated hours, invoicing milestones, any minimum commitment or cap, and treatment of additional hours will be expressly stated in the approved proposal, BRD, PO or agreement. Unless the signed commercial documents say otherwise, the estimate is not a fixed-price commitment and actual charges are based on approved work performed at the agreed rate. CLIDE will seek written approval before materially exceeding an approved estimate. Rates are exclusive of applicable taxes, duties and levies, which will be charged as required by law.

6. Customer responsibilities and dependencies

The customer will appoint a project owner and authorised decision-maker, provide accurate requirements and timely consolidated feedback, make relevant subject matter experts available, and obtain internal approvals. The customer is responsible for the accuracy, legality and permissions associated with data and content it supplies.

Where required, the customer will provide timely access to systems, environments, APIs, test accounts, documentation, sample data and third-party contacts. The customer will maintain appropriate backups and ensure its own systems and users are ready for testing and rollout. CLIDE may rely on information and approvals supplied by the customer.

7. Defects, enhancements and scope control

A defect is a reproducible failure of the delivered customisation to materially conform to an approved BRD requirement or acceptance criterion in the agreed supported environment. CLIDE will assess reported issues and, where a defect is confirmed, address it under the agreed project terms and warranty/support provisions.

An enhancement is a new or changed requirement, preference, workflow, output, integration, or acceptance criterion that was not included in the approved BRD, or a request to change an approved design or behaviour. Enhancements and out-of-scope requests require a written change request. CLIDE will assess impact on feasibility, effort, fees, dependencies and schedule and provide a revised estimate or proposal. Work on the change starts only after written approval and any required PO amendment.

The customer should report defects with steps to reproduce, expected and actual results, screenshots or logs where appropriate, affected users and environment details. Issues caused by unsupported environments, third-party changes, customer modifications, incorrect data or use outside the agreed scope may be treated as separately chargeable work, subject to assessment.

8. UAT, acceptance and review windows

The customer will complete UAT within the period stated in the BRD or project plan. If no period is stated, the default is ten business days from the date CLIDE makes the release candidate available and notifies the customer. Feedback must be consolidated and tied to the agreed acceptance criteria.

If the customer identifies a material failure to meet an acceptance criterion within the UAT window, CLIDE will review it and address confirmed in-scope defects. The parties will agree a reasonable re-test window for the corrected build. If the customer does not submit written rejection with specific material failures within the UAT window, the deliverable will be treated as accepted for project administration and invoicing purposes, to the extent permitted by applicable law and the signed agreement. This deemed acceptance does not waive rights relating to latent defects that could not reasonably have been identified during UAT.

Acceptance may also occur when the customer approves rollout in writing or puts the customisation into production use, whichever occurs first, unless the signed agreement specifies a different acceptance mechanism.

9. Delays, pauses and cancellation

If customer inputs, approvals, access, payment or third-party actions are delayed, CLIDE may adjust sequencing and delivery dates to reflect the resulting impact and resource availability. CLIDE will communicate material schedule changes. If a dependency remains unavailable, CLIDE may pause affected work until it is resolved.

If work is placed on hold, the parties will confirm the hold, outstanding actions, any work already completed and the conditions for restarting. Restart dates depend on resource availability and may require a revised schedule or estimate. The customer will pay for work performed and approved non-cancellable commitments incurred up to the effective hold or cancellation date, as set out in the applicable agreement. Any cancellation charges, refunds or treatment of prepaid amounts will be governed by the signed commercial documents.

Either party may terminate the project only as provided in the applicable signed agreement or PO terms. Cancellation does not transfer rights to unfinished work except as expressly agreed in writing and subject to payment of amounts due.

10. Third-party services and dependencies

A request that depends on third-party software, APIs, infrastructure, licences, marketplaces or services is subject to those providers’ availability, terms, technical limits and changes. Unless expressly agreed otherwise, the customer is responsible for obtaining and maintaining required third-party licences, accounts, approvals and fees. CLIDE does not control third-party products or guarantee their continued availability or compatibility. Additional work caused by third-party changes may require a separately approved change request.

11. Intellectual property

Each party retains ownership of its pre-existing intellectual property, materials, tools, methods, software and know-how. Ownership and licence rights in the standard CLIDE Analyser platform remain subject to the applicable subscription or licence terms. Customer data and materials supplied by the customer remain the customer’s responsibility and ownership, subject to the rights needed for CLIDE to perform the services.

Rights in project-specific deliverables, custom code, designs and documentation will be as stated in the signed agreement or statement of work. If those documents do not expressly grant ownership, the customer receives only the rights, if any, granted under the applicable CLIDE subscription and project terms. No transfer of source code or assignment of intellectual property is implied by payment alone.

12. Confidentiality and data security

Each party will protect the other party’s confidential information and use it only for the project and related services, subject to the confidentiality provisions in the applicable agreement. The customer should provide only data reasonably necessary for the work and should use masked or synthetic data for development and testing where practicable.

The parties will follow the security, privacy and data-processing obligations set out in their applicable agreements. The customer is responsible for ensuring it has a lawful basis and necessary permissions to provide personal or regulated data. Any required data-processing terms, access controls, hosting arrangements, retention periods and incident-notification procedures must be agreed in writing before relevant data is processed.

13. Warranty and ongoing support

Any warranty period, remedy, service level or post-rollout support commitment will be stated in the signed project agreement or applicable subscription/support terms. If no project-specific warranty is agreed, CLIDE’s standard subscription and support terms govern. Customisation work does not automatically include ongoing maintenance, new features, third-party updates, additional training or support beyond the agreed scope.

CLIDE does not warrant that customisations will be uninterrupted, error-free in every possible environment, or suitable for a purpose not expressly documented in the approved BRD. The parties’ rights and remedies remain subject to applicable law and the signed agreement.

14. No guarantee of feasibility

Every request is subject to assessment. CLIDE may determine that a request is technically infeasible, commercially impractical, inconsistent with product direction, creates unacceptable security or operational risk, depends on unavailable third-party capabilities, or cannot be delivered within the requested constraints. CLIDE will explain its assessment where reasonably practicable. Discovery or estimation does not commit CLIDE to build or release the request.

15. Governing documents and precedence

This policy is a general description of CLIDE’s customisation process. It does not replace or amend a signed agreement, statement of work, approved BRD, PO, subscription terms or data-processing agreement. The documents applicable to a specific engagement will be read together. If they conflict, the precedence stated in the signed agreement applies; if that agreement is silent, the parties will resolve the conflict in a signed written amendment. No website policy overrides a signed project document.

16. Contact and request submission

To submit a customisation request, contact your CLIDE representative with a description of the business need, affected users, desired outcome, relevant examples and target timing. CLIDE will confirm the next steps for requirement gathering and assessment. A request is not approved for implementation until the commencement gates in section 3 are satisfied.

17. When CLIDE may decline or defer a customisation request

CLIDE assesses each request against the following factors. CLIDE may decline a request, defer it, or propose a different approach where:

• It requires a change to CLIDE Analyser’s underlying framework, core architecture, technology stack, or shared platform components that CLIDE does not support or consider appropriate for the product.

• It would create a separate customer-specific version or “fork” that cannot be maintained and updated reliably alongside the standard product.

• It creates unacceptable security, privacy, data protection, reliability, performance, or operational risk.

• It conflicts with applicable law, regulatory obligations, platform controls, or CLIDE’s product policies.

• It depends on a third-party service, API, licence, or capability that is unavailable, unsupported, or outside CLIDE’s control.

• The requirements are incomplete, unclear, or cannot be translated into testable acceptance criteria after reasonable clarification.

• The requested outcome is not technically feasible , or feasibility cannot be established without discovery work that the customer does not approve.

• The request is likely to adversely affect other customers , including by reducing the security, stability, performance, or availability of the shared platform.

• The effort, cost, delivery risk, or ongoing maintenance burden is disproportionate to the expected benefit or cannot be supported under the proposed commercial model.

• Required customer inputs, access, approvals, data, or third-party permissions are unavailable and no workable alternative is agreed.

• The requested timing cannot reasonably be met given the scope, dependencies, resource availability, or required testing and rollout steps.

• The request would require CLIDE to use, disclose, or transfer intellectual property or confidential information without the necessary rights or approvals.

Assessment and response. Where reasonably practicable, CLIDE will explain the relevant reason and may suggest standard configuration, a reduced scope, a phased approach, further paid discovery, or another alternative. A request may be deferred while information, approvals, or dependencies are outstanding. CLIDE’s assessment or estimate does not commit CLIDE to deliver the request; implementation requires the approvals and documents described in this policy.