The demo went well. The buyer likes the product, and your sales team is already talking about a launch date. Then the buyer says, \u201cWe\u2019re ready to move forward. We just need one thing.\u201d That one thing is an approval workflow you never planned to build, and they need it before the end of the quarter.<\/p>\n\n\n\n
It\u2019s tempting to say yes while everyone is still on the call. A large customer can bring revenue, useful feedback, and a chance to learn how your product holds up in a bigger business. But a feature that sounds small in a demo can occupy your team for months once you include testing, support, and the changes it forces elsewhere. The decision gets easier when you understand the customer\u2019s problem, the value to your product, and what your team would have to postpone.<\/p>\n\n\n\n
Customers often describe a feature by explaining how their current system works. If they ask for three approval screens, it may be because three people review a request today. Their real need could be more specific: managers should approve exceptions, and finance should be able to see who signed off. Once you know that, you can explore options that fit how your product already works.<\/p>\n\n\n\n
Ask the buyer to walk you through a recent example. Who started the request? Where did it get stuck? What information did the approver need? Then find out what would actually prevent them from using your product on day one. A record of who approved a request might be essential. A report with the same layout as their old system might be something they\u2019re willing to revisit later. You\u2019ll get a better estimate once you know which details matter and why.<\/p>\n\n\n\n
A request can point to a valuable product improvement even when only one customer asks for it directly. Your support team may already have heard related complaints. Another customer may be solving the same issue with spreadsheets, email threads, or a colleague who checks every request manually. Look for evidence of the underlying problem instead of counting votes for a particular button or screen.<\/p>\n\n\n\n
It also matters which<\/em> customers would benefit. If your SaaS product is moving toward larger teams, an approval feature may fit even if your smaller accounts never use it. On the other hand, a workflow that copies one buyer\u2019s internal structure can be difficult to explain, sell, and support elsewhere. Ask your team how they\u2019d describe the finished feature to a second customer. If that explanation only makes sense after describing the first buyer\u2019s business, you may be looking at custom work.<\/p>\n\n\n\n Imagine a SaaS company that helps property managers coordinate maintenance. A prospective enterprise customer asks for three levels of approval on every work order, with separate screens for site staff, regional managers, and finance. The product team could start designing those screens immediately. Instead, they ask to see a few recent jobs, including one that took too long to approve.<\/p>\n\n\n\n It turns out that the delays mostly happen when repairs exceed an authorised spending limit. Routine requests rarely need a regional manager or finance reviewer. The team proposes a smaller release: send requests above an agreed limit to an authorised reviewer, record the decision, and let staff check the status. They ask the buyer to test this against both a routine repair and a costly exception. The buyer can then judge whether the proposed release covers the real need, and the SaaS team can assess whether other property managers would use it.<\/p>\n\n\n\n Engineering note:<\/strong> If you make an approval rule configurable, decide what happens to requests already in progress when someone changes it. A request submitted under one rule should have a clear, predictable path even if an administrator updates the settings before approval.<\/p>\n\n\n\n A development estimate tells you how much effort it may take to ship the first version. It doesn\u2019t tell you how much work the feature will create later. A customer-specific rule may need separate testing whenever permissions change. Support staff may need to learn which behaviour applies to which account. If the original customer leaves, your team may still be maintaining their workflow. Those costs should be part of the discussion before you agree to build.<\/p>\n\n\n\n Make the tradeoff concrete by naming the work that would move. If accepting the request pushes back an onboarding improvement, who will feel that delay? Conversely, if the request could help you sell to more teams in your target market, what evidence supports that opportunity? Put both possibilities on the table. A deal can justify changing the roadmap, but it\u2019s easier to make that decision when everyone can see what\u2019s being exchanged.<\/p>\n\n\n\n When the customer\u2019s problem is clear but the solution still needs review, give sales a response they can use: \u201cWe understand that larger repairs need approval before work begins. We\u2019re checking whether our current workflow can support that, and we\u2019ll show you what\u2019s possible before committing to a date.\u201d That keeps the conversation moving without making a promise engineering hasn\u2019t evaluated.<\/p>\n\n\n\n If you decide to build, write down what the first release will do and how the buyer will tell whether it works. If you decide against it, explain the specific gap and offer a workable option if you have one. A clear answer early gives both sides room to make a decision they can stand behind.<\/p>\n\n\n\n Separate pricing can make sense when the work requires customer-specific implementation or ongoing support. Decide who will maintain it, what future changes cost, and whether the capability will become part of the shared product.<\/p>\n<\/details>\n\n\n\n A workaround can fit when the task is infrequent, the process is reliable, and the customer understands who owns it. Agree on when you\u2019ll revisit it, especially if the team expects usage to grow.<\/p>\n<\/details>\n\n\n\n Agree on the outcome, what\u2019s included in the first release, the dependencies, and the examples the customer will use to accept it. Then estimate the work against your existing commitments.<\/p>\n<\/details>\n\n\n\nWhat you discover<\/th> A reasonable next step<\/th><\/tr><\/thead> Several customers need the same outcome<\/td> Consider a shared feature with a focused first release<\/td><\/tr> Existing settings can meet the need<\/td> Demonstrate the workflow before promising development<\/td><\/tr> The request depends on a tool the buyer already uses<\/td> Check whether an integration can cover the gap<\/td><\/tr> The outcome is valuable but the full request is large<\/td> Agree on what must work at launch and what can wait<\/td><\/tr> The rules are unique to one customer<\/td> Evaluate it as separately scoped custom work<\/td><\/tr> The request would delay a more important commitment<\/td> Explain the tradeoff and offer a realistic alternative<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n An Illustrative Example: The Three-Level Approval Request<\/h2>\n\n\n\n
Count What the Feature Will Cost After Launch<\/h2>\n\n\n\n
Give Sales a Useful Answer Before the Next Call<\/h2>\n\n\n\n
Frequently Asked Questions<\/h2>\n\n\n\n
Should we charge for a feature requested by one customer?<\/summary>\n
When is a simple workaround enough?<\/summary>\n
What should we agree on before committing to a delivery date?<\/summary>\n