# AIDE Chain & AIDE Blueprint
## Sales, Pilot & Onboarding Guide

Version 1.0 | 5 October 2026 | Public customer and partner edition
JEL Project Management

Reference: https://aidechain.com.au/sales-pilot-onboarding.html


## Start here

A public, repeatable path from a useful first conversation to an accepted, supported customer service.

For customers, sales partners and delivery teams evaluating AIDE Chain, AIDE Blueprint or both through JEL Project Management. Start with a real business problem, agree what evidence would justify a purchase, and expand only after the initial scope works.

> **The operating principle**
> Qualify the problem. Demonstrate the relevant capability. Prove value in a bounded pilot. Provision consistently. Accept operational readiness. Support adoption.

### How to use this guide

| Stage | Use this material | Keep this record |
| --- | --- | --- |
| Sales | Sections 1-3: qualification, demonstration and proposal | One opportunity brief and a dated next action |
| Pilot | Sections 4-5: delivery plan, measures and decision | Agreed pilot charter and evidence scorecard |
| Onboarding | Sections 6-8: provisioning, go-live and handover | Readiness checklist and service handover |
| Continuous improvement | Section 9 and the template pack | Stage metrics, feedback and named follow-ups |

### What is fixed, and what is agreed

Keep the stage gates, accountable owners, evidence records and explicit decisions consistent. Agree the scope, price, dates, deployment model, data boundary, integrations and service arrangements for each customer. Suggested timings in this guide are planning defaults, not delivery guarantees.

This is a public reference process, not a contract, service-level agreement or certification statement. The executed order, statement of work and applicable terms govern each engagement. Commercial arrangements, product availability and customer-specific approvals must be confirmed before commitment.

The checklists and sales metrics describe an operating method; they do not imply that AIDE automatically runs the sales pipeline or replaces customer governance. Use the approved CRM or project workspace to maintain the records.

> **Public information only**
> Blank templates may be shared. Completed records, commercial details, customer evidence and diagnostics belong in the agreed restricted workspace, not on this website.


## 1. The customer journey

A stage changes only when its exit evidence exists. A successful meeting is not the same as an accepted pilot or a live customer.

| Stage and owner | Minimum activity | Exit evidence / next decision |
| --- | --- | --- |
| Qualify / Sales lead + customer champion | Confirm the problem, affected scope, sponsor, urgency and buying route. | Opportunity brief; proceed, nurture or decline. |
| Discover and demonstrate / Sales / solution lead | Use the customer's problem to select the relevant Chain or Blueprint workflow. | Customer confirms relevance; next review and decision owner named. |
| Agree pilot / Commercial lead + sponsor | Agree scope, measures, fees, access, data approvals, responsibilities and exit. | Approved charter/order; readiness conditions met. |
| Run and evaluate / Pilot lead + customer lead | Establish baseline, configure, operate, collect evidence and review. | Signed decision: proceed, extend with conditions, or stop. |
| Onboard and accept / Onboarding lead + customer Owner | Provision or transition the environment; validate data, roles, training and support. | Go-live acceptance, or explicit hold with actions. |
| Stabilise and support / Service owner + customer administrator | Complete agreed hypercare, handover and value reviews. | Operational acceptance; review and renewal dates recorded. |

### One route, several entry points

Direct outreach, referrals, partners and tenders enter the same qualification process. Record the originating channel and a single opportunity owner. For partner-led work, agree who sells, contracts, implements and supports. For tenders, follow the stated procurement process and permitted communications; a product fit is not proof of supplier eligibility.

### Named responsibilities

The customer sponsor owns the business decision and outcome. The customer Owner owns organisation access and subscription decisions. The delivery lead or architect validates the operating model. The technical/data lead approves source access and mappings. The AIDE/JEL lead coordinates delivery; the named service owner receives the handover. One person may hold several roles, but approvals and evidence validation remain explicit.

> **Direct-to-production option**
> A pilot is not mandatory when fit and acceptance evidence already exist. Document the reason for skipping it and retain the same commercial, security, onboarding and go-live gates.


## 2. Standard sales and discovery

Find out whether there is a problem worth solving before spending time on a broad product demonstration.

| Qualification area | Questions to resolve |
| --- | --- |
| Problem and consequence | What is difficult today? Where is time lost, evidence fragmented, risk hidden or architecture disconnected from delivery? What happens if nothing changes? |
| Scope and product fit | Which programme/projects or architecture domain matter first? Does the buyer need Chain, Blueprint or both? What must remain in existing systems? |
| People and authority | Who experiences the problem, champions the work, funds it and approves the purchase? Who will operate the service? |
| Evidence and access | Which sources are authoritative? Who owns them? Can an approved sample, manual input or supported connector supply the minimum evidence? |
| Timing and procurement | Why now? What budget/funding path and procurement route apply? What are the decision dates and mandatory conditions? |
| Security and adoption | What data, residency, identity, assurance and supplier-review gates apply? Who has time to participate and change the reporting/review process? |

