Recommended resources
The freely available resources this lesson will direct you to.
Hello again. The previous lesson showed how to plan responsibly when details are still unknown. One finding from discovery deserves particular care: a customer may ask for work that matters to them but does not automatically belong in the onboarding plan. “We need this before launch” tells you the request is important; it does not yet tell you whether it is an agreed implementation task, a product change, or an operational support need.
This final lesson in the operating-model module gives you a way to make that distinction. The aim is not to send people to different queues as quickly as possible. It is to preserve the customer’s underlying need, identify who can decide what happens, and keep a clear owner for the customer-facing response.
First, find the need behind the request
Customer language often describes a proposed solution rather than the problem. “Add a new export button” might mean users cannot retrieve information they need, do not know about an existing export, or need an output the platform cannot produce. Those are different kinds of work.
Read the relevant parts of Intercom’s The right way to respond to feature requests. Although it is written for customer support, its distinction between an unresolved problem, an improvement, and a genuinely new capability is useful at onboarding intake.
The right way to respond to feature requests - The Intercom Blog
Read this Intercom article to see why a request should be understood before it is labeled a feature request.
Under “How to manage different types of feature requests,” begin with the three types and continue through the subsections on improvements and brand-new features, ending with the discussion of the customer's “specific pain point.” Then, under “Closing the loop,” read the feedback loop. Focus on what information is passed to product, and why acknowledging a need is different from promising a feature.
Before choosing a route, establish four facts:
- What outcome is the customer seeking? Ask what they cannot do today and who is affected.
- What happens with the existing, supported approach? An unfamiliar configuration, a broken function, and a missing capability can look alike from the customer’s perspective.
- Is the outcome part of the agreed deployment? Check the relevant scope and acceptance terms rather than relying on how urgent the request sounds.
- When is the outcome needed, and what happens without it? A genuine launch blocker requires an immediate delivery decision, even if the work itself belongs to product development.
These questions separate classification from priority. Something can be outside onboarding scope and still be urgent. Something can be a product idea without being a condition of go-live. Neither urgency nor a customer's preferred solution, on its own, grants approval to change the deployment.
Onboarding owns the agreed deployment—not every request made during it
A request normally belongs in onboarding execution when it concerns work needed to deliver the agreed initial deployment using an approved approach. That can include configuring a supported integration, clarifying mappings for an agreed data source, arranging the agreed SSO setup, or correcting an implementation error found during validation. The onboarding engineer coordinates the outcome and its dependencies, even when a customer administrator or internal specialist must perform part of the work.
The boundary is the agreed outcome, not a frozen list of low-level tasks. If discovery reveals that a timestamp in the agreed feed needs a documented transformation, resolving that mapping may be ordinary elaboration. If the customer instead asks to include an additional data source that was not agreed, the request needs a scope and impact decision before it becomes onboarding work. It might ultimately be added to onboarding; it is not added simply because the team knows how to integrate it.
PMI’s Controlling scope creep explains why both customer requests and internal enthusiasm can change a project without an explicit decision. Read the selected passages for the boundary-setting principle, not as a prescribed commercial policy: the article’s advice on who pays for change analysis will depend on the actual agreement.
Read PMI’s discussion of customer involvement and protection of an agreed project baseline. It helps distinguish useful clarification from unapproved additional work.
In “Some Practical Advice,” under “For externally induced change,” read from customer ground rules. Then, in “Managing Scope Creep,” read from baseline and impact. Notice that a change can be considered constructively without being silently accepted.
The practical response to a possible addition is neither an automatic “yes” nor a reflexive “out of scope.” Establish what it would change: the agreed result, effort, schedule, security review, data handling, testing, and ownership. Route that information to whoever has authority to approve a revised commitment. Later modules will treat that change process in detail; here, the essential distinction is evaluating a request versus accepting it into the plan.
Product development owns decisions about capabilities
A request belongs in product development when satisfying it requires a capability or behavior the platform does not currently support, rather than customer-specific setup of supported functionality. Product management evaluates the need and its fit with the wider product; software engineering assesses and builds an approved solution. An onboarding engineer can supply evidence and explain delivery impact, but should not promise that a requested capability will be built.
Consider a customer asking for a new, platform-wide permission type because the existing roles cannot express an access boundary they require. You should first check whether supported roles meet the underlying need. If they do not, this is potentially a product gap. If the access boundary is mandatory for the agreed deployment, it is also an onboarding blocker. The two descriptions answer different questions:
- Product gap identifies where a capability decision belongs.
- Onboarding blocker identifies its effect on the current deployment.
A blocker does not move product authority to the onboarding engineer. It calls for a timely joint decision: is there an approved alternative that meets the requirement, must the launch scope or date change, or is product work needed before launch? A privacy or security requirement must not be waived merely to preserve the date.
The selected excerpts of Linear’s Managing Feature Requests with Linear show a useful distinction between capturing customer evidence and committing to build. The particular tracking tool is incidental.
Managing Feature Requests with Linear
Watch Managing Feature Requests with Linear from Linear to see how incoming suggestions are checked against existing requests, then considered by product before development is committed.
In request triage, notice the duplicate check and categorization. Then watch product discovery for the distinction between collecting feedback and deciding what to pursue. In prioritization, focus on the point at which demand signals become a planned product effort; a recorded request alone has not crossed that boundary.
Useful feedback to pass along includes the customer’s desired outcome, affected users or workflows, current limitation, examples obtained through approved channels, any acceptable workaround, and the consequence for go-live. This is more useful than forwarding only “customer wants a button.” In this role, take particular care not to attach sensitive customer records to a general product-feedback system without authorization.
A reported defect needs a slightly different distinction. If an existing capability fails to work as intended, engineering may need to fix it; that does not make the failure a request for a new feature. During onboarding, you still own visibility of its effect on validation and launch. The technical fix, the deployment decision, and the customer update may have different owners.
Ongoing support owns operation after handoff—but the boundary is not just a date
Ongoing support is the usual route for help operating a live deployment: diagnosing a failed feed, investigating a login problem, helping an administrator use existing functionality, or handling an incident under the established support arrangements. Its purpose is to make the deployed service work reliably, not to decide the product roadmap or quietly extend implementation scope.
Timing matters, but it is not the sole test. A login failure during pre-launch testing may be handled through a support ticket or engineering investigation, while the onboarding engineer retains responsibility for its effect on launch readiness. Conversely, a request made after go-live for a new integration is not automatically “support work” merely because onboarding has ended. Support may receive and triage it, but a new implementation or product decision still needs its proper route.
Watch the excerpt from CSM Practice’s The Ultimate Guide: Customer Success vs Customer Support for the customer-facing consequence of unclear routes. The speakers discuss success and support rather than onboarding engineering, but the same temptation applies when you have become the customer’s familiar technical contact.
The Ultimate Guide: Customer Success vs Customer Support
Watch this CSM Practice discussion to understand why a helpful relationship can turn into an unofficial support channel, and why a handoff needs a usable route rather than a simple refusal.
Watch support pathways. Focus on the account of customers bypassing the normal channel and the concluding point about setting expectations and appropriate pathways. Apply it to the transition from an onboarding contact to ongoing support.
An effective handoff tells the customer where to report a problem, what information to include, what response route applies, and who remains responsible for any open onboarding items. If a serious incident arrives in your inbox after handoff, help get it into the right operational channel and ensure it is acknowledged. You need not become its permanent, private support desk. Clear routing protects the customer as well as your capacity to deliver other onboardings.
One request can require several routes
The most useful mental model is not three mutually exclusive boxes. Give the request a primary decision or work owner, then identify any parallel effect on the onboarding plan and any customer communication owner.
| What you establish | Primary route | What the onboarding engineer still does |
|---|---|---|
| An agreed source feed needs a supported field mapping clarified before acceptance | Onboarding | Coordinates the data owner, documents the meaning, and confirms the acceptance check |
| A new source system is requested for the initial launch, outside agreed scope | Scope decision first; onboarding if approved | Assesses delivery impact without treating the request as accepted |
| A required access rule cannot be expressed with supported platform behavior | Product evaluation | Makes the launch consequence visible and seeks a decision on an acceptable path |
| A previously working production feed stops delivering records after handoff | Ongoing support | Helps route relevant context if needed; does not leave the incident in an untracked personal conversation |
This also explains why a request may change category as you learn more. “We need different redaction” could mean the agreed configuration was applied incorrectly, the customer has introduced a new rule, or the platform cannot support a required control. Until you establish which, record the request as unclassified, name the question that would resolve it, and avoid implying a commitment.
Once classified, close the loop in plain language. For example:
“I understand the need is to restrict access to these records before users begin validation. I’m checking whether the agreed configuration supports that boundary. If it does not, I’ll bring the gap and its launch impact to the product and project decision owners. I’ll update you with the available options rather than commit to an unverified change.”
That response does three jobs: it confirms the need, names the next investigation, and retains accountability for an update. It does not imply that logging feedback equals a roadmap commitment. Whatever internal tools the team uses, keep the request, its classification, decision owner, effect on go-live, and customer response traceable.
Key takeaways
Route a customer request by examining the underlying need, agreed deployment scope, supported behavior, lifecycle stage, and decision authority. Onboarding delivers the approved initial outcome; product decides whether to develop missing capabilities; ongoing support operates and troubleshoots the live service. Scope changes need approval, and defects may need engineering work without becoming feature requests. A request can belong to one route for resolution while also creating an onboarding risk that you must manage.
This completes the operating-model module. Next, the course turns to airline customers and safety context: the environment in which these delivery decisions will be made, and why seemingly routine data and workflow choices can carry unusual consequences.