Domain, business and market analysis

The short version

A value chain is the sequence of activities a company performs to deliver something a customer pays for. Michael Porter described it in 1985 as primary activities (bring in materials, make the product, ship it, sell it, service it) supported by activities such as procurement, technology, HR and company infrastructure.

A system of record is the one system the company treats as the official source of truth for a type of data. If the CRM says a customer's credit limit is one number and a spreadsheet says another, the system of record wins. For an FDE this matters because any automation that writes data must write to the system of record, or it creates a second truth that someone will have to reconcile by hand.

How a company makes money

Start with the simplest question: what does the customer pay for, and how often? A manufacturer sells units. A software company sells subscriptions. A logistics firm sells moves. A bank earns interest and fees. Then ask what the company must spend to deliver that: materials, people, equipment, rent, software.

Margin is what is left from revenue after the direct cost of delivering. Work that does not move revenue or margin is overhead. Overhead is not bad, since finance, HR and compliance keep the company legal and running, but it is where much manual, repetitive work hides, and so where many AI proofs of concept land.

Where the common systems sit

Most mid to large companies run some version of these systems. Learn what each one is the record for.

• ERP (enterprise resource planning, for example SAP or Oracle): orders, inventory, purchasing, invoices, payments, the general ledger. The financial heart of the company.
• CRM (customer relationship management, for example Salesforce): leads, accounts, contacts, opportunities, quotes. The record of who the customers are and what is in the sales pipeline.
• PLM (product lifecycle management): product designs, bills of materials, engineering changes and specifications.
• QMS (quality management system): deviations, complaints, corrective and preventive actions (CAPA), audits and controlled documents. Critical in regulated industries such as pharma and medical devices.
• HRIS (human resources information system, for example Workday): employees, roles, pay, leave and org structure.
• Ticketing or ITSM (IT service management, for example Jira Service Management or ServiceNow): requests, incidents and support cases, with who handled them and when.
• Around these sit email, shared drives, spreadsheets and chat. They are not systems of record, but a lot of real work happens there.

Where cost and delay hide

Cost and delay collect at handoffs: the moment work moves from one team or one system to another. A sales order created in the CRM has to be re-keyed into the ERP. A supplier invoice arrives as a PDF in a shared mailbox and someone types it in. A quality complaint lands in the ticketing tool and has to be copied into the QMS.

Look for four signs: re-keying of the same data into two systems, work waiting in a queue or inbox, rework when something was entered wrong, and exceptions that fall outside the standard flow and go to a person. Exceptions are often a small share of volume but a large share of effort, which makes them good candidates for an AI assistant that reads documents and drafts a decision for a human to approve.

How to learn a new industry fast

Read the client's annual report or investor presentation if it is public. The sections on revenue, segments and risks tell you what leadership cares about. Read three or four job postings from the client: they often name the systems (for example 'experience with SAP S/4HANA and Coupa'). Ask for an org chart and a systems landscape diagram in the first week. Then draw the value chain yourself and ask a domain person to correct it. Being corrected early is cheap; being wrong in week six is not.

Questions to ask in week one

These questions help you place the problem on the chain and find the right owners. Ask them of the sponsor, a process owner and someone in IT, and compare the answers.

• Which step in this process touches revenue, cost or customer experience most directly?
• Which system does finance or audit treat as the official record for this data?
• Where is the same data typed into more than one place?
• Where does work wait, and for whom?
• What happens to the cases that do not fit the standard flow, and who handles them?
• Which reports does leadership look at for this area, and where do the numbers come from?

The short version

Both canvases come from Alexander Osterwalder and the company Strategyzer, which publishes free templates. The Business Model Canvas (BMC) has nine blocks that describe how an organisation creates, delivers and captures value. The Value Proposition Canvas (VPC) has two halves: a customer profile and a value map. A good fit means the value map answers what the customer profile says matters.

You do not need to be a strategist to use them. Treat them as structured note-taking: each box is a question you ask and a place to write the answer.

The nine blocks of the Business Model Canvas

Fill the right side (customers) first, then the left side (how the company delivers), then the bottom (money).

