A forward deployed engineer, a solutions engineer and a customer success manager all work with the same customer, often in the same quarter. That overlap is why the titles get confused, and why so many post-sales teams struggle to say who owns the customer at any given moment. The short answer: the solutions engineer proves the product can solve the customer's problem before the deal closes, the forward deployed engineer (FDE) makes it work inside the customer's environment after the deal closes, and the customer success manager (CSM) makes sure it keeps delivering value through renewal and expansion.
This guide compares the three roles side by side: when each one engages, what each owns, what each hands off and to whom. It ends with a simple RACI for the go-live handoff, the point where ownership most often gets lost. If you want a deeper definition of the FDE role on its own, start with what is a forward deployed engineer.
How the Three Roles Differ in One Sentence Each
The cleanest way to separate these roles is by the question each one answers for the customer.
- Solutions engineer: "Will this work for us?" They answer it with discovery, demos, technical validation and proofs of concept during the sales cycle.
- Forward deployed engineer: "Can you make it work here?" They answer it by building integrations, configuring the product and getting the customer to production.
- Customer success manager: "Is this still worth it?" They answer it by tracking adoption, health and outcomes, then running renewals and expansion conversations.
All three are technical to some degree, and all three care about value. The difference is the stage of the customer lifecycle they are accountable for and the kind of work they do there.
Forward Deployed Engineer vs Solutions Engineer vs CSM: Side-by-Side
| Dimension | Solutions engineer | Forward deployed engineer | Customer success manager |
|---|---|---|---|
| Main stage | Pre-sale | Rollout and early adoption | Steady state through renewal |
| Core question | Will it work? | Can we make it work here? | Is it still delivering value? |
| Typical work | Discovery, demos, technical validation, proofs of concept | Connectors, setup, data migration, cutover | Adoption reviews, health checks, QBRs, renewals |
| Owns | Technical win and solution design | A working production deployment | Retention, adoption and expansion |
| Hands off to | FDE or delivery team | CSM | Account team at renewal or expansion |
| Measured on | Technical win rate and deal support | On-time go-live and technical readiness | Retention, health and account growth |
Treat the table as a default. In smaller companies one person may cover two columns, and in enterprise deals the FDE often stays involved long after go-live.
Solutions Engineer: Proving It Works Before the Deal Closes
Solutions engineers, sometimes called sales engineers or presales engineers, sit with the sales team. Their job is to understand the buyer's technical requirements and show credibly that the product meets them. That usually means running discovery calls with technical stakeholders, tailoring demos, answering security and architecture questions and scoping a proof of concept.
The solutions engineer's most important output for post-sales is not the closed deal. It is the record of what was promised. Requirements, success criteria, known gaps and workarounds discussed during the sale all shape the implementation. When that context lives only in a call recording or a sales engineer's memory, the FDE starts the project already behind.
A good habit is a written handoff brief before kickoff that covers deal context, key contacts, recent calls and open items. Quivly's skill templates include a Sales Handoff Brief that pulls exactly this context together for the team running kickoff. For a full checklist, see the sales-to-implementation handoff.
Forward Deployed Engineer: Making It Work in the Customer's Environment
The forward deployed engineer is embedded with the customer after the sale. Where the solutions engineer shows what is possible, the FDE does the hands-on technical work to make it real: connecting systems, mapping data, configuring workflows, writing custom code where needed and validating that everything holds up under real usage.
FDEs typically own:
- The technical plan from discovery through production cutover, including milestones, dependencies and readiness gates.
- Integrations and data, including connectors, field mappings, migrations and validation.
- Technical risk, meaning catching integration failures and errors before the customer feels them.
- Early technical adoption, so customers actually use the capabilities that drive value after go-live.
This is where a shared plan matters most. Quivly's forward deployed engineer workspace ties milestones, owners, dependencies and customer readiness into a single rollout timeline that CS and engineering both see, so the FDE and CSM work from the same plan from kickoff through cutover. Our guide on how to structure a forward deployed engineering team covers staffing and scope in more depth.
A related title you may see is customer engineer. Customer engineers usually build reusable technical assets for the whole customer base rather than one account at a time. In Quivly's framing, they build and roll out AI agents to segments of accounts with guardrails. See what a customer engineer does in post-sales for that comparison.
Customer Success Manager: Keeping Value Going Through Renewal
The CSM owns the relationship once the customer is live. The work shifts from "is it configured?" to "is it being used, and is it producing the outcomes the customer bought it for?" CSMs run adoption reviews, monitor account health, prepare QBRs, manage stakeholders, spot churn risk and expansion signals, and lead the renewal.
CSMs are rarely deeply technical, but they need technical context. When an integration breaks or usage drops, the CSM is usually the one who talks to the customer about it. That makes the FDE-to-CSM link critical even after go-live.
Quivly is designed around that link. When it detects a technical risk, the FDE gets an alert with the technical context, such as error logs, affected endpoints and a recommended resolution. The CSM gets a short summary written for customer communication and a suggested message. Both link to the same incident timeline, so neither has to set up a coordination call to get the facts. For the CSM's day-to-day work, the Quivly view for customer success managers ranks the accounts that need attention and drafts QBR agendas and renewal prep from account data.
Where the Roles Overlap and Where Handoffs Break
Most problems between these roles are not about skills. They come from unclear ownership at the boundaries. The most common breaks are:
- Promises that do not survive the sale. The solutions engineer agreed to a workaround, but the FDE never heard about it.
- Go-live treated as the finish line. The FDE moves to the next implementation, and the CSM inherits an account with half-adopted features and no record of open technical issues.
- Technical issues reported by the customer first. Nobody was watching integration health after cutover, so the CSM hears about a broken sync from an unhappy champion.
- Two versions of the plan. Engineering tracks tasks in one place and CS tracks the customer in another, and the two drift apart.
The fix for all four is the same: one shared record of the customer that each role adds to, and an explicit handoff with named owners at each stage. Our implementation-to-adoption handoff playbook for FDEs walks through the full process.
A RACI for the Go-Live Handoff
Go-live is where ownership most often slips. A simple RACI makes it explicit. R is responsible for doing the work, A is accountable for the outcome, C is consulted and I is informed.
| Go-live activity | Solutions engineer | FDE | CSM |
|---|---|---|---|
| Confirm original success criteria | C | R | A |
| Technical readiness and cutover sign-off | I | A/R | C |
| Document open technical issues and workarounds | C | A/R | I |
| End-user training and enablement | I | R | A |
| Set adoption goals and review cadence | I | C | A/R |
| Post-go-live technical monitoring | I | A/R | I |
| Customer communication about issues | I | C | A/R |
Adapt the letters to your team, but keep one rule: every row has exactly one A. If two roles are accountable, neither is. In Quivly, each project has an owner and each task an assignee, and the project's updates carry an On Track, At Risk or Off Track status, which gives a handoff like this a single place to live.
How to Decide Which Roles Your Team Needs
Not every company needs all three as separate jobs. A few questions help you decide:
- How technical is the sale? If buyers need architecture reviews or proofs of concept to say yes, you need solutions engineering capacity, even if it is shared with product or engineering at first.
- How much work happens in the customer's environment? If implementations involve integrations, data migration or custom configuration that takes weeks, a dedicated FDE function pays for itself in faster, safer go-lives.
- How long and complex is the relationship after go-live? Multi-stakeholder accounts with renewals and expansion potential need a CSM who owns the relationship, not just the tickets.
- Where do handoffs currently break? The role you are missing is usually the one at the boundary where customers fall through.
Whichever structure you choose, the roles work better when they share the same customer context instead of passing documents between tools. Quivly brings implementation projects, product adoption, health and account history into one workspace for FDEs, CSMs and the rest of the post-sales team. If that sounds useful, see how it works for forward deployed engineers.
