Strategy & artificial intelligence consulting
Decide where to invest in AI. Compare the options, select the right projects and lead their implementation.
Let’s discuss your projectContact the firm. Explore our expertiseAI product & automation
Product vision, prioritisation decisions and coordinated delivery of management tools incorporating AI use cases.
Explore the experienceObserved outcome
An initial release approved by sponsors, with use cases deployed across several teams.
Role performed
Product management and coordination of a team effort.
Professional experience predating Arlan Grey, presented in anonymised form. Photograph for illustrative purposes.
Where to start?
Online · 10 questions
Value, data, feasibility and governance: identify what needs further investigation and get an immediate summary.
Start the self-assessmentNo registration. Your answers stay in your browser. This self-assessment does not replace an audit.
Consulting engagement · Scoped proposal
Have your processes assessed, compare options and build a roadmap with explicit conditions for success.
Explore the diagnostic engagementA defined scope, deliverables and fees agreed before work starts.
AI agents & investment decisions
A worked example to compare fully loaded costs and decide whether to scale up.
Strategy & investment decisions
A three-year model to identify the assumptions that change the decision.
Perspectives
01 / Strategy & AI investment
Demands are multiplying while budgets remain constrained. We help leadership teams build an investment thesis and make choices across projects.
The decision to prepare: which projects to pursue, in what sequence and under what funding, validation and stop conditions.
Buy a solution, build in-house or defer: compare options at the same service level, including human rework and maintenance. Our worked comparison of buying and building AI illustrates the assumptions that can reverse the decision, using an entirely fictional example.
02 / AI product leadership
A validated pilot still leaves decisions open: scope, required quality, integration and operations. We lead this transition with business and technical teams.
The decision at each milestone: continue delivery, address gaps or revise scope, using criteria agreed with sponsors.
Responsibilities for development, operation and maintenance are specified in the engagement proposal.
03 / Operational transformation
Expected value depends on how work is organised. We support process change, team adoption and performance monitoring.
The intended outcome: practices embedded in day-to-day work and performance monitored by operational managers.
Prior professional experience · Anonymised
Product management of business tools incorporating AI and automation use cases.
This experience predates the establishment of Arlan Grey. The account is deliberately limited to the information needed to understand the work undertaken without identifying organisations or individuals.
Prior professional experience · Anonymised
Scoping the selection of hardware and digital services in a demanding environment.
This experience predates the establishment of Arlan Grey. Names, dates and identifying details are omitted to preserve confidentiality.
AI audit · Investment diagnostic
Compare options, assess value and establish investment conditions. A focused diagnostic covering up to three processes to prepare your next decision.
Pursue, investigate, defer or rule out an opportunity. Each recommendation sets out its assumptions, limitations and the evidence that could change it.
The reference scope covers one entity or unit, up to three processes, six interviews and three opportunities. It comprises six consulting days, including one review cycle.
Initial findings are presented around three weeks after kickoff, subject to the availability of stakeholders and agreed information. Consolidated feedback is then incorporated into the final dossier.
Download the engagement outline (PDF, French)
Scoping establishes the intended decision, sponsor, available data and success criteria. Scope, schedule and fees are confirmed in the engagement proposal.
In our entirely hypothetical example, AI frees more capacity than automation rules. Yet that additional benefit does not cover its extra cost under the stated assumptions. This is precisely the kind of decision the dossier should enable.
Examine the reasoning and assumptionsDownload a decision note (PDF, French)
This note uses a different, entirely fictitious case to illustrate the format of our findings. It is neither a client reference nor a promise of results.
Once the decision is made, support can extend to product leadership, delivery coordination and changes to working practices. Evaluation milestones allow choices to be revisited as evidence develops.
AI product leadership · Operational transformation
Implementation is subject to a separate scope and fees. The diagnostic does not include development, deployment, licences, or legal or security audits.
Sample deliverable · Decision memo
A decision memo connects the diagnostic assessment, economic assumptions and implementation requirements. This extract illustrates the approach.
A process handles 600 requests per month, at 8 minutes each: an initial workload of 80 hours. Three options are assessed within the same scope, including human oversight and maintenance.
| Option | Total time | Capacity freed up | Recurring cost |
|---|---|---|---|
| Simplified process | 62 h | 18 h | €50 |
| Rules-based automation | 53 h | 27 h | €150 |
| AI automation | 48.5 h | 31.5 h | €550 |
AI frees up an additional 4.5 hours compared with rules-based automation, for an extra €400 in recurring costs. At an assumed value of €40 per hour, this capacity represents €180 per month.
Recommendation at this stage: investigate the rules-based option further. At this volume, time savings alone do not justify the additional cost of AI.
The diagnostic assessment must also examine service quality, exceptions and the actual ability to redeploy the time freed up. Available capacity does not automatically translate into cash savings.
Volume, expected quality or the nature of requests may change the trade-off. If the incremental saving of 0.45 minutes per request remained constant, 1,800 requests would free up an additional 13.5 hours, valued here at €540.
With the additional monthly cost held at €400, the difference would be €140 before initial investment. This sensitivity analysis is not a return-on-investment calculation: among other things, it assumes that costs, human oversight and quality do not deteriorate as volume increases.
AI may also create value by handling requests that were previously left unaddressed or by improving service levels. These benefits must be defined, measured and then assessed against the total cost.
The findings bring together the recommendation, its limitations and a roadmap with decision milestones.
An entirely hypothetical example, with no client data, constituting neither a quotation nor a promise of results. The assumptions illustrate the approach and must be developed afresh for each engagement.
Perspective · AI & operational performance
A demonstration shows that a task can be automated. It does not yet establish the cost of running a reliable service day to day.
The key point. Measuring production time without accounting for verification and rework overstates the value of automation.
A quickly generated response may require verification, correction or further research. The cost then falls elsewhere in the process or on another team. The relevant unit of measurement is a request handled correctly from end to end.
Assume 100 cases, each taking 8 minutes to process: 800 minutes initially. With AI, production falls to 200 minutes. However, 300 minutes of verification and 200 minutes of rework must be added. The total is 700 minutes.
The saving is therefore 100 minutes before integration and maintenance costs. These assumptions are hypothetical: they show why a saving measured at just one stage can be misleading.
Evaluation should cover representative situations distinct from the examples used to prepare the pilot. It must include incomplete requests, errors and difficult cases, then measure how they are actually handled.
The decision also depends on the required level of quality. Some errors are easy to correct; others require systematic checks. Responsibility for those checks must be explicit.
Who monitors errors? Who takes action when a source changes? Who can suspend the service? These questions shape the operating model and recurring costs as much as the choice of model does.
Before deployment, establish evidence of three things: sufficient quality, an acceptable total cost and clearly assigned operational responsibility.
An educational example, with no client results. The criteria must be adapted to the requirements and risks of each process. References: NIST AI RMF and FinOps Framework .
Perspective · Technology strategy
Vendor dependency is also measured by what must be rebuilt to move away.
The key point. An exit clause is no substitute for understanding the data, configurations and integrations needed to switch solutions.
Documents, data, instructions, relevant histories, access rights and evaluations: these elements differ in format and in how they can be retrieved. It is essential to distinguish what can be exported from what must be rebuilt.
Select a representative use case and examine the stages of a transfer. Check whether the necessary elements can be retrieved, connections rebuilt and the required quality achieved. This test does not establish general portability, but it makes the main obstacles visible.
Migration effort, any period of parallel operation and user training all belong in the comparison. A more open solution may also require greater in-house expertise.
The right decision depends on how critical the use case is, the resources available and how long the organisation is prepared to remain dependent on its supplier.
This briefing proposes an assessment approach. The ability to switch depends on the contracts, architectures and use cases actually adopted.
Perspective · Strategy & investment
A useful investment case compares alternatives, makes assumptions explicit and sets out the conditions for proceeding.
Describe the process, its current difficulties and what an improvement should deliver. This provides a basis for comparing several responses, including simpler ways of working or conventional automation.
An AI solution must be compared with a realistic alternative. If it frees up 31.5 hours per month compared with 27 hours for rules-based automation, the difference to account for is 4.5 hours, together with its costs and quality requirements.
The investment case must support a decision on what to fund, the evidence required at the next stage and the conditions that would lead to a project being revised or stopped.
Volumes, adoption, time spent on checks, recurring costs and initial investment must be visible. A sound decision can then evolve as initial results replace assumptions.
The figures in this briefing are hypothetical. Time freed up does not necessarily translate into cash savings.
Retail · Strategy & AI
We help leadership teams scope their AI priorities, compare scenarios and prepare a roadmap that reflects operational constraints.
Which problem warrants investment? Which decisions sit with the site, the network or central functions? Which data and interfaces are actually accessible? Scoping identifies these dependencies before recommending deployment.
A focused process map, a comparison of options and a prioritised roadmap. Recommendations specify the conditions for creating value, governance arrangements and evaluation criteria for an initial scope.
Possible applications, presented for illustrative purposes. They are not client references. Scope, deliverables and fees are defined in an engagement proposal.
Home care · Organisation & AI
We support leadership teams in examining processes, assessing trade-offs between use cases and preparing for change with their teams.
Scoping takes account of service continuity, confidentiality and available resources. It clarifies what can be automated, what requires human validation and the conditions for adoption by teams.
A focused diagnostic assessment, a comparison of scenarios and a roadmap that balances total cost, adoption and governance. Responsibilities and validation criteria are defined before any implementation.
Possible applications, presented for illustrative purposes. They are not client references. Scope, deliverables and fees are defined in an engagement proposal.
Arlan Grey perspective
An agent can work correctly and still cost more than the AI-assisted workflow it replaces. Before expanding its use, a leadership team must assess exception-handling costs against the required service level.
The right basis for comparison is the fully loaded cost of an accepted outcome, at comparable quality and turnaround times. Human oversight is part of this calculation, as highlighted by McKinsey in its analysis of agent economics.
Consider an entirely hypothetical case: 120 cases per day, of which 20% require an eight-minute human review. That means 24 cases need review. With two hours available, the team can review fifteen. With a constant inflow, no initial backlog and no other constraints, nine additional cases remain pending each day.
Adding 72 minutes per day only keeps pace with the average inflow. Assume an additional capacity buffer of 48 minutes: four hours of human oversight per day in total, including the two hours already available. This hypothetical buffer still needs to be sized for peaks, absences and any backlog.
Over twenty working days, both operating models handle the same 2,400 cases, with accepted outcomes, equivalent quality and equivalent turnaround times assumed. All amounts are hypothetical. The AI-assisted workflow, in which AI prepares the work and a human decides, costs €6,200, including an appropriate capacity buffer. The agent costs €2,000 excluding human oversight; each hour of oversight capacity costs €60.
| Operating model | Fully loaded cost over twenty days |
|---|---|
| AI-assisted workflow | €6,200 |
| Agent, with 80 hours of human oversight | €2,000 + €4,800 = €6,800 |
These fully loaded costs include setup costs allocated over the chosen time horizon, operations and rework. The economic difference does not automatically translate into cash savings.
Under these assumptions, the agent costs €600 more. Scaling it up to reduce costs is not justified.
The maximum human oversight budget at cost parity is €4,200, or 70 hours. Reviews already consume 64 hours, leaving six hours of capacity buffer, or 18 minutes per day. The capacity buffer needed to maintain the service therefore determines the decision.
If the 16-hour capacity buffer is necessary, 54 hours remain for 480 reviews: 6 minutes 45 seconds per review at cost parity. The process must support this review time without compromising oversight.
At six minutes, the cost would fall to €5,840, with costs outside human oversight unchanged. The favourable difference of €360 must cover any additional improvement costs allocated to the same time horizon.
| Option | Decision criterion |
|---|---|
| Retain the AI-assisted workflow | A baseline that costs less than the estimated expansion. |
| Scale up the agent | Demonstrate reliable capacity and a lower fully loaded cost, or a documented additional benefit that covers the difference. |
| Target a narrower scope | Recalculate review frequency and duration, including how excluded cases are handled. |
Our recommendation: retain the AI-assisted workflow under the current assumptions. The scaling test is successful if, with representative case flows, quality and turnaround requirements are met, the backlog is under control and the fully loaded cost stays within the agreed budget. Otherwise, retain the AI-assisted workflow or reconsider the scope.
Research by BCG on process redesign sheds light on this option: redesigning how work is organised can change the economics of the operating model.
Before approving a budget for scaling up, the Diagnostic de décision IA can be scoped around a decision note: required capacity, a comparison of costs, a recommendation and conditions for reassessment. The scope and required data are agreed before the engagement.
Arlan Grey perspective
An in-house solution can look cheaper and lose its advantage as rework increases. The decision rests on the cost of an accepted outcome and the ability to maintain service quality.
Our view: buy when a solution meets the need and its dependencies are acceptable; build when the differentiation also justifies the operating burden; defer when the evidence is not yet sufficient to decide.
In its 2026 survey, McKinsey reports that 32% of respondents say their organisations decided against purchasing at least one software product or feature because of agentic coding tools. This describes a reported decision, not its profitability. It does not establish that building is cheaper.
A vendor quote and a prototype budget do not necessarily cover the same service. Before comparing them, define scope, quality, response times, exception handling and maintenance ownership. Conventional automation or process simplification also deserves consideration.
Buy: use representative cases to verify what the contract includes, what is billed by usage, what can be exported and what remains the organisation’s responsibility. Vendor controls do not replace internal controls.
Build: fund a lasting capability for testing, oversight and maintenance. An in-house product can still depend on external models, infrastructure or suppliers; building does not by itself guarantee control over data.
Defer or forgo: retain an explicit alternative, with its cost and a review date. This is justified when the need remains poorly defined, quality is insufficient or operating resources are unavailable.
Entirely hypothetical example, unrelated to any client engagement. A company compares three ways of processing 60,000 requests a year over three years. The full cost of human processing is assumed to be €1.50 per request, including quality control and oversight. Both AI options resolve 80% of requests to the required standard; humans fully reprocess the remaining 20%. Response times and final quality are assumed comparable and must be demonstrated before committing.
Assumptions: €20,000 setup for the purchased solution, billed at €0.50 per resolved request; €40,000 for in-house development, then €0.10 per attempt and €10,000 annual maintenance. Each AI option also includes €6,000 annual operating oversight and quality checks on 5% of resolved requests, at €0.75 per check. All amounts are modelling assumptions, not market prices.
| Item | Buy | Build | Human processing |
|---|---|---|---|
| Setup, one-off | 20 000 | 40 000 | 0 |
| Annual usage | 24 000 | 6 000 | 0 |
| Annual human handling and rework | 18 000 | 18 000 | 90 000 |
| Annual quality checks | 1 800 | 1 800 | Included |
| Annual maintenance | Included | 10 000 | Included |
| Annual operating oversight | 6 000 | 6 000 | Included |
| Three-year total | 169 400 | 165 400 | 270 000 |
The calculation is reproducible: 48,000 resolved requests, 12,000 human rework cases and 2,400 quality checks per year. Buy: 20,000 + 3 × (24,000 + 18,000 + 1,800 + 6,000) = €169,400. Build: 40,000 + 3 × (6,000 + 18,000 + 1,800 + 10,000 + 6,000) = €165,400.
Building retains a €4,000 advantage over three years. This is not enough to decide without testing the model’s sensitivity. Amounts are undiscounted and exclude tax and financing. Both options are assumed operational at the start of the period, with no ramp-up. Migration, exit, parallel running and additional delay costs must be added when applicable.
The difference from human processing values the resources used. It becomes a cash saving only if expenditure is actually avoided. Freed-up time can create useful capacity without reducing expenses.
Two tests reveal how sensitive the initial ranking is.
First test: an additional €6,000 in development takes the in-house total to €171,400. Buying becomes €2,000 cheaper. Delivery cost cannot be treated as a detail to resolve after the decision.
Second test: if both solutions resolve only 60% of requests, human rework rises to 24,000 cases per year. With other assumptions unchanged, buying costs €204,050 over three years, versus €218,050 for building. Outcome-based billing offers more protection to the buyer here; that advantage would change under a different billing model.
Resolution rates must be measured on representative requests, including difficult cases. Sampling does not guarantee the absence of errors in unchecked responses. When some errors are unacceptable, systematic validation may be necessary and must be costed separately.
Under the central assumptions, we would not recommend committing to a build solely for cost savings. Its €4,000 advantage must be weighed against additional operating responsibility and still-hypothetical performance. Differentiation, integration requirements or demonstrably better control may nevertheless justify building.
The decision paper should specify five things: the expected service, costs over the same horizon, quality evidence, operating ownership and thresholds for continuing, revising or stopping. The investment decision can then be reviewed against evidence.
Arlan Grey supports this assessment through its AI Decision Diagnostic: comparing options, testing assumptions and producing a recommendation with implementation conditions. Scope, deliverables and fees are defined in an engagement proposal.
McKinsey, The state of AI in 2026: On the road to ROI. Published 25 August 2026, accessed 27 September 2026. Self-reported survey of 1,719 participants across 97 countries, conducted from 4 May to 8 June 2026. Its findings are not estimates specifically for French SMEs or mid-sized companies.
The decision framework and simulation are Arlan Grey analysis. Amounts, volumes and performance levels are hypothetical; no client reference or promised result is presented.
AI training & literacy
Tailored corporate AI training for executives and managers. Understand the possibilities, test the limitations and identify uses worth experimenting with.
AI literacy should support better decisions about work. The programme starts with participants’ responsibilities, approved tools and the situations they face. No software development background is required.
Build a shared understanding of generative AI, its uses and its limitations. Demonstrations focus on practical decisions: can this output be used, what information is missing, and who should check it? Participants leave with an initial use-case assessment framework.
A deeper examination of an activity selected with the sponsor. Participants compare the current method with an AI-assisted approach, document errors and rework, and prepare an experiment protocol. Duration and delivery arrangements depend on participants’ experience, group size and objectives.
Entirely fictional teaching example: a team receives a source file and an AI-generated summary. Participants identify an omission, distinguish facts from interpretation and check whether the sources support the conclusion.
The issue is not how polished the writing looks. It is whether the summary should be used, corrected or rejected. The exercise makes verification time and the conditions for delegation explicit.
A comparison at the start and end of the session assesses progress against the same criteria: defining the need, detecting errors and choosing appropriate checks. It does not measure return on investment in production.
Scoping establishes participants’ roles, starting level, working scenarios and permitted tools. Exercises use fictional data or anonymised materials approved beforehand. No confidential document is needed for an initial discussion.
Depending on the agreed format, participants receive an assessment framework, usage guidelines to adapt to their organisation, and an experiment plan with an owner, evaluation criteria and a next milestone. Scope, deliverables, schedule and fees are defined in the engagement proposal.
If the question concerns the economics of a process or implementation, an audit or transformation engagement can extend this work under a separate scope.
Our expertise
Perspectives