### Suggested discovery meeting: 30 minutes

Use 5 minutes to establish context, 10 to understand the problem and current process, 10 to confirm scope, stakeholders and constraints, and 5 to agree the next action. Send a short factual recap for correction rather than assuming agreement.

### Qualification decision

Proceed when a material problem, accountable sponsor/champion, feasible initial scope and credible decision path exist. Nurture when fit is plausible but timing, funding or access is not ready. Decline or refer when mandatory requirements cannot be met, the problem is too small, or the buyer expects autonomous authority or unsupported functionality.

### Minimum opportunity record

Organisation and opportunity ID; channel/partner; customer problem in their words; selected product; sponsor and champion; indicative scope; buying route and timing; security/data gates; current stage; next action, owner and date. Record stated objections separately from sales assumptions.

> **Measure organisations, not just messages**
> Multiple messages or contacts can belong to one organisation. Deduplicate the opportunity before counting pipeline. A reply or booked meeting alone is not a qualified buying opportunity.


## 3. Demonstration and commercial proposal

Show the shortest credible path from the buyer's problem to a decision-useful result.

| Product track | Demonstrate | Confirm with the customer |
| --- | --- | --- |
| AIDE Chain | Approved delivery evidence; project/programme view; a material signal or dependency; an authorised response and its record. | Which governance decision becomes easier, earlier or better evidenced? |
| AIDE Blueprint | Bounded business/application/data/technology scope; current and target state; reconciled gaps and a proposed roadmap. | Which architecture question, dependency or change decision becomes clearer? |
| Both products | An approved architecture gap connected to delivery work, using licensed and available functionality. | Who owns the handoff from architecture intent to delivery and verification? |

Use synthetic or explicitly approved demonstration data. Distinguish a demonstration from customer-validated evidence. Do not imply that discovery produces an authoritative architecture without reconciliation, or that a recommendation authorises external work.

### A simple offer structure

| Offer | Standard boundary |
| --- | --- |
| Discovery / demonstration | Confirm relevance and a next decision. Any paid diagnostic is separately scoped and agreed; it is not a prerequisite for every buyer. |
| Bounded pilot | A defined product scope, evaluation period, named users, limited data sources, success measures and decision date. State pilot licence and service fees, including any agreed conversion credit. |
| Production subscription | Agreed products, plan, seats, term and billing. Identify onboarding, integration or consulting work separately, rather than implying it is included in every licence. |

### Proposal contents

Include the problem/outcome, deliverables and exclusions, customer and supplier responsibilities, dates and dependencies, licence/service charges, currency and applicable taxes, acceptance criteria, data and security arrangements, support coverage, change control and exit. Identify the contracting entity and the authorised approvers. Never infer price or entitlement from a previous customer deal.

> **Claims and procurement discipline**
> Confirm connector support, deployment choices, marketplace/panel availability and mandatory assurance requirements for this specific purchase. Do not promise unimplemented roadmap items, certification, guaranteed savings, zero-risk operation or a headcount reduction. Human decision authority stays with the customer.


## 4. The standard pilot

A recommended four-to-six-week evaluation after readiness is confirmed; the charter sets the actual duration and commitments.

### Bound the first implementation

For Chain, a useful starting shape is one organisation, one programme and three to five related projects, adjusted to the smallest meaningful use case. For Blueprint, select one business/service domain and an agreed inventory boundary. Start with one or two priority sources and a small role-based group. A pilot of both products needs explicit scope for each.

| Phase | Activities and outputs | Owner / gate |
| --- | --- | --- |
| Before day 1 / Readiness | Approve charter/order, sponsor, participants, access, data permissions, baseline method, commercial terms and support route. | Joint leads confirm readiness. Do not start the evaluation clock with essential access missing. |
| Week 1 / Baseline and configure | Record current effort/decision cycle; establish scope and roles; reconcile a representative data sample; set up the first view. | Customer data lead validates evidence; pilot lead logs gaps. |
| Week 2 / Calibrate and train | Agree tolerances or architecture reconciliation rules; validate signals/mappings; train operators and test support contact. | Customer delivery lead/architect approves the usable baseline. |
| Weeks 3-4 / Operate and measure | Run agreed governance/architecture reviews; record decisions, reporting effort, evidence quality, adoption and issues. | Joint weekly review maintains the scorecard and actions. |
| Weeks 5-6, only if agreed / Additional evidence | Use an agreed extension for an insufficient sample or defined remediation, not an open-ended free trial. | Record reason, revised scope/fees and final decision date. |
| Final review / Decide | Compare results with the pre-agreed thresholds and costs; review open risks and production readiness. | Sponsor chooses proceed, extend with conditions, or stop. |

