1. Selling
In sales terminology, a potential or a likely customer is called a "prospect". Prospects are typically determined by one of the following:
- Leads – These are typically determined by product marketing teams and decision analytics systems supporting product marketing. For e.g., responses from email-, direct- or tele-marketing campaigns may provide good leads to potential customers. Similarly, website analytics tools may be used to analyze web page hits from a particular region to determine prospects.
- Referrals – The customer might indicate an interest to a branch or call center representative who then directs the referral to sales specialists. Service providers also provide customer portals where customers can register an interest.
- Transaction-Based Triggers – Prospects may also be determined by transaction-based activities combined with decision analytics. For e.g., based on customer's long distance calling pattern and its availability to a sales rep, the sales rep may be able to suggest a higher value unlimited long distance plan.
Prospects are turned into opportunities for further processing through the sales-pipeline, based on a number of factors, including but not limited to [TargusInfo]:
- Which prospects are most likely to convert?
- What is a prospect's potential lifetime value?
- What size order would the prospect place if she were to become a customer?
The sales-pipeline supports the key selling related functions such as analysis of customer needs, identification of respective product offerings, sales-negotiation, quotes, proposals, sales forecast, etc. eTOM classifies key selling sub-processes as illustrated in Figure 1 below.
The sub-processes within "Selling" in eTOM are:
a) Manage prospect: This sub-process is responsible for matching assigned leads with the most appropriate products and ensuring that the prospects are handled appropriately [Etom_Gb921]. Activities include capturing and processing the probability of successful sales closure, estimating the total attainable revenue, analyzing the needs of the prospect, identifying potential solutions from the service provider's portfolio, etc.
b) Qualify opportunity: This sub-process ensures that the opportunity is qualified in terms of any associated risk, and the amount of effort required (e.g., response to a RFP vs. potential revenue) to achieve a sale [Etom_Gb921]. Also, customer's needs are analyzed and matched against available product offerings or customized solutions.
c) Negotiate sales/contract: Customers may agree with the standard prices and promotions or may want to negotiate pricing. For example, although the sales rep may have already offered 5% discount, the customer might be looking for a 12% discount. Also, the customer may want to negotiate non-standard terms and conditions/contracts. This sub-process includes activities supporting sales and contract negotiation.
d) Acquire customer data: This involves collection, association and organization of all pertinent data related to the customer, including those that are required to support the agreed product offerings and contract.
e) Cross/up selling: The purpose of this sub-process is to ensure that the value of the relationship between the customer and service provider is maximized by selling additional, or more of the existing products [Etom_Gb921]. Additionally, the ongoing analysis of customer's usage, problems or complaints can be used to identify when the current products may no longer be appropriate for the customer, or an opportunity for a larger sales arise [Etom_Gb921].
f) Develop sales proposal: The purpose of this sub-process is to develop a sales proposal to respond to customer's requirements [Etom_Gb921]. The development of a sales proposal may require selection of standard a product offering or may require the development of a non-standard offering [Etom_Gb921], leading to development of a unique solution design.
Note that the sub-processes defined in eTOM, as shown in Figure 1 above, are in no particular sequence. eTOM refrains from defining sequencing of these processes as different service providers may need to implement them in different sequences, based on their particular environment. Figure 2 below depicts a sample flow that might be applied in a service provider environment.
Once a sales contract has been signed by the customer, its time to create and process customer orders for fulfilling the services that form the product offering. Enter order handling.
Although the terms product offerings and services are often used interchangeably, they have separate meanings. As described by [McFadyen], "This is best thought of as the box that everything is put in. Just as when you buy cornflakes it is the flakes of corn you want inside the box, but it is the box with its logo, brand name, and barcode that you actually purchase." The "flakes of corn" is the service while the "box of cornflakes" is the product offering. From the viewpoint of a product manager, a product offering defines what functionality is provided at what price to which market segments over which sales channel. A service on the other hand is the functionality that the customer gets. Product offerings can get complex in that many different services may be combined in a single offering bundle to make it attractive (cost-effective, for e.g.).
eTOM classifies key order handling processes/activities as:
The sub-processes within order handling are:
a) Determine preorder feasibility – This sub-process is responsible for determining whether the standard/customized product offering chosen for the customer is available and/or feasible. Examples of such checks include (but are not limited to):
- Can the corresponding services be provisioned at the given location?
- Are there enough circuits or lines available in the given region?
- Can the services meet the specified SLA based on current network environment?
c) Issue customer order – This sub-process ensures that all necessary information about the customer order is captured and validated and that the customer has been issues a sales order. This sub-process typically kicks in after a purchase order has been received by the service provider.
A purchase order (PO) is a commercial document issued by a buyer to a seller, indicating types, quantities, and agreed prices for products or services the seller will provide to the buyer [Wikipedia_po], and constitutes a legal offer to buy products or services. Acceptance of the PO by the seller (service provider in this context) forms a contract between the buyer and the seller. A PO ensures the service provider is protected in case of a customer's refusal to pay for agreed products or upon unilateral cancelling of the order [Wikipedia_po].
A sales order (SO), on the other hand, is an order issued by the seller (service provider in this context) to the buyer (customer). Information captured as part of the sales order may include originating PO (one or more), service locations, product configuration data (such as bandwidth, circuit speed, etc.), bill-to customer account, customer contacts, and so forth. Both the customer and the service provider use the issued order to track the status, make edits to the order, etc.
d) Track and manage customer order handling – The objective of this sub-process is to ensure customer provisioning activities are assigned, managed and tracked efficiently to meet the committed availability date [Etom_Gb921]. This includes scheduling activities, generation of respective service order creation requests, tracking orders, adding additional information to existing customer order, cancelling customer order, monitoring jeopardy status of customer orders and escalating customer orders as necessary [Etom_Gb921].
e) Complete customer order – This process is responsible for ensuring that any customer information required by any other processes is updated as part of customer order completion [Etom_Gb921]. This may involve additional touch points with the customer. This may also involve sending relevant notifications to the customer on events such as service provider's acceptance of the order, commitment date, etc.
f) Report customer order handling – The objective of this sub-process is to monitor the status of customer orders, provide notifications of any changes and provide management reports [Etom_Gb921]. Specialized notifications to customers may include those indicating service provider's validation and acceptance of the order, availability date of the services, completion of the provisioning, activations of the respective services, etc.
g) Close customer order – The objective of this sub-process is to close a customer order when the customer provisioning activities have been completed.
As mentioned earlier, eTOM doesn't specify how the sub-processes are sequenced.
References
[McFadyen] Andrew McFadyen, http://telecomseim.blogspot.com/
[Etom_Gb921] GB921 Addendum D-Process Decompositions & Descriptions, Business Process Framework (eTOM), R 8.0, TeleManagement Forum (TM Forum), June 2009
[Wikipedia_po] http://en.wikipedia.org/wiki/Purchase_order
[TargusInfo] "Turning Prospects into Profits", TargusInfo, 2009
1 comment:
Great information and easy to follow. Especially liked the part where you highlighted that eTOM does not define the sequence of the process but that it differs according to service provider.
I also like your suggested sequence as it did pertain to my situation.
Post a Comment