01The engagement in brief
European EPC software provider · client anonymised
One due diligence made late, over-budget projects predictable, and the client’s own teams now keep them on budget
The client aimed to find out, with evidence, why fixed-price implementations ran over plan, where customer-critical controls were only assumed, and what to fix first, and then to run the controls with its own software teams.
Half the time to go-live — 12 → 6 weeks
86% of projects within budget — up from 60%
7.7 FTE of capacity freed — plus €240k a year of at-risk revenue saved
Due diligence mid-April – mid-July 2026 (12 weeks). Since then the client’s own teams run the controls. Measured by the client: the 12 months to March 2026 vs July – October 2026; project cohort started June – August 2026, all live. Client anonymised.
Client issue: The client, a European provider of document-management software for oil & gas and other capital projects with about 100 employees, engaged AIx2 for a single due diligence. Implementations ran 25% over estimated hours, the documented method ran four different ways, 30% of scope decisions lived only in meetings and e-mail, know-how sat with a few experts, and every customer security audit took three weeks to evidence.
Solution: Over 12 weeks AIx2 mapped the workflow and the data flow of implementation, support and release in parallel across 11 systems, translated workshop recordings, tickets and timesheets into one canonical text stream with CPU toolboxes on-premise, and fused them into an organization model. It was checked against the client’s own method and SLAs, ITIL 4, DevOps benchmarks and ISO 19650, and ISO/IEC 27001, GDPR and the EU AI Act, and its overrun forecast was backtested before hand-over. Being a software company, the client built the template library and controls into its own tools and runs them itself.
Impact: Projects started since June reached go-live in 6 weeks instead of 12, 6 of 7 stayed within budget and unrecorded scope changes fell below 5%. Audit evidence takes one day. The capacity freed is worth about €1.3M a year at cost; counting half of it plus retained revenue, the engagement paid back in month 6.
Time to go-live — From: 12 weeks; To: 6 weeks
Projects within budget — From: 60%; To: 86% (6 of 7)
Delivery method — From: 4 variants in practice; To: 1 template library, owned by the client
Scope decisions — From: 30% outside any system; To: under 5%
Audit evidence — From: 3 weeks; To: 1 day
02Results: measured
Three months after the due diligence, new projects finish in half the time and stay on budget
Closed cohort: every implementation started June – August 2026, after the template library was approved in week 7 of the due diligence, all now live (n = 7), compared with the 30 implementations of the 12 months to March 2026. Go-live: median; hours over estimate: average.
Time to go-live, weeks (shorter is better) — Before (Apr 2025 – Mar 2026): 12; After (started Jun – Aug 2026): 6
Projects within budget, % (actual ≤ 110% of estimate) — Before: 60; After: 86
Hours over estimate, % (average, vs original contracted estimate) — Before: 25; After: 8
Scope changes never recorded, % (decisions found only in meetings or e-mail) — Before: 30; After: <5
Overrun forecast, backtested on 15 past projects before use: caught 5 of 6 (83%) overruns ≥ 4 weeks before they showed in reporting, 1 of 6 flags (17%) false alarms. Support, customer, people and knowledge metrics: appendix §11.
How the results were verified: Figures taken from the client’s own project tool, timesheets, ticketing and audit records, compiled by its delivery office and finance team.
Same team size and contract types over the period; the one method change, a template library, came out of the due diligence.
The mechanism is traceable: 6 of 7 (86%) new projects started from an approved template, up from none.
AIx2 has not been involved since July 2026; the controls are run by the client’s own teams.
03Financial case
A due diligence paid back in month 6
Benefits ramp up from month 3 (July 2026) to full in month 7 (November 2026). Retained revenue is counted at gross margin; freed capacity at internal cost.
Chart: value (cash + half the freed capacity) against cash only. Payback: month 6 (Oct 2026). Value €2.27M. Cash only €0.51M.
Cash only pays back in month 13 (April 2027); with all freed capacity, month 5. Full table and three-year view: appendix §12.
Annual value at full performance: Cash: at-risk accounts saved, €240k ARR at 80% margin: €192k.
Capacity freed: 12,720 h ≈ 7.7 FTE of about 100 staff, at internal cost: €1.32M.
Change orders now invoiced: €125k July – October 2026, reported separately and not added, to avoid double counting.
Conclusion: The due diligence freed about 7.7 FTE of capacity and protected €240k of recurring revenue. Counting half the capacity, it returns about €850k a year and paid back in month 6. Over three years it returns about €2.27M, 17.5 times the fee; on cash alone, 4 times.
04How the work ran and security
Twelve weeks inside the client’s network, each phase signed off by a named owner
Weeks 0–5 · Connect and map: Read-only links to 11 systems, plus implementation workshops and documents with consent. Atlas mapped how work and data really flow.
Weeks 5–9 · Check: Compared with the client’s procedures, best practice and regulation. Each finding had evidence, a count and an owner; the template library was approved in week 7.
Weeks 9–12 · Forecast and hand over: Overrun forecast backtested on 15 past projects; templates, controls and the forecast handed to the client’s own teams to run.
Human sign-off at every step: every finding, the forecast and the final report were approved by the COO and CTO before release.
Data stayed on site: Ran inside the client’s network, with no cloud. Read-only connectors; personal data masked; meeting audio deleted after transcription. IT systems only: no link to control systems or OT networks.
How AIx2 accessed it: No inbound connections; work through a jump host controlled by the client, sessions recorded. Models ran locally with documented origin and were handed over as signed packages. All AIx2 access removed at the end of week 12.
Controls on Atlas itself: Role-based access, encryption at rest and in transit, tamper-evident audit log. Software bill of materials. Deletion of all client data at exit; supports GDPR and EU AI Act duties: data contracts, transparency, human oversight.
05What the work required
Five capabilities the due diligence depended on, and how common tool categories cover them
Process-analytics tools and data platforms are strong in their own scope, and Atlas reads from and feeds both. The right-hand column shows what each capability produced at this client.
Analyse system event logs; compare with a target process — Process-analytics tool: Core strength; Data platform: After pipelines are built; AIx2 Atlas: Yes; Evidence at this client: 4 implementation variants found instead of the 1 official method
Capture decisions that never reach a system (meetings, e-mail) — Process-analytics tool: Task and desktop mining; not meetings; Data platform: Custom build; AIx2 Atlas: Built in, transcribed on-premise; Evidence at this client: 30% of scope changes existed only in meetings and e-mail; now under 5%
Evidence per control for NIS2, ISO 27001, GDPR — Process-analytics tool: Limited; Data platform: Custom build; AIx2 Atlas: Built in; Evidence at this client: controls with evidence 55% → 98%; audit evidence 3 weeks → 1 day
Human approval of every result and model update — Process-analytics tool: Not enforced; Data platform: Custom build; AIx2 Atlas: Mandatory; Evidence at this client: every finding and the forecast signed off by a named owner
Deployment — Process-analytics tool: Typically cloud; Data platform: Typically cloud-first; AIx2 Atlas: Inside the client network, CPU-only; Evidence at this client: no customer data left the client’s servers
Comparison by category, not by vendor; capabilities vary by product and edition.
06What this means for an operator
What these results imply for capital projects, maintenance and change control
Overruns flagged 4–6 weeks before they show in reporting (backtest: 5 of 6) — Operator equivalent: Capital-project and turnaround overruns, flagged while still fixable
Unrecorded scope changes cut from 30% to under 5% — Operator equivalent: Management of change and contractor change orders captured as they are agreed
Ticket → defect → release loop linked — Operator equivalent: Work order → failure → maintenance-strategy loop linked
Audit evidence in 1 day instead of 3 weeks — Operator equivalent: NIS2 and ISO 27001 audit evidence always ready
New experts autonomous in 6 weeks instead of 4 months — Operator equivalent: Engineering and operations know-how kept as experienced staff retire
Where the transfer is direct: Scope and change capture, the link between hours, scope and templates, and control-to-evidence mapping use the same Atlas components and data contracts on any project organization.
What an operating site adds: Work-order backlogs (e.g. SAP PM), schedules (e.g. Primavera P6), contractor document status and MoC registers, and many more contractors. This client is a software company, not an operator: these elements were not part of this engagement.
Why one due diligence was enough here: The client has its own engineering team and its process data lives in systems, so it could build and run the controls itself. A less mature organization would need a managed service to keep them in place.
07Timeline, status and lessons
Twelve weeks of due diligence, then three months run by the client’s own teams
Connect · Apr. Map · May. Check · May – Jun. Forecast & hand-over · Jul. Client runs the controls · Jul – Oct 2026.
Where it stands, October 2026: Template library in the client’s own tools since June; 6 of 7 new projects use it. Scope-change step and change-order invoicing live; €125k invoiced July – October. Overrun forecast run monthly by the delivery office. One customer security audit evidenced in one day.
What made it work: A software team able to build the controls into its own product and tools. Workshop recordings made hidden scope decisions visible. Each finding came with a count, evidence and an owner. The forecast was backtested before anyone relied on it.
Who owned what: CEO: scope and priorities. COO: delivery, capacity, sign-off. CTO: system access, releases, AI features. ISMS lead and DPO: data contracts, consent, regulatory checks. AIx2: connections, mapping, checks, forecast, report.
08Appendix · Engagement report: 01 Executive summary
AIx2 Atlas at a European EPC software provider
The detail behind the CEO deck: scope, how the work ran, findings, measured results and the financial calculation. The client is anonymised at its request.
Engagement: mid-April – mid-July 2026 · one 12-week due diligence · since then run by the client.
The client sells document-management software for oil & gas capital projects. Its revenue depends on three engines: implementing the product for each customer project, support, and product development. Before the engagement these ran on separate tools (CRM, ticketing, code repository, timesheets, e-mail), so delays, churn risk and release problems became visible only after they had happened.
In 12 weeks AIx2 mapped how work and data really flow in all three engines, linked them into one model of the organization, and checked them against the client’s own procedures, best practice and regulation. The overrun forecast was backtested in weeks 9–11 and handed over in July 2026. Being a software company, the client built the template library and controls into its own tools and runs them itself. Each result was approved by a named client owner before use.
Measured July – October 2026: go-live 12 → 6 weeks; projects within budget 60% → 86%; hours over estimate 25% → 8%; audit evidence 3 weeks → 1 day. Annual value: €240k ARR saved on at-risk accounts (cash) plus 12,720 hours of capacity freed (≈ 7.7 FTE, €1.3M at cost); change orders invoiced since July: €125k.
0902 Client profile
Company — European software provider for capital-project document management, mainly oil & gas EPC
Product — Engineering document management: submittals, comments, revisions and handover; AI document comparison and tagging; integration with ERP and planning tools
Customers — EPC contractors, engineering companies, project owners and vendors in oil & gas, mining and renewables
Size — ≈ 100 employees
1003 Operating model and processes mapped
Strategy & roadmap → Sales & partners → Pre-sales → Contract → Implementation → Go-live → Support & customer success → Renewal
Sales to contract — Sub-processes: qualification, demo, RFP and security questionnaire, pricing, statement of work; Systems and traces: CRM, e-mail metadata, RFP documents
Implementation — Sub-processes: kick-off, workflow design, document-register templates (MDR / VDRL), legacy migration, ERP and planning integration, user testing, training, go-live; Systems and traces: project tool, timesheets, workshops, configuration logs
Support — Sub-processes: intake, triage, escalation, defect diagnosis, hotfix; Systems and traces: ticketing, issue tracker
Product development — Sub-processes: roadmap, sprint, code review, testing, release, operations; Systems and traces: code repository, build pipeline, monitoring
AI features — Sub-processes: training, evaluation and monitoring of document-comparison models; Systems and traces: model repository, inference logs
Security & compliance — Sub-processes: information-security management, access management, customer audits, data protection; Systems and traces: policies, access logs, identity management
1104 Pain points diagnosed
Ranked by impact, confirmed with evidence in weeks 2–9.
1 · Unpredictable implementations — Rating: Critical; Root cause: each project configured from scratch; scope changed in workshops without a record; Business impact: 25% hours over estimate on fixed-price work
2 · Know-how held by a few experts — Rating: Critical; Root cause: configuration decisions made in workshops and e-mail, not in a system; Business impact: key-person risk; slow onboarding
3 · Slow security evidence — Rating: Critical; Root cause: control evidence spread across systems; Business impact: longer sales cycles with security-sensitive customers
4 · Ticket → defect → release loop not linked — Rating: High; Root cause: ticketing, issue tracker and code repository unconnected; Business impact: slow resolution; renewal risk
5 · No early view of customer risk — Rating: High; Root cause: usage, ticket and satisfaction signals never combined; Business impact: lost recurring revenue
6 · AI feature governance — Rating: High; Root cause: no formal accuracy and drift monitoring; Business impact: EU AI Act exposure; customer trust
7 · Consultant capacity — Rating: Medium; Root cause: resourcing by urgency, not by project risk; Business impact: one team in sustained overtime while others had slack
1205 Scope and data access
All connections read-only, each with a data contract approved by a named owner and the DPO.
CRM & service desk (HubSpot) — Data used: deals and stages, change orders, renewals, tickets, SLA timestamps; Method: read-only API; Privacy: no e-mail bodies; ticket text after personal-data masking
Project tool & timesheets — Data used: phases, milestones, hours, change requests; Method: read-only API; Privacy: names replaced by roles
HR system (Zoho People) — Data used: HR requests and SLAs, overtime and open work by team; Method: read-only API; Privacy: team level only; no individual scoring; agreed with the works council
Issue tracker, code repository & build pipeline — Data used: issues, changes, reviews, builds, deployments, rollbacks; Method: read-only API; Privacy: metadata only
Product configuration logs — Data used: workflow designs, templates, roles; Method: export; Privacy: end-customer consent, anonymised
Product usage — Data used: module and AI-feature usage; Method: aggregated export; Privacy: aggregated
Meetings & workshops — Data used: implementation workshops, steering, sprint reviews; Method: recorded with per-series consent, transcribed on-premise; Privacy: transcript only; audio deleted
E-mail — Data used: sender role, timestamp, thread; Method: mail-server metadata export; Privacy: no message bodies
Documents & knowledge base (Confluence) — Data used: methodology, SLAs, security policies, statements of work, configuration and support articles; Method: read-only API; Privacy: access tags kept
Identity & access logs — Data used: roles, permissions, sign-in events; Method: export; Privacy: pseudonymised IDs
Finance — Data used: billing, project cost; Method: export; Privacy: aggregated
Example of the single timeline Atlas builds from a workshop, a timesheet and a ticket:
[2026-03-04 10:12] PROJECT IMPL-07 · decide-scope · Customer PM, client lead — “Add vendor transmittal workflow for 3 packages; not in SOW” · source: workshop-12 @00:41:12 · confidence 0.93
[2026-03-06 16:40] PROJECT IMPL-07 · log-hours · Consultant · 14.0 h · task: workflow design · source: timesheet
[2026-03-09 09:05] TICKET 41877 · open · high · “Comment consolidation drops markups” · linked to release 5.8.2
1306 How the work ran
Each step ends with results reviewed and signed off in Atlas by the named client owner.
1 · Connect — What we did: registered 11 sources with data contracts; read-only links; personal-data masking; Output signed off: every source has an owner and a contract
2 · Map — What we did: rebuilt each project, ticket and release as a timeline across systems; found decisions that existed only in meetings and e-mail; Output signed off: map of how work really flows + map of where data comes from and goes
3 · Check: own rules — What we did: compared with the implementation methodology, contractual SLAs and release procedure; Output signed off: deviations with exact counts
4 · Check: best practice — What we did: ITIL 4 (service management), DevOps research benchmarks, PMBOK / PRINCE2, ISO 19650 and IEC 82045 (document management); Output signed off: distance to best practice
5 · Check: regulation & contracts — What we did: ISO/IEC 27001, GDPR, EU AI Act, customer contract clauses; Output signed off: compliance matrix: met · partial · not met · no evidence
6 · Forecast & hand over — What we did: overrun and renewal-risk forecasts backtested; templates, controls and forecasts handed to the client’s own teams in July 2026; Output signed off: backtest and hand-over approved by COO and CTO
1407 Process and data findings by level
Strategy — roadmap priorities were not linked to usage and churn data
Strategy execution — resources allocated by urgency, not by risk
Detailed processes — 4 implementation variants in practice instead of 1 official method; 30% of scope changes outside any system
Outcomes — go-live recorded, but stability after go-live not measured
Data governance — areas checked: data lifecycle, KPI definitions across teams, lineage of AI training data
1508 What the organization model answers
Which implementation will overrun time or budget? — Signals: hours, scope changes, milestone slip, variant; Warning time: 4–6 weeks before it shows in reporting; Validation: backtested on 15 projects of the prior 6 months: 5 of 6 overruns (83%) caught, 1 of 6 flags (17%) false alarms
Which release will cause problems? — Signals: change size, test coverage, modules touched; Warning time: before release; Validation: checked at each release
Which customer may not renew? — Signals: usage, tickets, sentiment, contract events; Warning time: 60–90 days; Validation: flags reviewed monthly with customer success
What if a key consultant leaves? — Signals: who configured what, on which projects; Warning time: what-if; Validation: reviewed with delivery leads
Is capacity enough next quarter? — Signals: pipeline, project risk, calendars; Warning time: 12 weeks; Validation: compared with actuals monthly
Technical note: forecasting uses survival analysis, gradient boosting and graph models, all running on CPU on the client’s servers.
1609 Check findings (summary)
Details, counts and severities were shared with the client only. Each finding had evidence, an owner and a due date in Atlas.
Own rules — Area of finding: sequence of design sign-off and testing; support response times; release procedure; Owner: Delivery, Support, CTO
Best practice — Area of finding: change-failure rate against the DevOps benchmark; problem management for repeat tickets; Owner: CTO, Support
Regulation — Area of finding: access-review evidence; end-of-project data lifecycle; AI transparency documentation; Owner: ISMS lead, DPO, Head of AI
By month 12, ISO/IEC 27001 controls with live evidence rose from 55% to 98% (§11).
1710 Deliverables in operation
Process and data maps — Content: how sales, implementation, support and release really run, with data owners; Cadence: live
Executive readout — Content: risks, progress on each improvement, next actions; Cadence: monthly
Configuration template library — Content: repeating implementation patterns extracted from workshops and logs; Cadence: updated as patterns change
Security audit pack — Content: questionnaire answers with evidence per control; Cadence: always ready
Project risk forecast — Content: overrun probability per implementation, with drivers; Cadence: daily
Customer risk forecast — Content: renewal risk with cause; Cadence: weekly
Release check — Content: risk score before each release; Cadence: every release
AI model monitoring — Content: accuracy, drift and transparency documentation; Cadence: monthly
Deal and change-order view — Content: time in security review, stalled deals, scope changes raised as change-order deals; Cadence: weekly
Team workload view — Content: HR request SLAs, overtime and open work per person, by team only; Cadence: monthly
Knowledge coverage map — Content: templates in use, single-author topics, recurring ticket types without an article; Cadence: monthly
Decision-support agents propose actions (project alerts, risk escalations, compliance reminders, profitability checks); a named person approves each one.
1811 Measured results
Baseline: the 12 months to March 2026. Project metrics: closed cohort of every implementation started June – August 2026, all live, medians. Other metrics: July – October 2026, after hand-over. People metrics are reported by team only; no individual is scored. The window is short: results are early and will be re-measured at month 12.
Projects & delivery · Time to go-live — Definition: kick-off to first production use, median; Baseline: 12 wks; After (Jul – Oct 2026): 6 wks; Sample / window: closed cohort, n = 7, started Jun – Aug 2026; Source: project tool
Projects & delivery · Projects within budget — Definition: actual ≤ 110% of original contracted estimate; Baseline: 60%; After (Jul – Oct 2026): 86%; Sample / window: same cohort; Source: project tool, timesheets
Projects & delivery · Hours over estimate — Definition: (actual − original contracted estimate) ÷ original estimate, average; Baseline: 25%; After (Jul – Oct 2026): 8%; Sample / window: same cohort; Source: timesheets
Projects & delivery · Unrecorded scope changes — Definition: scope decisions outside any system; Baseline: 30%; After (Jul – Oct 2026): < 5%; Sample / window: same cohort; Source: meetings, e-mail, project tool
Projects & delivery · Change orders raised as deals — Definition: recorded scope changes turned into change-order deals: count · value; Baseline: 7 · €55k; After (Jul – Oct 2026): 16 · €125k; Sample / window: baseline 12 months; after Jul – Oct 2026; Source: HubSpot
Knowledge · New projects started from an approved template — Definition: share of new implementations using the template library; Baseline: 0% (no library); After (Jul – Oct 2026): 86% (6 of 7); Sample / window: same cohort; Source: Confluence, project tool
Knowledge · Configuration topics held by one person — Definition: topics documented or answered by a single person only; Baseline: 64%; After (Jul – Oct 2026): 18%; Sample / window: 140 configuration topics; Source: Confluence, workshop transcripts
Knowledge · Recurring ticket types with an approved article — Definition: recurring ticket types covered by a reviewed article; Baseline: 21%; After (Jul – Oct 2026): 83%; Sample / window: 48 recurring types; Source: Confluence, HubSpot
Knowledge · New consultant time to autonomy — Definition: to first independent configuration; Baseline: 4 mo; After (Jul – Oct 2026): 6 wks; Sample / window: early result, small sample; Source: project tool, Confluence
Support · Ticket resolution time — Definition: open to closed, mean; Baseline: 5 days; After (Jul – Oct 2026): 1.5 days; Sample / window: n ≈ 2,000 tickets, Jul – Oct 2026; Source: HubSpot
Support · First response within SLA — Definition: within SLA ÷ total; Baseline: 86%; After (Jul – Oct 2026): 98%; Sample / window: same tickets; Source: HubSpot
Support · Tickets open beyond resolution SLA — Definition: month-end average; Baseline: 140; After (Jul – Oct 2026): 15; Sample / window: monthly, Jul – Oct 2026; Source: HubSpot
Support · Customer wait for next reply — Definition: median, business hours; Baseline: 26 h; After (Jul – Oct 2026): 6 h; Sample / window: same tickets; Source: HubSpot
Support · Repeat tickets — Definition: tickets sharing a root cause (ITIL problem management); Baseline: 22%; After (Jul – Oct 2026): 8%; Sample / window: same tickets; root causes fixed by engineering; Source: HubSpot, issue tracker
Support · Change failure rate — Definition: releases needing hotfix or rollback (DevOps research: high performers < 15%); Baseline: 18%; After (Jul – Oct 2026): 7%; Sample / window: n = 16 releases; Source: build pipeline
Customers & sales · Renewal risks caught ≥ 60 days ahead — Definition: flagged early ÷ all renewals at risk; Baseline: no system; After (Jul – Oct 2026): 85%; Sample / window: 11 of 13 at-risk renewals (small sample); Source: Atlas, HubSpot
Customers & sales · Alert to first customer-success action — Definition: days from first risk signal to first contact; Baseline: 38 days; After (Jul – Oct 2026): 4 days; Sample / window: same accounts; baseline reconstructed from 2025 renewals; Source: HubSpot
Customers & sales · At-risk accounts saved — Definition: flagged at-risk accounts that renewed; Baseline: 45% (5 of 11); After (Jul – Oct 2026): 73% (8 of 11); Sample / window: one renewal cycle; 3 extra renewals = €240k ARR; Source: HubSpot, finance
Customers & sales · Time in security review — Definition: median days a deal spends in the security-review stage; Baseline: 24 days; After (Jul – Oct 2026): 6 days; Sample / window: n = 19 deals; Source: HubSpot
Customers & sales · Open deals stalled or without a next step — Definition: share of open deals, month-end; Baseline: 34%; After (Jul – Oct 2026): 7%; Sample / window: all open deals; Source: HubSpot
People & workload · team level only · HR request first response — Definition: median; Baseline: 3.2 days; After (Jul – Oct 2026): 0.6 days; Sample / window: n ≈ 360 requests, Jul – Oct 2026; Source: Zoho People
People & workload · team level only · HR request resolution — Definition: median; Baseline: 9 days; After (Jul – Oct 2026): 2.5 days; Sample / window: same requests; Source: Zoho People
People & workload · team level only · HR requests within SLA — Definition: resolved within SLA ÷ total; Baseline: 58%; After (Jul – Oct 2026): 93%; Sample / window: same requests; Source: Zoho People
People & workload · team level only · HR request escalations — Definition: per month; Baseline: 21; After (Jul – Oct 2026): 4; Sample / window: same requests; Source: Zoho People
People & workload · team level only · Most loaded team: overtime — Definition: hours per person a month; Baseline: 22 h; After (Jul – Oct 2026): 7 h; Sample / window: after 2 people moved from other teams; headcount unchanged; Source: Zoho People
People & workload · team level only · Most loaded team: open work — Definition: open items per person; Baseline: 31; After (Jul – Oct 2026): 12; Sample / window: same team; Source: Zoho People, project tool
Security & compliance · Security-audit evidence — Definition: per customer questionnaire or audit; Baseline: 3 wks; After (Jul – Oct 2026): 1 day; Sample / window: n = 21 audits; Source: Atlas audit pack
Security & compliance · ISO 27001 controls with live evidence — Definition: evidenced ÷ total (ISO/IEC 27001 Annex A); Baseline: 55%; After (Jul – Oct 2026): 98%; Sample / window: all Annex A controls; Source: identity & access logs, Confluence
Security & compliance · Document-comparison accuracy — Definition: on a fixed evaluation set (EU AI Act); Baseline: not measured; After (Jul – Oct 2026): monitored, drift alerts; Sample / window: monthly; Source: model monitoring
Early readings at day 90 (leading indicators only): first response within SLA 94%, ticket resolution 2.5 days, audit evidence 3 days.
1912 Financial calculation
One horizon: annualised at the performance measured July – October 2026. Cash and capacity reported separately.
At-risk revenue saved — Type: Cash; Calculation: of 11 flagged at-risk accounts, 8 renewed vs 5 at the 2025 rate: 3 extra renewals, €240k ARR; € / year: 240,000
Change orders now invoiced — Type: Cash; Calculation: scope changes recorded and billed instead of absorbed; these hours are deducted from “project overrun avoided” below; € / year: €125k (Jul – Oct 2026), not added
Project overrun avoided — Type: Capacity; Calculation: 30 × 1,200 h × (25% − 8%) = 6,120 h × €110 cost, against the original contracted estimate; less any hours billed as change orders; € / year: 673,200
Support effort — Type: Capacity; Calculation: 6,000 × 3.5 h × 20% = 4,200 h × €90 cost; € / year: 378,000
Audit evidence — Type: Capacity; Calculation: 25 × 120 h × 80% = 2,400 h × €110 cost (80% used, below the ~93% measured time reduction, to stay conservative); € / year: 264,000
Capacity total — 12,720 h ≈ 7.7 FTE at 1,650 h; € / year: 1,315,200
Payback against the fee, from contract start mid-April 2026 (benefits ramp from month 3, July 2026, to full in month 7, November 2026):
Cash only: saved revenue at 80% margin (€192k / year) — month 13 (April 2027)
Cash + half the freed capacity (€850k / year) — month 6 (October 2026)
Cash + all freed capacity (€1,507k / year) — month 5 (September 2026)
Three-year view, cash + half the freed capacity (€k) — Value (year 1 from the ramp): Year 1: 567; Year 2: 850; Year 3: 850; Total: 2,267
Annual values assume the performance measured July – October 2026 holds over a full year.
Gross margin of 80% on saved recurring revenue is the client’s own figure. Invoiced change orders (€125k, July – October 2026) are reported separately and not added, to avoid double counting. Not counted: faster sales cycles, product quality, risk reduction.
2013 Conclusion
Counting retained revenue and half the freed capacity, the due diligence returns about €850k a year and paid back in month 6 (October 2026); over three years about €2.27M, 17.5 times the fee. On cash alone it pays back in month 13 (April 2027) and returns 4 times.
21Timeline and governance
Apr 2026 · weeks 0–2 · Connect — Work done: 11 sources, data contracts, recording consent, end-customer consent for configuration logs; Signed off when: every source has an owner and a contract
Apr – May 2026 · weeks 2–5 · Map — Work done: process map, data map, decisions found outside systems; Signed off when: maps approved by COO and CTO
May – Jun 2026 · weeks 5–9 · Check — Work done: three checks, evidenced findings, compliance matrix; template library approved in week 7; Signed off when: findings with counts and owners
Jun – Jul 2026 · weeks 9–12 · Forecast and hand-over — Work done: organization model, project and customer risk forecasts, backtest, hand-over package; Signed off when: backtest and hand-over approved
Jul – Oct 2026 · Run by the client — Work done: template library, scope-change step, change-order invoicing and monthly forecast run by the client’s own teams; no AIx2 involvement; Signed off when: results re-measured at month 12
Sponsor: CEO — scope and priorities
Business owner: COO — delivery, capacity, monthly steering
Technical owner: CTO — system access, releases, AI features
ISMS lead and DPO — data contracts, consent, regulatory checks
AIx2 — connections, modelling, checks, reporting
2214 What made it work
Started with internal projects and volunteer customers, so end-customer consent was never a blocker.
Per-series recording consent and transcript-only retention earned the team’s trust.
Every forecast shipped with its confidence and drivers. Models learned from new outcomes, and each update was reviewed and approved in Atlas before going live.
Role mapping joined the systems of teams in different countries into one model.
Everything ran on the client’s own servers; no customer data left them.
23How each result happened: the story behind every number
What we did at this client, result by result: what we saw when their systems were joined, what we compared it with, what we proposed, what their managers decided, and how we checked the outcome. Under each number is the Atlas capability that did the work. Atlas found, measured and proposed; the client’s people decided and made the changes.
What combining the data adds: An alert tells someone a number crossed a line. Most results below came from what Atlas sees only because it joins the client’s systems: where time is spent waiting, which team every workflow depends on, where two records of the same thing disagree, and how the as-built company compares with its own target and with established practice.
Work and wait time — Each case rebuilt as a timeline across systems; cycle time split into working and waiting, stage by stage.
Ownership and handoffs — Every department linked to the workflows it owns or joins; missing owners and congested handoffs become visible.
Cross-system reconciliation — Records that should agree are compared (hours vs scope, changes vs invoices, controls vs evidence); each gap becomes a finding with an owner.
Target state and redesign — As-built compared with the documented method and with practice (ITIL, tiered HR service); Atlas drafts a blueprint with an owner and a pilot.
Capacity vs forecast demand — Load per person across teams, demand projected from the sales pipeline; shortfalls show before backlogs.
Decisions, then verification — Findings reach managers as decisions with expected impact; the choice is recorded and the outcome measured against it.
The loop every result followed: Understand → Identify → Trace data & dependencies → Compare with target → Recommend redesign → Execute → Verify. Atlas proposes at each step; named client owners decide.
From bottleneck to decision: capacity or culture? Atlas does not tell a client why work piles up. It shows where. Before recommending anything, we test two explanations in order.
Signal: Requests pool at one team and wait longer than anywhere else.
1 · Capacity test: Work per person, overtime and backlog above comparable teams, queue growing with demand → add capacity (hire or move people).
2 · If capacity is enough: Requests wait even when the queue is short → a working norm. Confirm through interviews, then fix with management: standards, recognition, leadership.
This engagement had one of each: the integration team (capacity) and HR (culture).
Knowledge that lives in heads: an incentive problem. Tools do not make people document. Where knowledge brings status, sharing it costs the person who shares. So the fix was managerial as much as technical:
Part of each consultant’s objectives tied to the quality and completeness of the documentation they leave on every project and to contributions to the template library, reviewed by peers.
A second owner for every topic only one person knew.
Atlas measures the result monthly: single-person topics, template use, recurring tickets without an article.
People data is shown by team, never scored by individual; changes to objectives were agreed with the works council.
24How each result happened: Projects & delivery
Time to go-live (12 → 6 weeks). Work / wait split · conformance to the documented method · blueprint and pilot.
We started by rebuilding every 2025 implementation as one timeline, stitched together from the project tool, the timesheets and the workshop transcripts, and laid it over the delivery method the company had documented. The first surprise was that there was no single method in practice. The same documented process ran in four different ways, depending on who led the project.
Splitting each stage into time someone worked on it and time it waited told us where the twelve weeks went. Design took the most elapsed time, and about half of it was waiting for the customer to sign off. User testing often began before design was approved, so it had to start again. The consultants were not slow; the projects were waiting.
We drafted a redesigned implementation workflow with the delivery lead: start from one of 12 configuration templates, run ERP integration and legacy migration alongside design rather than after it, and add a sign-off gate before user testing. The client piloted it on four projects. We compared their timelines with the rest in Atlas, and only then did it become the standard. Atlas still tracks how closely projects follow it, so any drift back to the old variants shows within weeks.
Projects within budget (60% → 86%). Overrun forecast with drivers · decision queue · outcomes tracked.
Looking back at 2025, every project that overran had shown it weeks earlier: scope added in workshops, hours running ahead of plan, milestones slipping. Each signal lived in a different system, so nobody saw them together. We built a forecast that combines them, and before anyone relied on it we backtested it: it caught 5 of 6 overruns four to six weeks early.
What made the difference was how the forecast reached people. A flagged project did not arrive as an alarm; it arrived at the weekly delivery review as a decision, with its main drivers, the options (re-plan with the customer, add a senior consultant, raise a change order) and the expected effect of each on hours and margin, estimated from how similar projects had responded. The project lead chose and recorded the decision in Atlas. Over the first months, that record began to show which response worked for which cause, and the client wrote it up as a short delivery playbook.
Hours over estimate (25% → 8% average). Reconciliation: timesheets × workshop decisions × statement of work.
We put three records side by side that had never been compared: hours booked in timesheets, scope agreed in workshops, and the statement of work. Most of the overrun was time spent on scope that appeared in neither the contract nor any change request.
That turned one number into two. Part was estimating error; part was unpaid extra work. The unpaid work was stopped or billed (the next two stories). The estimating error went back into the estimating sheet by project type, using actual hours from comparable projects. The 8% that remains is mostly estimating error, and it is falling as the estimates draw on real history.
Unrecorded scope changes (30% → under 5%). Decisions extracted from transcripts · traced to hours and invoices.
Reading the workshop transcripts against each statement of work, we found that 30% of scope decisions existed only in a meeting or an e-mail. Consultants said yes to small additions to keep the customer happy, and recording them meant a form nobody used. We traced each one forward: who agreed it, which hours were booked to it later, and whether it was ever billed.
That trace became the fix. When Atlas now detects a scope decision in a transcript, it drafts a change request already linked to the moment in the workshop, the SOW clause and an hours estimate based on similar changes. The project lead approves or rejects it within 48 hours. The client added a rule that no work starts on unrecorded scope, and Atlas checks it by flagging hours booked to tasks with no approved scope.
Change orders raised as deals (7 · €55k → 16 · €125k). Reconciliation: approved changes × CRM deals × finance invoices.
Once every scope change was linked to hours, we could put a value on the work given away in 2025, and the number made sales and delivery sit down together for the first time. There had been no shared way to price extra work.
Approved changes now become change-order deals in HubSpot, priced by sales from the linked hours estimate. Each month the client’s finance team reconciles approved changes, deals and invoices with the Atlas report and lists anything that was worked but never invoiced. Hours billed this way are taken out of the capacity figure in §12 so they are not counted twice (€125k invoiced July – October 2026).
25How each result happened: Knowledge
We learned early that knowledge stayed in people’s heads for a reason. Knowing what nobody else knows brings status and some job security; writing it down brings extra work and no credit. No tool changes that on its own. Atlas made the problem measurable, and management changed the incentive: part of each consultant’s objectives was tied to the quality of the documentation they leave on every project and to their contributions to the template library, reviewed quarterly by peers, agreed with the works council.
New projects started from an approved template (0% → 86%, 6 of 7). Pattern mining across configuration logs · ownership on the organization map.
When we compared the configuration logs of all 2025 projects, near-identical designs kept appearing. Twelve patterns covered most of what customers had asked for, and each had been rebuilt from scratch several times. There was no library because nobody owned one and nothing rewarded writing it.
Each pattern, together with the projects where it had worked best, became a template with a named owner. Template use is checked at kick-off, and Atlas compares each new project’s configuration with its template, so a deviation shows up as a possible improvement to the template rather than one more rebuild. 6 of 7 new projects started from a template.
Configuration topics held by one person (64% → 18%). Knowledge dependency graph · pipeline exposure · what-if on a departure.
We built a graph of who had documented, configured or answered questions on each of 140 configuration topics, using transcripts, configuration logs, chat metadata and Confluence authorship. For most topics there was one source, and for many of them the source was one of two senior consultants.
The graph alone was a worry; joined with the HubSpot pipeline it became a risk with a size. We could see which upcoming projects depended on those two people, and a what-if view estimated the delay if either left. Key-person risk turned into a list ranked by exposure. Each high-exposure topic got a second owner and a documentation deadline, the new objective made that work count, and the map is reviewed every month.
Recurring ticket types with an approved article (21% → 83%). Ticket clustering · resolution mining · gaps ranked by cost.
We grouped tickets by cause into 48 recurring types, and for each type found the replies that had closed tickets fastest without a reopen. Few types had an article. The answer usually sat in one agent’s sent mail.
An agent now drafts an article from those best replies and the support lead edits and approves it. We ranked the missing articles by ticket volume times handling time, so the most expensive gaps were written first. Each ticket links to the article that solved it, which also tells the team which articles actually work.
New consultant time to autonomy (4 months → 6 weeks). New hires’ questions analysed by topic.
The chat metadata showed new consultants sending long chains of questions to the same two seniors in their first months. When we grouped those questions by topic, most were about configurations that had since become templates or articles.
Onboarding was rebuilt around what new hires actually ask, in the order they meet it on a first project, with protected mentor time for the rest. The sample is small, so we report it as an early result.
26How each result happened: Support
Ticket resolution time (5 → 1.5 days). Work / wait split · handoff graph · redesign against ITIL practice.
We traced each ticket across HubSpot Service, the issue tracker and the release history, and split its life into working and waiting. Most of the five days was waiting. The handoff graph showed where: tickets moved between support and engineering three times on average with no single owner, and duplicates were worked in parallel by different people.
Against ITIL incident and problem practice we drafted a different flow: one owner per ticket, a single handoff to engineering with a required reproduction template, automatic merging of duplicates, and a link from ticket to issue to release. Agent-drafted replies helped, but the larger gain came from taking out the waits and the handoffs.
First response within SLA (86% → 98%). Demand by hour × the support rota.
We laid ticket arrivals by hour and weekday over the support rota. Breaches clustered wherever demand outran cover: Monday mornings and the hours when only one of the two support locations was staffed. The rota was rebuilt against forecast demand, with no extra headcount, and the team lead is alerted an hour before a breach for whatever the rota still misses.
Tickets open beyond resolution SLA (140 → 15). Backlog by age and by reason for being stuck.
Sorting the backlog by age and by why each ticket was stuck changed the conversation. The oldest tickets were not hard problems; they were waiting for a customer reply that never came, or for a fix that had shipped but was never confirmed with the customer. Each cause got its own fix: reminders and closure after a set period, and a release-linked check that closes tickets once the customer confirms the fix. A 30-minute weekly review handles the rest.
Customer wait for next reply (26 h → 6 h). Whole-conversation measurement.
When we measured every reply, not just the first, we saw fast first answers followed by long silences. The SLA covered only the first response, and the team had organised its day around it. A next-response target was added, and the support dashboard now shows the whole conversation.
Repeat tickets (22% → 8%). Root-cause clusters linked to code modules, priced in support hours.
We clustered tickets by root cause and linked each cluster to the code modules and releases involved. A handful of causes produced most of the repeats, and for the first time each had a price in support hours. A monthly problem review now sends the most expensive clusters to engineering with counts, hours and modules, so they compete for roadmap time on cost. The fixes were engineering’s work.
Change failure rate (18% → 7%). Releases linked to the hotfixes and tickets that followed.
Linking each release to the hotfixes and tickets that followed showed that failures concentrated in large releases, in modules with thin test coverage, and in releases that had skipped the second review. Each release now gets a risk score from those factors before deployment; high-risk ones need a second review and are split where possible. The engineering team made those changes.
27How each result happened: Customers & sales
Renewal risks caught 60 days ahead (no system → 85%). Usage × tickets × correspondence × contract events.
For the customers lost in 2025 we lined up product usage, tickets, the tone of correspondence and contract events on one timeline. Each signal alone was weak. Together they showed decline months before renewal.
Customer success now gets a weekly renewal-risk forecast that names the drivers behind each flag, so the first conversation starts from the cause. 11 of 13 at-risk renewals were flagged at least 60 days ahead; the sample is small.
Alert to first customer-success action (38 → 4 days). Ownership of every risk signal, with escalation.
Reconstructing 2025 showed a month or more between the first signal and the first contact. The signal belonged to no one. Each flag now creates a HubSpot task for the account owner with the drivers attached and escalates to the head of customer success after three days.
At-risk accounts saved (45% → 73%). Response matched to the driver behind each flag.
Because each flag carried its drivers, the response could fit the cause: a recurring defect went to the problem review with priority, an untrained customer team got training, an unanswered complaint went to a manager. Those responses became a short save playbook.
8 of 11 flagged accounts renewed, against 5 of 11 at the 2025 rate: three extra renewals worth €240k ARR. We report this rather than overall churn, which moved by too few customers to attribute to our work.
Time in security review (24 → 6 days). Control-to-evidence map reused by sales.
Deals sat in security review while someone assembled answers by hand. The control-to-evidence map we had built for the ISO audit already held current evidence for each control, so we gave sales that, plus a library of approved answers. Atlas tracks which questions customers ask most, so those answers are kept current first.
Open deals stalled or without a next step (34% → 7%). Pipeline hygiene · forecast against actual.
A third of the open pipeline had no next step or a close date already in the past, and that inflated the forecast. Deal owners get a weekly reminder, the pipeline review covers only deals with a next step, and each quarter Atlas compares the forecast with what actually closed, so leadership can see whether the forecast is becoming one it can trust.
28How each result happened: People & workload
The organization map showed requests piling up at two teams. We ran the same capacity test on both, using requests per person from Zoho People, overtime, response times from mail metadata and demand projected from the pipeline. The signal was the same; the causes were opposite, and so were the responses. People data here is shown by team; no individual was scored.
HR request first response (3.2 → 0.6 days). Organization map · capacity test across departments · comparison with tiered HR service.
On the organization map, HR was the department most other workflows waited on. Our first assumption was that HR was understaffed, so we tested it: requests per person, overtime and backlog were in line with comparable teams, and requests waited even when the queue was short. Staffing did not explain it.
The interviews did. Being the team everyone had to chase was quietly seen as a sign of importance, and a quick answer earned no recognition. We also compared the HR request flow with the common tiered model, self-service answers, a generalist first line, specialists for complex cases, and found every request, however simple, going to a specialist. The response was part management and part design: HR leadership set and published service standards, simple requests were routed to self-service or a generalist, the team got a dashboard of its own results, and responsiveness became part of how the team is recognised.
HR request resolution (9 → 2.5 days). HR requests grouped by topic.
Grouping requests by topic showed a few policy questions making up a large share. Their answers were published in Confluence and linked from the request form, so many were answered before a request was ever opened, and the specialists’ time went to cases that needed them.
HR requests within SLA (58% → 93%). Service levels by request type, reported next to other departments.
There had been no agreed service level, so no request was ever formally late. Service levels by request type, with escalation steps and reminders, were set up in Zoho People, and Atlas reports them next to the other departments’ service levels.
HR request escalations (21 → 4 a month). Follows from the changes above.
People had escalated to managers when they could not get an answer. Faster first responses and published service levels took away most of the reason.
Most loaded team: overtime (22 → 7 h per person a month). Capacity against pipeline demand · donor teams checked.
The second pile-up was at the integration team, which every implementation needs. Here the capacity test failed: open work per person was more than twice that of comparable teams and overtime was sustained. Projecting demand from the pipeline showed that every project closing next quarter would add integration work, so the queue would only grow.
The same capacity view showed which teams had slack in that period, so the recommendation could be specific: move two people from named teams whose own forecast load allowed it, and train them on the integration templates. Headcount did not change. A month later we checked the donor teams’ load again to make sure we had not simply moved the problem.
Most loaded team: open work (31 → 12 items per person). 12-week capacity forecast, reviewed monthly.
Open work per person fell as the two new members took on projects and integration templates entered the library. The 12-week capacity forecast is now reviewed monthly, so the next shortfall shows up before the queue does.
29How each result happened: Security & compliance
Security-audit evidence (3 weeks → 1 day). Control-to-evidence map · continuous assurance.
Before each audit, evidence was collected by hand for three weeks. We mapped each ISO 27001 control to where its evidence lives, access logs, policies, tickets, change records, and Atlas checks continuously that the evidence is current. The audit pack is generated from that map.
ISO 27001 controls with live evidence (55% → 98%). Findings with owners and verdicts · scheduled recurring checks.
The same map showed which controls had missing or expired evidence; periodic access reviews were the most common gap. Each gap became a finding with an owner and a due date, accepted or rejected in Atlas with an audit trail, and the recurring checks were scheduled so the evidence would not lapse again.
Document-comparison accuracy (not measured → monitored). Continuous quality control of the AI feature.
The product’s AI document-comparison feature had no fixed test set, so nobody could say whether it was getting better or worse. With the client’s AI team we built an evaluation set. Atlas runs it monthly, raises an alert on drift, and requires a named owner to approve each model update, with the result logged.