### Keep the pilot governable

Default to read-only source access and approved manual evidence where appropriate. Record authoritative sources, refresh expectations, baseline versions, users and data exclusions. Keep decisions human-approved. Scope changes require an impact review and an explicit agreement on time, effort, price and success criteria.

> **Weekly review: 30 minutes**
> Review the scorecard, data quality and usage; demonstrate one useful finding or workflow; triage issues; and agree the next action with an owner and due date. Keep the sponsor informed of anything that threatens a valid evaluation.


## 5. Pilot scorecard and decision

Choose a small number of measures before the pilot starts. Thresholds below are to be agreed; no improvement is guaranteed.

| Measure | Baseline and measurement method | Acceptance to agree |
| --- | --- | --- |
| Reporting effort / Chain / both | Minutes or hours preparing the same report/review before and during the pilot; record sample count and scope changes. | Target reduction or time ceiling, comparable periods, evidence owner. |
| Decision latency / Chain / both | Elapsed time from a recorded signal or issue to an authorised decision. Report median and exceptions. | Target elapsed time and minimum number of comparable decisions. |
| Evidence quality / Either product | Sample selected records against their authoritative sources; record mappings, freshness and exceptions. | Sample size; acceptable reconciliation/freshness level; critical gaps allowed. |
| Architecture decision value / Blueprint | Record reconciliation effort and a traced path from the selected business need through current/target state to an approved gap or roadmap item. | Named architect validates completeness and usefulness of the selected scope. |
| Useful signals / findings / Either product | Log useful, false and missed warnings or relationships; have the operating team judge the result. | Useful findings required; tolerable noise; limitations documented. |
| Adoption and operability / Either product | Named users complete the agreed workflow; customer administrator tests access and support; record incidents and workarounds. | Roles trained, core workflow demonstrated and no blocking readiness issue. |

### Be precise about value

Effort reduction (%) = (baseline effort - pilot effort) / baseline effort x 100, only when the baseline is non-zero and the work is comparable. Time saved x an agreed labour rate estimates released capacity, not automatically cash savings. Compare expected benefits with licence, implementation, integration and operating costs. Separate observations from assumptions and avoid attributing every improvement to AIDE.

### Make the final decision explicit

Proceed when the agreed evidence is sufficient, mandatory gates are met and the buyer approves the commercial case. Extend only for a named evidence gap or remediation with a revised end date and cost agreement. Stop when fit, readiness or value is inadequate; record the reason and apply the agreed export, access-revocation and data-retention/deletion process.

> **Pilot success is not production acceptance**
> A positive pilot does not itself authorise a production subscription, unrestricted data use or go-live. Complete the purchase and operational readiness gates separately.


## 6. Repeatable customer onboarding

The customer factory accelerates provisioning. Onboarding proves the customer can use and operate the service.

| Step | AIDE/JEL activity | Customer input / acceptance evidence |
| --- | --- | --- |
| 1. Mobilise | Confirm order, products, seats, deployment model, onboarding lead, target dates and acceptance plan. | Sponsor/Owner, technical/data leads, authorised scope, data classification and purchasing approvals. |
| 2. Prepare | Prepare the approved customer configuration and environment details using the customer-factory process where applicable. | Correct organisation, named Owner, selected modules and approved hosting/access requirements. |
| 3. Deploy and validate | Provision the agreed environment, apply baseline configuration and perform automated validation. | Record the validated target and any exceptions. Provisioning alone is not billing approval or go-live. |
| 4. Complete human checks | Verify Owner sign-in, actual password-recovery email, clean customer workspace and correct entitlements. | Owner confirms access; privileged roles/MFA checked; no demonstration or other customer records in the live scope. |
| 5. Configure and connect | Set roles, initial programme/projects or architecture boundary; connect one approved source at a time. | Least-privilege credentials transferred securely; source owner confirms mapping and sample reconciliation. |
| 6. Calibrate and train | Agree controls/decision rights or architecture reconciliation; train users and administrators; run a first review. | Customer completes the selected workflow using approved evidence and understands limitations/escalation. |
| 7. Accept and hand over | Complete go-live checklist, support test, known-issue disposition and the service handover record. | Sponsor/Owner accepts readiness or records a hold; hypercare and review dates agreed. |