• Customer segments: the groups of people or companies the business serves. Be specific: 'mid-size factories in the region' beats 'manufacturers'.
• Value propositions: what each segment gets that makes them choose this company, such as price, speed, reliability or expertise.
• Channels: how the company reaches and delivers to customers, such as sales reps, a web shop, or partners.
• Customer relationships: the kind of relationship each segment expects, such as self-service, a dedicated account manager, or a community.
• Revenue streams: how money comes in: one-off sales, subscriptions, fees, licences.
• Key resources: the assets the model depends on: people, warehouses, data, brand, patents.
• Key activities: the things the company must do well, such as purchasing, logistics or engineering.
• Key partnerships: suppliers and partners the model relies on.
• Cost structure: the main costs and which ones grow with volume.

The nine blocks filled for the distributor (fictional)

Here is the Business Model Canvas for the fictional parts distributor used across this module, one line per block, so you can see what a useful level of detail looks like.

• Customer segments: mid-size factories within a day's drive that need spare parts quickly to avoid downtime.
• Value propositions: next-day delivery on common parts, one supplier for many brands, and technical advice from experienced counter staff.
• Channels: field sales reps, a phone counter and a basic web shop for repeat orders.
• Customer relationships: a named account manager for large customers, self-service for small ones.
• Revenue streams: margin on parts sold, plus a fee for same-day or emergency delivery.
• Key resources: two warehouses, a stocked inventory, supplier agreements and staff product knowledge.
• Key activities: purchasing, stock control, picking and delivery, and paying suppliers accurately.
• Key partnerships: about 400 suppliers and a regional courier.
• Cost structure: inventory, warehouse rent, delivery vehicles and staff. Finance staff time grows with supplier and invoice volume.

The Value Proposition Canvas

The customer profile has three parts. Jobs are what the person is trying to get done, including functional jobs (pay suppliers on time) and social or emotional ones (not look careless to the CFO). Pains are what makes the job hard, risky or slow. Gains are outcomes they want or would be pleased by.

The value map mirrors it. Products and services are what you offer. Pain relievers say how the offer removes specific pains. Gain creators say how it produces specific gains. Fit is when your pain relievers and gain creators line up with the pains and gains that matter most to the person, not the ones you find interesting.

How an FDE uses them

Use the BMC for the client company as a whole, so you understand which segment, activity or cost your work touches. Use the VPC for the specific user group of your proof of concept, such as AP clerks or field technicians. Draft both from your discovery notes, then review them with the sponsor and with two or three users. Every pain you write should be traceable to something someone said or something you saw.

Rank pains by how often they happen and how much they hurt. Your first build should target the top one or two, and your business case should be able to put a number on them.

Running a canvas session with the client

Print the canvas large or share it on a whiteboard tool. Bring your draft, but present every box as a question: 'Is this right? What is missing?' Let the client correct you out loud, since corrections are the most valuable output of the session. Keep it to 45 minutes, photograph or save the result, and send a clean copy the same day with the open questions listed underneath.

The short version

A market scan is a short, structured look at every realistic way the client could solve the problem, including not solving it. It is not a market sizing exercise and it is not a sales pitch. Its job is to help the client make an informed choice, and to help you position your work honestly.

Done well, it takes a few hours, fits on one page, and is revisited when new options appear.

Who else solves the problem

List options in five groups. Most clients only think of the first.

• Dedicated products: vendors who sell a tool for exactly this job, such as invoice capture or contract review software.
• Features in systems they already own: ERP, CRM and ticketing vendors keep adding automation and AI features. Check the client's current licences and roadmaps first.
• People-based options: hire more staff, use a contractor, or outsource to a business process outsourcing (BPO) provider.
• General tools: spreadsheets, low-code workflow tools, or a general AI assistant used by staff directly.
• Do nothing: live with the problem. Always include it, because it is the real baseline your option must beat.

How a client compares options

Buyers rarely compare on features alone. They ask: does it fit how we work and our data? What will it cost in total over three years, including licences, integration, support and staff time (total cost of ownership, or TCO)? How long until it delivers value? What is the risk: security, data leaving the company, regulatory approval, vendor going away? Who else like us uses it, and can we speak to them? Can our IT team support it?

