Ci sono due problemi, che devono essere disattivati.
-
Smetti di quotare in tempo, inizia a quotare in dollari. Ciò consente loro di eseguire rapidamente un'analisi costi / benefici e di aggiungere un preventivo standard "tempo di analisi". Il tempo è troppo appiccicoso, perché non riflette la reale quantità di lavoro svolto (potrebbero essere fatte quaranta ore in un giorno, cinque giorni o tre settimane) ed è fin troppo facile per non spingere indietro il ciclo di rilascio preventivato per tale richiesta.
-
Fornisci al personale di vendita un input di richiesta nel ciclo di sviluppo (preferibilmente un'interfaccia non umana, per risparmiare tempo (misurato in denaro)).
Le persone di vendita tendono a pensare in termini (se ho X, posso chiudere questa vendita). Le loro richieste spesso non sono coerenti con l'architettura attuale del prodotto, ma sono coerenti con l'attuale bisogno di un cliente.
Indica alla forza vendita che tali richieste sono vitali per il tuo prodotto, e in quanto tale, hai bisogno di non perderle nella "richiesta rapida", richiederà più tempo rispetto al periodo di interesse, rilasciare la richiesta, ripetere "ciclo". Tali richieste devono essere catturate, analizzate, classificate in ordine di priorità, integrate nel prodotto, testate e rilasciate con il prossimo ciclo di rilascio.
Quindi fai il backup delle parole con le azioni. Abbreviare il ciclo di rilascio a meno di due mesi, indicare quali elementi saranno presenti nella versione e rispettare le scadenze. Non istruire il personale addetto alle vendite in merito ai motivi interni, è sufficiente fare un'analisi di ciò che una richiesta fuori ciclo minimizza i costi (in dollari) e quale potrebbe essere il costo (dollari aggiuntivi e percentuale di occorrenza) se un problema supera la complessità minima. Quindi chiedi al venditore se la vendita è sufficientemente grande da supportare la richiesta fuori ciclo.
Una volta che hanno un processo per una richiesta in-cycle, e hanno un'idea di quanto costa gestire una richiesta fuori ciclo, le probabilità sono buone per poter convertire la richiesta fuori ciclo in una richiesta in-cycle, o determinare che la richiesta out-of-cycle sia abbastanza proficua da giustificare la spesa.