CUSTOMER ONBOARDING · UPDATED AUGUST 2026
AIDE is designed so commercial access and tenant setup are quick. The substantive implementation effort should be spent connecting useful telemetry, modelling the delivery system, agreeing tolerances and establishing how the organisation will use the resulting control signals.
A customer is considered onboarded when the organisation is securely established, the correct product entitlements are active, the required team members have access within purchased seat limits, the initial projects/programmes or Blueprint scope exist, agreed telemetry is flowing and the customer has completed a first control review using real or approved pilot data.
Access should be the easy part. The value-creating work is establishing trustworthy evidence and a coherent picture of the delivery or architecture system.
AIDE Chain and AIDE Blueprint are separate products. The customer may purchase Chain, Blueprint or both. Entitlements are enforced separately even though both products share the same AIDE organisation and account experience.
For direct SaaS purchase, the Owner completes Stripe Checkout for the selected product/plan. Signed Stripe webhooks update AIDE's entitlement state. Later billing management is handled through the Stripe customer portal where applicable.
Where the Marketplace offer is enabled, the buyer purchases in Microsoft, follows the configure-account link, authenticates, and claims the verified marketplace subscription into an AIDE organisation. Marketplace lifecycle events then maintain the plan, quantity and status.
AIDE supports independent billing sources. An organisation can, for example, hold AIDE Chain through Microsoft Marketplace and later add Blueprint through Stripe.
A new production organisation with no active product is intentionally locked from delivery functions. The user can secure the account, activate products, manage eligible billing operations or switch to another organisation they already belong to.
The organisation is the tenant boundary for members, seats, projects, programmes, resources, architecture records, billing state and private artefacts. The first authorised customer user becomes the Owner.
For direct onboarding, an organisation is created for the customer before or during the commercial setup process. For Microsoft Marketplace, AIDE validates the Marketplace purchase and buyer identity before the subscription is claimed into an organisation. This avoids creating unowned or unverified commercial tenants.
Users who belong to multiple organisations can switch between them. An unpaid new organisation does not prevent the same user from returning to another paid organisation.
The Owner should complete the account-security steps before inviting the broader team:
Use a strong unique password and confirm that the account's email address is correct. Password recovery uses a time-limited recovery link rather than exposing an existing password.
Enrol TOTP authenticator MFA and securely retain the generated recovery codes. Existing MFA-enabled users must complete MFA when accepting invitations as well as during normal protected sign-in.
Confirm the organisation name, lifecycle information and administrative details that will identify the tenant to its members.
Optionally configure the organisation logo, primary/accent colours and light/dark presentation. Branding is applied across Projects, Programmes, Blueprint and the Admin Centre.
In production, AIDE Chain delivery routes require an active or trialling Chain entitlement. Blueprint routes require a separate active Blueprint entitlement. The Admin Centre remains the controlled place to view or activate subscriptions.
This means an invited user cannot accept an invitation to an unpaid organisation and then use an empty project/programme workspace for free. Product access is checked centrally on the server for each protected request.
Seat capacity is enforced during invitation creation and checked again when an invitation is accepted. AIDE treats existing organisation memberships and pending, unexpired invitations as reserved capacity. Suspended memberships remain seats until the member is removed.
Purchased seats must cover existing memberships plus outstanding valid invitations. Expired or revoked invitations no longer reserve capacity; removing a member frees the membership seat.
Invitations use one-time URL-safe tokens with a stored cryptographic hash, an expiry period and explicit revocation/replacement behaviour. Existing AIDE users must prove control of their account before the invitation is attached to it.
Full organisational authority, including billing, privileged roles and Owner-only controls. AIDE preserves at least one active Owner and prevents unsafe self-removal/suspension.
Manages organisation configuration, members and delivery administration but does not receive Owner-only or billing authority.
Operates project/programme control and organisation-wide delivery functions where portfolio scope is granted.
Can provide reports and telemetry evidence without receiving full project-control authority.
Read-only access for stakeholders who need visibility without operational change authority.
Can manage eligible billing operations without seeing project/programme delivery information.
Project access can be set to all organisation projects or selected projects. Where selected-project access is used, ungranted project identifiers are concealed rather than disclosed.
The first implementation should be deliberately bounded. The goal is to create enough structure to prove control value without spending weeks replicating every piece of existing portfolio data.
Create the initial projects and programme, define project relationships, dependencies, shared resources, budgets/tolerances, material risks and the decision points that the control room needs to observe.
Establish the architecture scope, business intent and current/target-state boundary. Decide which current-state evidence will be discovered/imported and which design decisions require explicit architect reconciliation.
Where Blueprint and Chain are both licensed, decide whether approved architecture gaps will compile directly into AIDE Chain projects/programmes and how architecture evidence will be used to verify delivery.
Packaged demos may be used for controlled training or product walkthroughs. Demo reset/selection controls are restricted to the Owner role and should not be treated as customer delivery records.
Do not integrate everything on day one. Start with the sources that materially affect programme or architecture decisions. For each source, agree the ownership, approved scope, evidence fields and refresh pattern.
The normal connector sequence is configure → test → preview where supported → import/refresh → inspect evidence → confirm mapping. Connector readiness is visible in the Admin Centre so an Owner/Administrator can see what remains to be configured or tested.
See Integrations & Telemetry for detailed guidance on Jira, Azure DevOps, Dynamics 365, Power BI, Azure Resource Graph discovery and CMDB/asset evidence.
Once the initial structure and telemetry exist, the customer defines how AIDE will be used operationally. This is more important than the mechanics of account creation.
Agree the schedule, budget, backlog, throughput, resource, risk or architecture conditions that should attract attention.
Identify cross-project or architecture-to-delivery relationships that can cause local problems to become programme problems.
Define which interventions are pre-approved, which require escalation and which roles are permitted to commit control changes.
Set an expected refresh rhythm for connected sources. AIDE distinguishes fresh, ageing, stale and silent telemetry so missing evidence is visible rather than treated as green.
For programmes, capture measurable benefits, accountable owners, targets, evidence gates, contributions and review cadence rather than assuming project completion equals realised value.
For Blueprint, agree who reconciles discovery observations, who approves baselines/target designs and how gaps are accepted into delivery.
The first review should answer practical questions using the live AIDE picture:
What is drifting? Which projects, dependencies, resources or architecture conditions are outside tolerance? What evidence is missing? Are any enabled telemetry sources stale or silent? What is the programme consequence? Does a local issue alter another project's delivery, a shared resource, a benefit or a target architecture outcome? What action is authorised? Can the team preview an intervention before committing it? What evidence will prove the action worked?
The intervention history then becomes part of the operating evidence for future reviews.
A practical onboarding acceptance check is:
The correct Chain/Blueprint products are active, the billing source is correctly displayed, and purchased seat quantity matches the intended team.
Owner MFA is enabled, privileged roles are understood, invitation/seat controls have been tested and customer-specific security actions are recorded.
The initial project/programme or architecture scope is represented accurately enough for the pilot/use case.
At least the agreed priority source is tested and supplying attributable evidence at the expected cadence.
The team can identify an attention signal, inspect its cause and programme impact, preview or record an authorised response and retain the decision evidence.
The Owner knows the public documentation, customer support route, billing management path and who is responsible for internal source-system access.
After the bounded implementation is accepted, the organisation can add further projects, programmes, Blueprint scope, telemetry sources and licensed members without rebuilding the tenant. The implementation pattern remains the same: add only the evidence and structure that improves the control picture.
For a customer using multiple organisations, each tenant remains independently entitled and isolated even where the same person is a member of more than one.
Bring the Owner/sponsor, delivery lead or enterprise architect, and one person who understands each priority source system. Leave the workshop with the bounded scope, role model, first telemetry source, key dependencies/tolerances and a date for the first evidence-based control review.