Learn the client's procurement rules early. Some companies require three quotes, a security questionnaire, or an approved vendor list. These rules can decide the outcome more than any feature comparison.

Reading vendor claims carefully

Vendor pages describe the best case. Separate what you can check from what is claimed. A public documentation page, a pricing page or a free trial you ran yourself counts as evidence. A case study on the vendor's own site is a claim. Accuracy figures without a test set you can see are claims. When you write the scan, put claims in a separate column, or mark them 'vendor says', so the client knows how much weight to give them.

Also check fit to the client's environment: does the product run in the client's cloud or region, does it connect to their version of the ERP, and does it pass their security questionnaire? A good product that fails the security review is not a real option this year.

How to run the scan

Write the problem in one sentence in the user's words. Search for products using the words a buyer would use, not technical terms. Read vendor sites, documentation and public pricing where it exists, and note what you could not verify. Ask the client's IT and procurement teams what they already own or have evaluated before, because many problems were looked at once and dropped for a reason worth knowing. Finally, ask two users how they would solve it if you were not there.

Score each option against the client's criteria, not yours. Keep scores rough (1 to 5) and write one line of evidence for each, so anyone can challenge them.

Problem: AP clerks spend too long resolving invoice exceptions

Option        | Fit | 3yr cost | Time to value | Risk | Evidence
--------------|-----|----------|---------------|------|---------------------------
Do nothing    |  1  |  low     | n/a           |  2   | backlog grows at month end
ERP add-on    |  3  |  medium  | 3 months      |  2   | demo seen; no email reading
Capture tool  |  3  |  medium  | 2 months      |  3   | handles PDFs, not reasons
BPO provider  |  2  |  high    | 4 months      |  3   | moves work, not insight
Custom LLM PoC|  4  |  medium  | 6 weeks       |  3   | needs IT support plan

Presenting the scan

Lead with the problem and the baseline, then the table, then a short recommendation with what would change it. Keep it to one page. If you recommend your own proof of concept, say plainly which part no other option covers, and what you will test to prove it. Clients trust an FDE who recommends a product when it fits better, and that trust pays back on the next decision.

The short version

Most operational business cases start with one line: volume times time saved per case times loaded cost per hour. Volume is how many cases happen per month. Time saved is the difference between how long a case takes now and how long it would take with the solution. Loaded cost is what an hour of staff time really costs the company: salary plus benefits, taxes, office and equipment, usually agreed with finance.

Then you add effects that are not time: fewer errors, lower risk, faster cycle time. You subtract what the solution costs to build and run. Payback is how many months until the cumulative benefit covers the upfront cost.

Getting inputs you can defend

Take volume from system data where possible: the ERP or ticketing tool can usually tell you how many cases happened last month. Take current time from timing real cases during shadowing, not from a guess in a meeting. Take time with the solution from your proof of concept results, and until you have them, use a cautious estimate and say so. Take loaded cost from finance, never from your own assumption.

Write each input with its source next to it. When a number is challenged, you can point to where it came from, and the conversation becomes about the input rather than your credibility.

Watch for seasonality. Many processes peak at month end, quarter end or in a busy season, so one month of volume can mislead. Pull twelve months if you can and use the average, and note the peak separately because peaks are often where the pain is felt most.

Quality and risk effects

Some value is not about hours. Fewer errors mean less rework and fewer customer complaints. In finance, catching a duplicate invoice before payment avoids paying twice. Paying on time can avoid late fees or capture early payment discounts. In regulated work, a consistent check can lower the risk of a failed audit.

Put a number on these only when you have a basis, such as last year's duplicate payments recovered, or late fees in the ledger. Otherwise list them as unquantified benefits. A short list of honest unquantified benefits is more persuasive than an inflated total.

Capacity hours versus cash savings

This is the distinction finance will test you on. Saving 200 hours a month across a team of ten does not save cash unless something changes: a vacancy is not filled, a contractor is released, overtime stops, or growth is absorbed without hiring. Otherwise the hours become freed capacity that people spend on other work.

Freed capacity is real value, but say clearly which it is. Ask the sponsor what they would do with the hours. If the answer is 'clear the backlog' or 'handle next year's growth without hiring', write that down as the benefit. Never imply headcount cuts the sponsor has not discussed; it damages trust with the users you need for adoption.

