SALES PLAYBOOK · SEPTEMBER 2026
This playbook is for AIDE sales partners, business-development contacts and people introducing the product. The objective is not to push AIDE into every organisation. It is to identify a real delivery-control problem, understand whether AIDE fits, demonstrate the relevant capability and capture what we learn from both yes and no decisions.
AIDE sits above existing systems of record and turns delivery evidence into a cross-project control picture. It helps teams detect emerging problems sooner, understand dependencies and constraints, consider responses and retain an auditable record of interventions. It is designed to increase the leverage of good project and programme leaders rather than replace them.
AIDE does not require a customer to abandon Jira, Azure DevOps, Dynamics 365, Power BI, SAP, CMDB platforms or other systems that already hold operational data. Those systems can remain authoritative while AIDE provides the control layer above them.
The value proposition is not prettier status reporting. It is seeing delay, stale information, dependency pressure, resource constraints, risk and emerging loss of control early enough to act.
AIDE supports decisions with evidence, control signals and scenario views. Project managers, programme managers, sponsors and executives remain responsible for judgement, stakeholder engagement and authorised intervention.
Rather than hiding the path from evidence to action, AIDE keeps source context, control signals and intervention history visible so teams can understand what changed and whether it worked.
AIDE is most compelling where delivery is important enough that waiting, fragmented status, hidden dependencies or slow escalation have a measurable cost. Strong prospects often have several projects or programmes, multiple delivery systems, shared resources, senior governance obligations or an architecture/transformation agenda.
COO, CIO, CTO, transformation executive, programme sponsor, PMO leader, head of delivery, portfolio executive or business-unit leader accountable for delivery outcomes.
Experienced project/programme managers, enterprise architects, delivery assurance leads, transformation teams and operators who are frustrated by manual status chasing or late visibility.
Technology transformation, government programmes, regulated industries, complex services, infrastructure/telecommunications, portfolios with shared resources and organisations already using several systems of record.
A single small project with little coordination overhead, no meaningful delivery pain, no accountable owner, or a prospect looking for an autonomous system to run projects without human governance.
The strongest demo starts with the prospect's delivery problem. A short discovery conversation should establish where information currently comes from, where decisions slow down and what a better control picture would change.
“Where do projects usually lose time?” “What are people waiting for?” “How long does it take before senior management knows something is genuinely off track?”
“Which systems hold delivery, finance, risk or architecture evidence?” “How much status is still assembled manually?” “What happens when one source goes quiet?”
“Where do dependencies or shared people create surprises?” “Can you see the consequence of one project's delay on the rest of the programme?”
“When a problem appears, who can act?” “How are decisions recorded?” “Can you later tell whether the intervention actually improved the situation?”
Keep the demonstration anchored to the prospect's problem. Show only the AIDE areas needed to tell that story. If the prospect cares about cross-project resource pressure, spend time there. If they care about architecture-to-delivery traceability, use Blueprint. If they are security-heavy, use the public Solution Architecture, Security and Assurance Readiness material rather than improvising.
Response: AIDE is designed to give PMs leverage, not remove their accountability. It automates sensing, aggregation and early warning so experienced PMs can spend more time on decisions, stakeholders and delivery.
Useful line: “AIDE doesn't replace the project manager. It replaces the Friday afternoon spent chasing everybody for a status update.”
Follow-up: “Which parts of your PM workload are valuable judgement, and which parts are information chasing?”
Response: Good. AIDE is not trying to replace those systems. It is intended to consume approved evidence from them and build the cross-project control picture that individual systems usually cannot provide on their own.
Follow-up: “Where do you currently combine those sources when a sponsor wants one view of delivery?”
Response: Dashboards display information. AIDE's proposition is a control loop: observe evidence, identify a signal, understand system impact, consider a response, record an authorised intervention and observe what happened next.
Follow-up: “What happens after your dashboard turns red today?”
Response: No autonomous project authority is required for the core operating model. AIDE is a decision-support and control platform. Human users retain responsibility for intervention and governance.
Follow-up: “Would better evidence and earlier warning help even if all decision authority stayed exactly where it is today?”
Response: AIDE treats source quality as part of the control problem. Telemetry can be classified by freshness and provenance, and automated polling is designed to fail closed when enabled sources are missing or conflicting unless the deployment explicitly allows otherwise.
Follow-up: “How do you know today when a project is reporting stale or incomplete information?”
Response: Current connected-system polling is designed as outbound read/pull telemetry. It creates AIDE control evidence and does not silently write changes back into Jira, Azure DevOps, Power BI, Dynamics 365 or SAP.
Follow-up: “Would a read-only pilot make internal approval easier?”
Response: Use the documented facts, not broad assurances. AIDE documents MFA, server-side RBAC, tenant controls, PostgreSQL row-level-security policy testing, hardened connector boundaries, application rate limits, private artefact storage, CI security scanning, SBOM generation, release-integrity verification, monitoring and tested recovery. Customer-specific requirements are assessed separately.
Follow-up: “What security or assurance gates would a pilot need to pass in your organisation?”
Response: Not currently. AIDE does not claim ISO/IEC 27001 certification or an existing SOC 2 Type II report. The public assurance material documents the current control/evidence base and the formal management-system and external-audit work required to pursue those outcomes.
Follow-up: “Is certification a hard gate before any pilot, or a requirement before production/procurement?”
Response: That may be possible. The question is whether building and maintaining the control model, integrations, tenant/security boundaries, assurance evidence and operating workflow is the best use of the organisation's delivery capability.
Follow-up: “What would you need to build, operate and assure internally to get the same outcome?”
Response: AIDE can begin incrementally. Start with a small number of projects, one or two trusted telemetry sources and a defined governance question rather than trying to re-platform the whole organisation.
Follow-up: “What is the smallest live problem we could prove without disturbing existing delivery?”
Response: Do not force the sale. Establish whether the problem is real and whether timing is the only barrier. A strong later opportunity is better than a weak immediate one.
Follow-up: “When is the next planning or funding point, and what evidence would make this worth revisiting?”
Response: That may be true. AIDE should not be sold where there is no meaningful control problem.
Follow-up: “If delivery risk increased or the portfolio became more complex, what would be the first symptom your current model would struggle with?”
For banks, government and other regulated organisations, assume the buyer will eventually ask about security, data boundaries, supplier assurance, recovery, auditability and deployment controls. Answer those questions from the published evidence rather than making promises in the room.
Explain what AIDE reads, where AIDE stores data, which systems remain authoritative, how tenant access is checked and whether the proposed pilot is read-only.
Current implemented controls, planned defence-in-depth work and external certification/attestation are deliberately separated in the documentation. Preserve that distinction in every sales conversation.
Find out whether ISO/IEC 27001, SOC 2 Type II, penetration testing, data residency, private connectivity or a customer-specific vendor-risk process is a pilot gate, a production gate or simply preferred evidence.
Use Solution Architecture, Security & Assurance, ISO/IEC 27001 & SOC 2 Readiness and Integrations & Telemetry as the baseline due-diligence material.
A successful demo does not need to end in a contract. It should end in a specific next step or a useful reason not to proceed.
The prospect asks for a second meeting, brings another decision-maker, wants a pilot, asks about pricing/procurement, provides integration details, requests security material or starts discussing a live project/programme.
A defined delivery problem, a named sponsor/champion, a bounded project or programme scope, known evidence sources and an agreed question such as “can we detect delay sooner?” or “can we expose cross-project dependency pressure?”
If the fit is poor, say so. Credibility matters more than forcing a weak opportunity into the pipeline.
Examples: technical review, security review, scoped pilot workshop, sponsor demo, integration discussion, pricing/procurement discussion or a specific date to revisit.
Rejections are market telemetry. Record enough structure that patterns can be analysed rather than remembered as anecdotes.
Sector, organisation size/complexity, role of the people involved, problem they were trying to solve and what initially attracted them to AIDE.
Before demo, after demo, technical review, security review, pilot proposal, pricing, procurement, internal approval or another stage.
Capture the stated reason and, separately, any inferred reason. Useful categories include low urgency, wrong buyer, product gap, integration gap, security/assurance gate, price, procurement friction, timing, incumbent preference, unclear value, adoption concern and PM/team threat perception.
Ask: “What would have needed to be different for this to have been worth proceeding with?” It usually produces more actionable information than simply asking “why not?”
Treat the sales process itself as a feedback system: lead → qualified conversation → demo → next step → pilot/commercial decision → won/lost → reason → adjustment. The objective is to learn which customers, messages and objections are repeatable enough to build a reliable sales motion.
Describe implemented capabilities, published architecture, current security controls, tested recovery processes, supported integrations and the assurance-readiness work documented on this site.
Do not claim AIDE is unhackable, fully autonomous, ISO/IEC 27001 certified, covered by a SOC 2 Type II report, IRAP-assessed, MAS/OSPAR compliant or guaranteed to improve project outcomes unless and until there is specific evidence supporting that statement.
If a prospect asks for a feature that is not currently implemented, capture it as a requirement and confirm it with the product owner rather than promising delivery in the meeting.
When a conversation moves into technical, security or procurement territory, send the relevant public documentation and arrange a follow-up with the product owner if deeper evidence is needed.
Solution Architecture Assurance Readiness Integrations & Telemetry Customer Onboarding