### Integration acceptance

For each source, record owner, approved dataset, permissions, connector/version availability, field mapping, refresh cadence and error handling. Configure, test, preview where supported, import/refresh, inspect and reconcile. Never put passwords or API tokens in the charter, email thread, public form or support ticket.

### Transition rather than assume

For a successful pilot, agree which configuration and evidence may carry into production, what must be cleansed or revalidated, and whether the same environment remains appropriate. For an existing customer tenant, validate the configuration rather than blindly reprovisioning it. Do not activate paid billing without the agreed purchasing authority.

> **Boundary before speed**
> Do not load restricted customer or procurement material until its use, hosting and access are authorised. Confirm any cloud, third-party or AI-processing restrictions before using those tools with customer information.


## 7. Go-live readiness and service boundary

Every applicable item needs an owner, evidence reference and pass/hold decision. Explain any approved not-applicable item.

| Readiness item | Pass evidence |
| --- | --- |
| Commercial and scope | Approved production order; correct products, plan, seats and billing; scope and exclusions understood. |
| Data and environment | Approved data/hosting boundary; correct customer workspace; agreed pilot-to-production transition completed. |
| Identity and access | Owner sign-in, MFA/recovery and named user roles verified; selected-project access and invitations reviewed. |
| Core workflow | Customer demonstrates the selected Chain control review or Blueprint reconciliation/roadmap workflow. |
| Integrations and evidence | Priority sources pass connectivity and reconciliation; freshness expectations and failure handling are understood. |
| Security and recovery | Customer-specific mandatory gates met; applicable monitoring, backup/recovery responsibilities and evidence confirmed. |
| Training and adoption | Administrator and relevant operators trained; materials and the first operating review scheduled. |
| Support and escalation | A monitored support route is named and tested; service owner, contacts, coverage and escalation are recorded. |
| Known issues | No unresolved issue blocks safe productive use. Non-blocking issues have an accepted owner, workaround/plan and date. |
| Acceptance and handover | Customer acceptance, hypercare plan, handover record and next value-review date are recorded. |

### Complete a support schedule, not an implied SLA

Record the actual support channel, authorised contacts, support hours/time zone, public holidays, severity definitions, initial-response targets, update cadence, escalation and any agreed recovery objectives. Distinguish response from resolution. Australian, New Zealand and Singapore customers should agree the applicable service clock and daylight-saving treatment.

The public Support page describes indicative response targets. This guide does not create a binding SLA, 24/7 service, service-credit entitlement or guaranteed resolution time. Confirm any contractual commitments and the staffing/tooling needed to deliver them before signing. Where a ticketing or operations layer is still being established, agree and test an interim monitored route before go-live.

> **Stop / hold rule**
> A missing mandatory security approval, inaccessible Owner account, untrusted critical evidence or unowned support route is a go-live hold, not an administrative detail. Record who can clear it and the evidence required.


## 8. Hypercare, handover and customer success

Plan the transition to ordinary operation at the start, rather than leaving the pilot team as permanent informal support.

### Suggested hypercare pattern

Allow approximately two weeks after go-live as a planning default; agree a longer period for complex integrations or greater risk. The order/onboarding plan sets actual coverage and commitments. Review environment/integration health, usability, open incidents and adoption. Schedule two proactive customer touchpoints per week where agreed.

| Handover area | Information to record |
| --- | --- |
| Ownership and scope | Customer sponsor/Owner, service owner, administrators, subscribed products, accepted use case and support boundary. |
| Configuration and evidence | Approved baseline/configuration version; priority integrations and source owners; operating cadence; restricted evidence location. |
| Support and recovery | Support channel and tested case reference; escalation; coverage; relevant recovery/retention responsibilities and controlled runbooks. |
| Training and known issues | Training completed, documentation links, open issues, workarounds, owners and due dates. |
| Commercial and success reviews | Acceptance date; hypercare exit; next review; contract/renewal notice dates; measurable outcomes and accountable customer owner. |

### Hypercare exit

Exit when there is no unresolved critical incident, major issues have an accepted plan or workaround, priority integrations are stable, the customer administrator can perform normal tasks, and the support process has been successfully exercised. Record customer/service-owner agreement and retain the known-issue register.

### Suggested first 90 days

At approximately day 30, review adoption, evidence quality and operating friction. At day 60, revisit measured value and tune the selected model. At day 90, decide whether to maintain scope, improve adoption or expand. Align these reviews to the contract term and customer governance calendar; they are not automatic service entitlements.