Ramp-up, run costs and ranges

Benefits do not start at full strength. Users adopt gradually, so assume a ramp, such as half the benefit in the first three months. Include run costs: LLM API usage, hosting, monitoring, and the staff time to maintain prompts and handle issues. Present a low, base and high case, and show which input moves the answer most. That input is what your proof of concept should measure first.

A simple way to find the key input is to change one input at a time by a fair amount, for example minutes saved from 7 to 4, and see how far the payback month moves. If payback barely moves when you halve run cost but jumps when you halve minutes saved, then minutes saved is what the sponsor is really betting on. Say that out loud in the meeting, and make timing real cases with the proof of concept the first thing you measure.

Presenting the case

Put the result on one page: the problem, the inputs with sources, the formula, the low, base and high results, payback, unquantified benefits and the key assumption to test. Review the inputs with finance before the sponsor sees the result, so the numbers are already agreed when the meeting starts. After the proof of concept, update the case with measured values and show both versions side by side. A case that changes with evidence is far more credible than one that never moves.

The short version

Configure means using settings, rules, workflows or built-in AI features of a system the client already owns, such as routing rules in the ticketing tool or an approval workflow in the ERP. Buy means licensing a product made for the job. Build means writing custom software, which for an FDE often means a thin layer of code around an LLM, connected to the client's systems.

Real solutions are usually a mix: configure what you can, buy the commodity parts, and build only the part that is specific to how this client works.

The decision criteria

Agree the criteria and their weights with the sponsor and IT before you score options. That way the result is their decision, not your preference.

• Fit: how much of the need does each option cover? A product that covers most of it with small process changes often beats a custom build that covers all of it.
• Differentiation: is this how the company wins, or is it standard back-office work? Standard work rarely justifies a build.
• Data and integration: where does the data live, and can each option read it and write back to the system of record?
• Security and compliance: can data leave the company? Does the vendor meet the client's security review? Is the use regulated?
• Time to value: how soon can users get benefit?
• Total cost of ownership: licences, build, run, support and upgrades over about three years.
• Ownership: who will maintain it after you leave? If no one can, a build is a liability.
• Lock-in and exit: how hard is it to switch later?

Order of questions

Ask first whether a system the client already owns can do it well enough with configuration. This is often the cheapest and safest path, because licences, security approval and support are already in place. If not, ask whether a mature product does it. If the need is specific to the client's process, data or rules, and someone can own the result, a build is justified.

When the answer is unclear, run a short, time-boxed test of the top two options on the same real cases and compare results. Evidence ends debates faster than opinions.

Hidden costs of each path

Each option has costs that do not appear on the first quote. Configure looks free, but heavy configuration can make upgrades of the platform slow and risky, and it often needs a specialist administrator. Buy brings licence increases at renewal, integration work, a security review that can take weeks, and the risk that the vendor changes direction. Build needs ongoing maintenance: prompt and model updates when the LLM provider releases new versions, monitoring for quality drift, access management and a person who answers when it breaks.

For an AI build specifically, plan for an evaluation set of real cases that you rerun whenever a prompt or model changes. Without it, nobody can safely change the solution after you leave, and the client is locked into the version you shipped.

Making the recommendation

Write a one-page note: the need, the options considered, the criteria and weights, the scores with one line of evidence each, the recommendation, and what would change your mind. Include the handover plan for any build: who owns it, how it is monitored, and how prompts and code are updated. Present it to the sponsor and IT together.

Expect pushback from two directions. IT may prefer configure or buy because it fits their support model, and business users may prefer build because it promises an exact fit. Both views are reasonable. Go back to the agreed criteria and the evidence, and if the scores are close, choose the option that is easier to reverse. A small build can be replaced by a product later; a three-year licence is harder to undo.

Mixing options in one solution

The best answer is often layered. Configure the platform to collect and route the work, buy a product for a commodity step such as document capture, and build a thin custom layer only for the reasoning step that is specific to the client. This keeps the custom code small, which makes it easier to hand over, test and replace. When you draw the solution, colour or label each part by path so the client sees exactly what they are taking ownership of.