What Is an FDE? Work and Deliverables Companies Can Commission
Tomohiro Iida ·
When an AI or SaaS product is deployed for a customer, someone has to connect its features to everyday work. That involves understanding the workflow, integrating existing systems, evaluating behavior, and handing over operations. When commissioning an FDE for this work, start by agreeing on the deliverable at each stage and the person who will accept it.
This article addresses deployments where an AI or SaaS company commissions the work and its customer uses the result. Official role descriptions and Netsujo’s completed workbook example provide a basis for discussing the work and deliverables to include in an engagement.
What an FDE does in a customer deployment
FDE stands for Forward Deployed Engineer. The role involves technical work close to a customer’s problem, integrating products and AI into business workflows. The exact responsibilities vary by company and engagement.
OpenAI’s Tokyo role description covers discovery, scoping, design, implementation, and production deployment, with attention to adoption and workflow impact. Anthropic’s role description also includes building applications that run in customer environments and turning lessons from deployments into reusable work.
For a commissioned engagement, translate those broad responsibilities into one deployment. Decide what each person passes to the next at stages such as explaining the workflow, building a connection, and checking production behavior. The following is a proposed way to structure that discussion.
Read the deliverables in a public workbook
Netsujo’s AI Agent Operations Workbook — Japanese PDF contains a completed example for preparing a weekly site operations report. It is an explanatory sample. It should be distinguished from evidence of a customer delivery or measured business results.
The Task Contract on pages 7–8 specifies GA4, Search Console, and operational logs as inputs. Its outputs include a report draft, source links, and a list of unresolved items. Permitted changes cover internal drafts and aggregation files in a designated folder. The production website, advertising settings, customer data, and measurement settings are outside the scope. It also defines stop conditions, including expired authentication and conflicting numbers.
Used in a commissioning discussion, this example makes acceptance more concrete. The recipient can check key figures against their sources and decide whether the remaining uncertainties allow a business decision. Alongside what will be built, the parties can agree on the information required to review it.
The Role Matrix on page 10 assigns roles for execution, review, decisions on external sharing, and final acceptance. Applying that approach to customer deployment leads to the deliverables and responsibilities below.
Agree on deliverables at each stage
The table proposes a way to define an FDE engagement. Adjust the amount of documentation to the workflow and the consequences of failure.
On a small screen, scroll the table horizontally to read the acceptance column on the right.
| Stage | Possible deliverables | What to check at acceptance |
|---|---|---|
| Workflow discovery and scope | Workflow map, inclusions and exclusions, baseline measurement method | Whose work will change, and how much of it is in scope? |
| Integration | Connection specifications, data fields, permission inventory, implementation | Can system owners verify the access scope and changes? |
| Evaluation | Test cases, acceptance criteria, results, unresolved issues | Have normal cases and exceptions been tested against the agreed criteria? |
| Production and handover | Deployment procedure, monitoring items, stop and recovery procedures, contacts | Are executors and approvers assigned, with a response for abnormal behavior? |
| Adoption and improvement | User instructions, support records, metric trends, improvement candidates | Does use continue, and how have rework and operating effort changed? |
Netsujo’s Deliverable Samples — Japanese PDF also separates verified facts, explanatory samples, and scope to be agreed for each engagement. Use these public materials to discuss requirements, then agree on the actual deliverables, acceptance conditions, and schedule for the project.
Responsibilities across the vendor, FDE, and customer
The product provider and the customer using it every day control different decisions. Even when an FDE coordinates between them, someone needs to own product priorities and business acceptance.
On a small screen, scroll the table horizontally to read the decisions column on the right.
| Party | Main responsibilities | Decisions to agree on |
|---|---|---|
| AI or SaaS company: business, engineering, and customer success | Product scope, shared feature development, contracts, customer support | Limits of customer-specific work, improvements to bring into the product, support handover |
| FDE | Workflow definition, technical scope, integration, evaluation, deployment coordination | Working permissions, deliverables, reporting and stop conditions, handover completion |
| Customer’s business and system owners | Business rules, data use, environment access, user coordination | Business correctness, production change approval, final acceptance, operational ownership |
This is an example for discussing responsibilities. An internal product team might own shared features while the FDE owns a particular customer integration. Agreeing on which enquiries customer success will receive, and when a customer-specific solution should become a product improvement, gives remaining work a clear destination after deployment.
Define scope and success measures before work starts
In the first discussion, identify the workflow, available data, environments that may be changed, the acceptance decision-maker, and the eventual operations owner. If a PoC already exists, gather its evaluation results, known issues, connections and permissions, and operating instructions alongside the working code. Those materials make the remaining work easier to estimate.
Define technical checks and business changes separately. For example, check test-case pass rate against the acceptance criteria and stopping behavior for exceptions, then measure use among the intended users, task time, returned work, and the effort required for human checks. Agree on baseline values, the measurement period, participants, and who compiles the results. Keep conditions comparable before and after deployment.
If task time falls, the effect on revenue or expenditure still needs further verification. Put both the acceptance milestone and the later business-outcome review into the plan.
An existing engineering, customer success, and customer team can carry the work when responsibilities already cover discovery through operations. For a small, low-risk deployment, the items in this article can fit on one page. Decide whether to add an FDE by identifying the work and ownership gaps that remain.
For decisions about who should implement the system, see how to choose between building, outsourcing, and buying AI agents. The AI implementation guide covers the broader deployment design. Use them to identify the decisions to retain internally and the work to commission externally.
What to bring to a discussion with Netsujo
Through its AI implementation and business improvement service, Netsujo supports AI and SaaS companies and new business teams across customer problem definition, technical scoping, PoCs, existing-system integration, production deployment, and impact measurement under its Technical BizDev / AI Deployment offering. The scope is defined alongside the responsibilities of your product team and specialist engineers. Ongoing support centered on advice and review is agreed separately from any scope in which Netsujo takes on implementation or operations.
If you need to select suitable workflows, the AI applicability diagnosis is JPY 300,000, excluding tax, over 10 business days. That diagnosis excludes AI implementation, PoC development, and ongoing operations. See the full package scope in Japanese for the current terms. If you already have a PoC, the support scope is designed individually after reviewing its current state and the work required for production use.
Bring what you know about the workflow, what already runs, what is blocked, and the people involved. The templates in the public downloads can help you identify the deliverables and reviewers for one workflow. The source PDFs are in Japanese.