> **Expansion follows demonstrated use**
> Add projects, users, programmes or architecture scope only where the customer has a reason to do so and the relevant products/entitlements are agreed. Reference stories, logos and case studies require separate customer permission.


## 9. Run a measurable, lightweight process

Use one weekly commercial/delivery review. Keep definitions stable so marketing, sales and onboarding measure the same journey.

| Metric or record | Definition / operating rule |
| --- | --- |
| Outreach and engagement | Track messages/touches separately from unique people and unique organisations. Record campaign/variant and channel. |
| Meetings and qualification | Separate booked from held meetings. Count qualified opportunities only after the qualification gate. |
| Stage conversion | Use a stated cohort/time period and denominator. Stage conversion = opportunities advancing / opportunities eligible to advance. Do not treat repeated messages as independent buyers. |
| Pilot performance | Track pilots agreed, readiness achieved, started, completed and the proceed/extend/stop decision; record duration and reasons for delay. |
| Customer status | Distinguish contract signed, paid subscription active, environment provisioned, operationally accepted and renewed. Do not count a demonstration or free pilot as a paying production customer. |
| Time to value / go-live | Agree the start event; record readiness date, first customer-validated useful result and go-live acceptance separately. |
| Value and service quality | Track scorecard outcomes, adoption, material incidents, customer feedback and renewal risk; distinguish recurring licence revenue from one-off services. |
| Learning and actions | Record stated loss/no-decision reasons, feature/assurance gaps and next actions. A request is not an approved roadmap promise. |

### Weekly review agenda

Review qualified pipeline and next actions; upcoming demos/proposals; pilot readiness and evidence; onboarding holds and service issues; then one or two improvements to test. Assign an owner and due date to each action. Avoid changing multiple campaign variables and the qualification definition at the same time.

### Record handling

Keep only the business-contact information needed for the agreed sales process. Honour contact preferences and applicable outreach requirements. Store completed templates in an access-controlled workspace. No customer names, pricing, credentials, data extracts, incident detail or private architecture should be copied into this public guide.

> **Improve the process from evidence**
> Use observed conversion, delivery effort and customer results to refine offers and capacity. This guide sets a repeatable method; it does not predict close rates or guarantee a revenue outcome.


## 10. Reusable records and next steps

Use the separate downloadable template pack for editable copies. Replace every placeholder and obtain the required approvals before use.

| Template | Complete these fields | Who confirms |
| --- | --- | --- |
| A. Opportunity brief | Organisation/opportunity ID; channel; problem; product; sponsor/champion; scope; buying route; gates; next action and date. | Sales lead and customer champion validate the factual recap. |
| B. Pilot charter | Outcome; scope/exclusions; users; sources/data boundary; prerequisites; dates; work plan; fees; measures; responsibilities; support; exit/change rules. | Authorised customer and AIDE/JEL approvers. |
| C. Evidence scorecard | Measure; baseline; agreed target; method/sample; source; owner; review date; actual result; limitation; pass/hold. | Customer evidence owner and sponsor. |
| D. Readiness checklist | Each gate; accountable owner; evidence link; pass/hold/not-applicable; exception approval and due date. | Customer Owner/sponsor and onboarding lead. |
| E. Service handover | Scope; configuration; contacts; support schedule; tested route; recovery/retention responsibilities; training; known issues; hypercare exit; reviews. | Customer administrator and receiving service owner. |
| F. Pilot / go-live decision | Decision date; evidence reviewed; unmet criteria; commercial approval; conditions/actions; data/access disposition; acceptance. | Authorised decision-maker; no implied approval by silence. |

### Read alongside the product documentation

Sales Playbook: discovery, objection handling and claims discipline. Customer Onboarding: product selection, account security, seats, roles, telemetry and acceptance. Operating Guide and Integrations & Telemetry: product workflows and source configuration. Security, Assurance Readiness, Terms and Support: current boundaries and due-diligence material.

Documentation: https://aidechain.com.au/docs.html
Sales Playbook: https://aidechain.com.au/sales-playbook.html
Customer Onboarding: https://aidechain.com.au/onboarding.html
Support: https://aidechain.com.au/support.html

### Document control

Title: AIDE Chain & AIDE Blueprint - Sales, Pilot & Onboarding Guide. Version 1.0. Published 5 October 2026. Public customer and partner edition. Maintained for JEL Project Management. Review when product capabilities, commercial terms, support arrangements, deployment controls or customer learning change. The website copy is the reference version; completed customer records remain private.

> **Start with one useful problem**
> Bring a sponsor/champion, the delivery lead or architect, and the owner of the priority source. Leave the first workshop with a bounded use case, evidence question and a named next decision.