Customer perceived value in software business relationships
Competitive paper for IMP2011 Conference
Helander, Nina1
Department of Business Information Management and Logistics, Tampere University of
Technology, P.O. Box 541, 33101 Tampere, Finland, Tel. +358504004275, Fax.
+358331154680
nina.helander@tut.fi
Ulkuniemi, Pauliina 1
Department of Marketing, Oulu Business School, University of Oulu, P.O. Box 4600, 90014
University of Oulu, Finland, Tel. +358 8 5532080, Fax. +358 8 2906
pauliina.ulkuniemi@oulu.fi
Abstract
This paper addresses perceived customer value in the context of software business. Customer
perception of value is a complex phenomenon not only theoretically, but even so in practice.
We have chosen to examine this phenomenon in the specific context of software business, as
we believe that software as object of exchange gives to the analysis fresh viewpoints due to its
abstract nature. Our study is exploratory in nature, with an empirical insight gained through
two qualitative case studies from the software business. As a conclusion, we present elements
of customer perceived value within both software project and product business. Based on this,
we suggest a framework for examining the way business logic has an influence on the
customer’s value perception, especially in terms of the complexity of the perception of both
benefits and sacrifices.
Keywords: Value perception, customer, business relationship, business logic, software
business
1
Corresponding author
Authors have contributed equally to the paper
Introduction
Value creation in business relationships has gained a lot of attention in the marketing
literature in the last decade (Lapierre, 2000; Flint, Woodruff, & Gardial, 2002; Eggert, Ulaga,
& Schultz, 2006). It has been emphasised, that customer perceived value is always the
customer’s subjective evaluation of the sacrifices and benefits involved into to the exchange.
Value has also been approached as including various elements, both monetary and nonmonetary (Ravaland & Grönroos 1996, Eggert & Ulaga, 2002, Ulaga, 2003; Komulainen et.
al 2007). Thus, the customer perception of the value is a complex phenomenon not only
theoretically, but even so from the managerial perspective. Furthermore, the contextdependent nature of value has also been emphasised in the literature and therefore value has
been studied in different types of industry contexts. Our study continues this line of research,
being an exploration of customer perceived value within a specific industry context.
We have chosen the software business as the industry context for our study as we believe that
the abstract nature of software causes even more challenges in understanding the customer
perceived value than is the case in more traditional industries. Software business is a blurred
business, but very important business sector for our everyday life in the form of increasing
intelligence in all kinds of devices that we use. Cusumano (2004) suggest that to capture the
blurred nature of software business we can consider two basic business logics in the software
industry: software products and software projects (see also Tähtinen 2001, Alajoutsijärvi et al.
1999, Hoch et al. 1999). Between these two different business types there are also different
kinds of “hybrid” software businesses, i.e. businesses that include both product and project
oriented strategies (Cusumano 2004). Even though the number of software companies that are
following the hybrid business logic is continuously increasing, there still are a great number
of companies that either represents a rather pure product company or a rather pure project
company. These two types of business logic can be seen as very different from each other
when it comes to such important management and marketing issues as central capabilities,
object of exchange, production, customer base, nature of markets, branding, nature of
exchange, and type of organization (Alajoutsijärvi et al. 1999). Thus, software, being a
complex combination of product and service elements and including technological
complexities is a challenging object of exchange for both software buyers and sellers. The
pace of technological development in these industries is also causing complexities for the
market participants.
In this study the objective is to increase empirical understanding of the customer perceived
value in software business. We aim to find out, how can the customer perceived value be
understood in software business and how is the business logic intertwined on the customer’s
perception of value? Our study is more of an exploratory in nature and with empirical
emphasis. To gain preliminary understanding we will use the existing literature on value
creation in industrial marketing and software business. In the empirical part, we have
conducted an interpretive qualitative study in order to explore the nature of customer
perceived value in the chosen industry context and to find out how the business logic is
connected to it. Our research strategy includes a multiple case study of two customers, one
focusing on project business and another in product business.
Perspectives on customer perceived value
One of the most topical themes in marketing is the discussion on value creation in business
relationships (Eggert et al., 2006; Flint et al., 2002). In the existing literature, value is
typically conceptualized as the subjective perception of the trade-off between benefits and
sacrifices – both monetary and non-monetary (Walter et al. 2001, Lapierre 2000, Parolini
1999, Slater 1997, Berry & Yadav 1996, Ravald & Grönroos 1996). The benefits and
sacrifices can be understood in monetary terms, but they can also be seen as including nonmonetary rewards, such as competence, market position, and social rewards (Walter et al.
2001). The non-monetary aspects of value have received particular attention in studies aiming
to classify these different value aspects (e.g. Ravald and Grönroos, 1996; Eggert and Ulaga,
2002; Fiol et al., 2011). Such benefits might include product quality, delivery, personal
interaction and service support (Ulaga, 2003). Non-monetary costs can include time, effort,
and energy spent, including that spent on conflict resolution, by the customer to obtain the
product or service. In this study, value is understood in both monetary and non-monetary
terms.
An essential element in the current understanding of value is also subjectivity and the idea of
perceived value. These refer to the basic nature of value for the customer – the value created
by the supplier is in the end measured in the mind of the customer, it further leads to the fact
that the value created is in most cases very hard to measure. In terms of software, the
complexities related to the multifaceted nature of benefits and sacrifices often create
challenges in the buying decision as the non-monetary aspects, such as e.g. training needs,
technological uncertainties and liability issues may be difficult to determine.
The value that the customer perceives is also relative to competition – meaning the alternative
solutions that the customer is considering or has available in relation to the particular need
(Ulaga, 2003; Komulainen et al., 2007). The supplier should be able to create more value than
the customer could achieve by choosing some other solution created by another, competitive
supplier. This kind of differential value is very hard to define and measure, because the
expectations of the customers are based on the alternatives available on the market; that is, the
impact of a similar or substitute product is remarkable Parolini (1999). Thus, measuring
differential value always requires a mapping of other potential solutions and comparison of
those with the one under consideration. However, it is not usually an easy task to identify
which options are seen as potential and comparable solutions in the eyes of the customer. For
the supplier, it is thus essential to understand the alternatives to the supplier’s offerings that
customers consider. In general, a false perception of value is more likely when there are
intangible elements and services present, or systemic and complex goods, or benefits that are
not immediate, or post-purchase costs and costs of consumables, products and services that
are new to the customer; and lastly, in the case of infrequently purchased goods (Parolini,
1999). From the viewpoint of software business, the above mentioned list is interesting:
software is indeed an intangible and in many cases a rather complex good, with benefits that
are not usually immediate, as software is valued by what it does, not by what it is.
Value is, however, not merely tied to the actual object of exchange, such as a software
component; instead it is dependent on the success of the whole relationship between the
customer and the supplier (see e.g. Lindgreen & Wynstra 2005). This view underlines the
importance of understanding value creation as a process during which the customer and
supplier interact and therefore, not only the product but also to the overall process through
which the product is developed, marketed, and delivered to the customer should be considered
(Kothandaraman and Wilson, 2001). The process view is especially relevant in terms of the
service aspects as the value a customer perceives may be different during the exchange
process and after it when the customer is able to evaluate the outcome of the process more
thoroughly (Lapierre, 1997). In the software business context, during the interaction, the
software and related services are exchanged between the parties and thus the benefits and
sacrifices are realized. However, there is also a great amount of interaction between the
parties in the relationship that is not directly related to the object of exchange. This interaction
does, however, usually influence how the customer perceives the total value obtained.
Naturally, it is hard to draw clear distinctions between the value perception related to the
object of exchange and that related to the relationship, and usually this distinction is not even
necessary. However, sometimes it is important to bring out the role of relationship-related
value, in order to remind the actors in the field that the value perceived by the customer is the
sum of many things. These elements are sometimes only indirectly related to the object of
exchange, but nevertheless their weight in the customer’s perception of value can be essential.
Software business characteristics
Software plays nowadays an important role in our modern society because of two interrelated
reasons. Firstly, the remarkable growth of software business and its influence on the world
economy is huge (Messerschmitt & Szyperski 2003). Secondly, software is strongly present in
our every-day life: when we use our mobile phone, travel by airplane or use modern home
devices, we are dealing with software. The software business is typically characterized by
distinction of software product and software project business (see Cusumano 2004, Hoch et
al. 1999). Software project business is a professional software service or to tailored software
business (see, e.g., Alajoutsijärvi et al. 1999) in which the customer organization is usually
charged an hourly rate, not a fixed price for the software products or components provided.
Software product business refers to software products that are provided standardized to
several customers. However, also companies that use a hybrid business logic employing both
two logics operating thus partly in both of these different business areas exist (Sallinen 2002,
Cusumano 2004). In their purest forms, the two logics represent rather different types of
businesses in many respects. Differences can be identified at least in central capabilities,
object of exchange, production, customer base, nature of markets, branding, nature of
exchange, and type of organization (Alajoutsijärvi et. al., 1999).
The software product business has same types of characteristics as typical firms operating in
the consumer goods industries. The software is highly standardized and productized and sold
to a mass of customers in the market. Within software industry, one example of highly
productized business, is the software component business which is based on the idea of offthe-shelf software which is sold and bought as any standard item (see e.g. Morisio et al.
2000). In software product business the relevant managerial areas include productisation,
channel management, alliance building and branding (Alajoutsijärvi et. al, 1999).
In software project business the key managerial issues include project management,
management of few close customer relationships and importance of key individuals
(Alajoutsijärvi et. al, 1999). The role of services is central in project business firms. Tailoring
software typically means that work is done together with the customer within service
relationship which means that in terms of management and marketing especially, issues such
as customer service and key customer management become crucial and the importance of
personal communication with the customer is in the focus.
Empirical research methods
In the empirical part, we have adopted qualitative approach which enabled us to examine the
research phenomenon in a holistic way. This is needed as the phenomenon under study the
customer perceived value in the software business is closely intertwined with its context. The
purpose here is to explore empirically how the customer perceived value can be understood in
software business and how does the business logic influence on the customer’s perception of
value. Our intention is to find out, what are the elements of customer perceived value in this
empirical setting though looking at both customer perceived benefits and sacrifices and also
the way these elements interplay.
Our research strategy includes a multiple case study of two firms buying software. As was
discussed earlier, the two business logics of project and product business describe the
software business notably. To encompass all the aspects of customer perceived value in
business relationships in software business, a case from both product business and project
business is needed. Our empirical research setting thus includes two cases; a case of customer
perceived value from the project business and another from the product business. In the
analysis, we focused on identifying especially those value elements that were related to the
particular business logic. Thus, the specific functionalities and characteristics of the actual
software in the cases were not in the focus of our analysis, although of course, these were
intertwined in the identified value elements as well.
Our empirical data includes interviews of the two software buyer companies and suppliers
from both cases in order to enlighten both the relationship’s counterparts’ views. Concerning
the case in project business, three interviews of representatives of the buyer company were
conducted and six interviews of supplier firm representatives. The data in the case of product
business includes 13 interviews of the representatives of the particular buyer organization and
two interviews of supplier firm’s representatives. The interviews lasted about 1-2 hours and
they were recorded and transcribed afterwards. The empirical data was analysed through
classifying the data according to the theoretical pre-understanding. This included the
categorising of the data according to the customer perceived benefits and customer perceived
sacrifices. A second round of categorising was conducted in order to identify the different
types of benefits and sacrifices. Thus the second round of categorising was more data driven
where as the first was a theoretical categorising. After identifying the different types of
customer perceived benefits and sacrifices, we conducted a cross-case analysis in order to find
out, how the different value elements interplay within the two different business logics. Next
we will present the analysis of the two cases and describe the customer perceived value in
them based on the sacrifices and benefits. After this, we will present a synthesising discussion
of the both cases and suggest a framework for understanding the way business logis and value
perception are interconnected.
Case studies of customer perceived value in software business
In next, we will discuss both of our cases, the project business and the product business case.
In both of the cases, the customer is named as the Buyer company and the seller is referred as
the supplier.
Case analysis of customer perceived value in project business
The first case represents project business logic. The object of exchange in the case is large
automated production system that is based on integration of software and hardware as a total
service solution. Through the automated production system, there is an aim of creating value
for the customer by providing more efficient and effective production capabilities.
The Buyer company represents telecommunications sector and as it is engaged in tough
competition for customers, production capabilities play a fairly important role in the
company’s business processes as a whole. In fact, the Buyer company places a greater value
on production capabilities that enable flexible production processes by providing the
possibility of using a single production line for both mass production and production of
customised products. Thus, no separate production lines for different product variations are
necessary and the customer is able to achieve savings in line investments and in floor space,
and to attain shorter production times.
Based on the interviews, the Supplier company of the system solution has been able to
provide general information on its value creation potential; thus, a general-level value
proposition has been developed and communicated among the customer, i.e. the Buyer
company. However, there were also some special things that the Buyer company valued a lot,
and, furthermore, these things could in fact be provided by the supplier and the then-current
version of its system solution. Yet these special wishes weren’t communicated between the
supplier and the Buyer company well enough. The problem was two-sided: the Buyer
company wasn’t stating what kind of special value they expected from the system solution,
and the supplier had not informed the customer well enough of the new developments of the
system solution that could indeed offer the extra features the customer desired. One such
special feature was component-level tracking, which was valued by all the interviewees. For
some reason, however, the value placed on this feature was not recognized by the supplier.
We can argue that such problems identifying the things that customers really value are of
course related to the nature of the relationship, its closeness, and also sharing of information
between the parties in the relationship. In this case relationship, there were problems in the
closeness of the relationship even though close relationships are usually preferred in project
business.
In order to stay competitive in the project business, the supplier should also be able to provide
solutions that the Buyer company itself is not even aware of yet. However, to enable such
solution provisioning, the supplier should be so close to the customer that it has a thorough
understanding of the customer’s value creation processes. By contrast, in the case relationship
there were lots of changes inside the supplier company in terms of the people who had contact
with the customers. The changes did cause a decrease in understanding of customers’ value
creation processes within the supplier company. Additionally, the many personnel changes at
the supplier led to decreased customer satisfaction.
In realizing the perceived value as a trade-off between benefits and sacrifices in both
monetary and non-monetary terms, the system solution can benefit the Buyer company in the
form of more efficient and effective production of its own products. This benefit could be
measured in monetary terms, but it also includes value elements that are non-monetary in
nature or at least whose benefits are not so easily measured in monetary terms. The main
difficulty in measuring ‘more effective production’ in strictly monetary terms is that the
benefits are not always immediate and/or easy to predict. For example, if the customer
acquires the system solution mainly because it can provide the ability for component-level
tracking, the benefits of the investment become real only if there occurs a real need for
component-level tracking. In other words, the benefit of the feature provided by the system
solution becomes real in the event of problems during production, in particular involving
defective components.
In practice, however, the Buyer company expected that the supplier could provide fairly exact
monetary calculations concerning the savings achieved by an automated production line
compared to manual production. This is especially true of the ‘core package’ of the system
solution, representing the basic functionalities offered by an automated production line. By
contrast, in the case of the more advanced, additional features and functionalities, the role of
exact monetary calculations as bases for value proposition and sales arguments diminishes.
It was also identified, from the empirical data, that besides expecting direct value in the form
of more effective and efficient production, the Buyer company was also expecting indirect
value from the supplier in the form of reduced activity requirements, as interaction with
several suppliers decreases when the whole system solution is acquired from a single actor.
However, this was unfortunately something in which the supplier had not been very
successful.
The Buyer company’s interviewees discussed the value created for their company by the
supplier through identifying different activities. In particular, they brought up activities, or
lack of activities, taken by the supplier in their shared relationship history with which they
weren’t pleased. These were activities that could have been identified and taken into account
by the supplier if it had more precisely identified the value creation processes of its customer.
One of these was indeed the sharing of information. Customer felt that, although it wanted to
interact only with the supplier as the system solution provider, they were several times forced
to contact the supplier’s subcontractors, too, in order to get problems solved. Thus, customer
would have valued the possibility of decreasing the amount of interaction with several actors
during the project, but this could not be provided by the supplier in practice.
In the following Table 1 we will present the summary of the analysis of the value benefits and
sacrifices perceived by the customer in the case of product business logic.
In the case project business the biggest benefit that the customer was expected to achieve
from the relationship with the single automation system supplier was savings in time when
everything was got from single supplier and through wide project delivery. However, this
benefit seemed not to be realized, as there were a lot of complexities related to this. First of
all, a broad project delivery is not usually possible to be created and implemented only by one
actor and thus there is nevertheless a need for a broad network of subcontractors. In our
project business case the supplier was not able to handle this wide network by its own, and
thus the buyer company as the customer was nevertheless forced to be in contact with other
suppliers and subcontractors e.g. in case something went wrong in the project. Secondly, even
though a potential benefit from the project relationship could be born from the close
relationship between the customer and the supplier in form of overall supporting of the other
party’s value creation process, this did not happen in the studied case. Thus it seems that we
cannot automatically assume that project business means close relationship with lots of
benefits in a project business environment. It can be even vice versa, if the project does not
success for some reason, the relationship counterparts may even end up to have an arm’s
length relationship without no kind of real understanding of the other’s business aims and
value creation processes.
Concerning the sacrifices, the main elements identified included schedule problems and
challenges in committing to the supplier even in cases where the supplier was in fact not able
to offer a complete solution.
Table 1. Identified value elements from the project business case
Value elements
Benefits
Total system solution from
single supplier
Deeper understanding and
support of the customer’s
overall value creation process
Sacrifices
Schedule problems
Committing to the supplier
Complexity
of
the
customer’s
perception
Very high – reduced number of activities
was aimed, but not achieved. Too complex
and inexactly defined objective and thus
led to ambiguity.
High – relationship was labeled as close
one, but did not realize to deep interaction,
trust and support of the other party’s value
creation process.
Low – the schedule problems were caused
by the project based delivery, but they
were rather expected and did not cause
severe problems.
Rather low – customer perceived as the
biggest sacrifice the commitment to a
single supplier that wasn’t always ready to
offer a turn-to-key solution that was the
ultimate aim of the customer. Still they
wanted to continue co-operation due to
long shared history.
Case analysis of customer perceived value in product business
The second case represents the product business logic and involves a large buyer organization
from the Finnish ICT sector. The company produced telecommunications equipment for
industrial customers and its products included both software and hardware. The buyer had a
long experience on buying software from sub-contractors and other types of industrial
suppliers. Operating as a buyer in software product business logic, however, was a rather new
way of buying software for the organization. The relationship with the supplier was developed
around an operating system software product, which was included into the buyer’s product as
a software component. The most distinctive feature of software component was that the
source code was not available to the customer organization, and further development of the
component was not under the control of the buyer. The supplier company was a middle-sized
company and had adopted strongly the product business logic by diversifying the organization
into software product division and professional services division. The relationship between
the supplier and the buyer company had existed for a rather long time and it included a several
purchases of different versions of the software products as well as different types of products.
With respect to the value benefits perceived by the buyer organization, based on the data, one
of the most important benefits that the interviewees raised up was the minimizing the overall
development and maintenance costs of software through the purchase of the particular
software product in question. Another important benefit was related to the lack of software
developers; by using external solutions the buyer company was able to focus on more central
areas of development in their software engineering. Thus, the alternative was to do the
particular piece of software by themselves which illustrates the differential value experienced.
The buyer company also saw that by using external solution they were able to reduce some
risks associated with software development as the software was developed by a firm whose
core competencies lay in this particular field of software engineering. Furthermore, as other
customers also use the component, possibly even competitors, quality of the component is
regarded as being higher. An important benefit in using software component was also the
possibility of attaining shorter time-to-market for the actual products as they did not need to
make everything by themselves. The case company had also recently adopted component
based software engineering principle, meaning that it was in their strategy to increase the use
of components in their software systems. The increasing opening and standardization of
interfaces in telecommunications equipment was essential factor in this.
The customer’s perception of the value sacrifices was one of the most important challenges
from the purchasing perspective. The Buyer company found it very difficult to understand all
the costs that were related to buying and using the software products. In terms of buying
process, Buyer company had difficulties in evaluating the components and potential suppliers.
The contracting issues were very difficult mostly because both technical and purchasing
related expertise were needed but the Buying company, however, was not able to smoothly
integrate technical and legal people and intertwine their expertise. For example, it was very
difficult to define the responsibilities between the parties of the relationship. As the software
component became a part of the product of the customer, sold forward to customer’s businessto-business customers, complex chains of responsibilities resulted. The possibilities of the
buying customer to test and understand the component were limited due to their ‘black-box’
nature. From the supplier’s perspective, it was very risky to accept a broad responsibility like
this, since the supplier was not a very large company. In the case of failure these suppliers
with large customer companies with big markets could easily be forced to bankruptcy due to
massive claims for compensation. Pricing issues were also one of the most important issues
that the interviewees were concerned about. All in all, the pricing of the software components
was a difficult issue. There was a lack of understanding of how the costs and benefits of the
components could be estimated. Suppliers had different means of pricing their components
and related services, and the Buying company had severe difficulties in handling the different
pricing strategies used by the alternative suppliers.
A lot of sacrifices were also related to the management of the maintenance and support of the
component. For example, the Buyer company felt it was difficult to ensure the willingness of
the supplier to fix the identified bugs in the software component as soon as possible is ensured
through contract paragraphs. As the component was incorporated into the product in the
software development phase, it was important that the component operated as it was supposed
to operate, or otherwise the whole product development project could be delayed. The
suppliers needed to be made committed to the processes of the customer e.g. through using
royalties as a pricing strategy, so that it was in their interest to support the customer. Thus, the
Buyer company felt that one of the challenges in using software components was to manage
the component and the supplier relationship throughout the component’s life cycle, even
though the product development project originally needing it was finished.
Another important perspective besides the interface with the supplier that needed to be
managed well in relation to after-purchase issues was to organize the management of the
component internally. As the Buyer company also had other divisions in other locations that
were using the same component provided by the same supplier, some kind of co-ordination
needed to be organized inside the company. Also, the fact that the purchased components
could possibly be used in subsequent product development projects was an important factor
emphasizing the importance of internal management of the component. Also, in relation to the
new versions of the component, managing the new releases so that the needs of every project
using the component are taken into account was considered to be important.
In the following Table 2 we will present the summary of the analysis of the value benefits
perceived by the customer in the case of product business logic. We identified three main cost
benefits compared to alternative solutions, ensured technological quality and the way the
purchase was in accordance with the strategy of the company, meaning that they had decided
to pursue an increase in the component use. From the customer’s perspective, all of these
were rather easy to perceive and their complexity to the customer was not particularly high.
The sacrifices in the product business case, on the other hand, were rather numerous and
complex. Firstly, the evaluation and comparison of alternative solutions and components was
seen as difficult, contracting as well as pricing procedures were not established in the market
and they have severe difficulties in making the supplier committed to the co-operation due to
the product business logic. Finally, this resulted in huge difficulties in managing the lifecycle
of the component internally but also externally in terms of new versions and future
development.
Table 2. Identified value elements from the product business case
Benefits
Sacrifices
Value elements
Cost benefits compared
to alternative solutions
Technological quality
ensured
Accordance with
strategy
Evaluation &
comparison difficulties
Complexities in
contracting
Pricing mechanisms
not established
Committing the
supplier
Management of the
component life-cycle
Business logic and value perception
Complexity of the customer’s perception
Low – it was easy to estimate the needed
workforce for alternative own development.
Rather low – the other customers using the
same component were easily identifiable on
the basis of supplier’s reference marketing.
Low – increasing the use of component was a
clear strategic aim.
Rather high – technical evaluation typically
manageable but comparison between very
different types of solutions was difficult.
High – no standard procedures for contracting
internally (unclear roles between engineering
and legal staff) nor standard contract templates
available.
High – suppliers used various different pricing
strategies and customer had difficulties in
evaluating their impacts (e.g. fixed sum,
licensing, royalties etc.).
High – business logic based on idea of simple
interfaces and even arms-length relationships
but in practice long-term cooperation needed.
Rather High – no procedures for managing the
lifecycle of the component internally but also
externally in terms of new versions and future
development.
Next we will synthesize the findings from the two case studies in order to find out how the
business logic influences on the customer’s perception of value. To begin, it is clear that the
two business logics relevant in software business have an impact on the customer’s value
perception as illustrated in the two case analyses above. The identified value benefits from the
cases emerged from the data and thus they are strongly empirically driven. Also, similarities
of the elements between the two cases are difficult to identify. All in all, in the project
business case, it seems that the approach to the co-operation with the supplier is a very
holistic one in the sense that a lot of reliance is given to the supplier. Where as in the product
business case the relationship with the supplier seemed to be a lot more difficult. The
relationship fluctuates between the arms-length and cooperative forms and the parties’
perception of the cooperation seem to be differing.
In the project business case it seems that the identified sacrifices were manageable to the
customer. Even though there were some central sacrifices like the ambiguities in scheduling
the project and controlling the overall supplier and subcontractor network, these sacrifices
were still rather straightforward and in the end, easy to accept and adjust. However, in the
project business case the complexity of perceiving the benefits related to the project and the
relationship with the supplier was visible. The customer was waiting to have an easy solution
from the supplier in the form of a total system solution, but this aim did not realize in the end.
In fact, the customer had difficulties to identify any kind of benefits after the project and also,
from the overall relationship with the specific supplier. Furthermore, there were issues in the
relationship that the customer would have liked to have from the supplier and from the total
project delivery, but they were not able to articulate these wishes to the supplier. What is even
more surprising, the supplier and the system solution already included these kinds of benefits,
e.g. like a component level tracking ability, but they did not consider it as an important one
and thus did not market and offer the benefit for the customer. Thus, even though the
relationship between the customer and the supplier was characterized generally as “close”
relationship, it did not possess such features as trust and effective knowledge sharing, which
generally can be seen as essential parts of a close business relationship.
In the case of the product business there were a lot of even surprising sacrifices and problems
that the customer company faced. Concerning the benefits, however, these were rather easy
for the customer to perceive and they had a lot of importance in the overall value for the
customer. They had a clear idea that this form of cooperation with the software suppliers was
beneficial and had a huge amount of potential in the future. The perceived sacrifices, on the
other hand were clearly more challenging for the customer, although, as mentioned, the
importance of these did not overcome the perceived benefits. In fact, the list of problems
faced by the case company was very long as also illustrated in the number of identified
sacrifices in the product business case. In addition to being numerous, the sacrifices were also
of high complexity for the customer and required a lot of managerial attention to be solved.
For example, the committing the supplier to the cooperation was indeed a very tricky one,
since it originated from the underlying idea of the business logic: software exchanged as a
standard products thus minimizing the efforts needed in managing the relationship with the
supplier. Yet this did not realize oneself as various needs for closer cooperation emerged, e.g.
in terms of future development of the software. Other complex sacrifices related to
contracting and pricing for example, required intensive interaction between the counterparts.
On the basis of our analysis of the value elements and the comparison of the two cases, we
propose a following framework for understanding the way business logic influences on the
customer’s value perception in the software business (see Figure 1.). This framework
examines the complexities of the customers’ perceptions of the value elements in the two
different logics. The framework has two dimensions, one illustrating the complexity of
customers’ perception of the complexity of the benefits and another illustrating the perception
of the complexity of sacrifices. Here we define the complexity as being high in cases where
the customer experienced severe challenges in managing the issues involved in to the value
element. Low complexity refers here to perceptions of the elements that did not include major
development areas for the buyer company.
Figure 1. Software business logic and the complexity of customer’s value perception.
If we take a look at the perception of value benefits in project business case, we argue, that
these included a considerable level of complexity for the customer. The underlying idea of the
business logic was based on close and broad cooperation between the supplier and the
customer which in turn created difficulties in terms of perceiving the totality of it all.
Typically in these kinds of business relationships, a variety of different kinds of bonds, e.g.
social, economic or technical are created between the counterpart and these create
complexities if we consider how to perceive it all. Thus, we argue, that in software project
business, high complexity exists in terms of customer’s perception of value benefits. On the
other hand, concerning the value sacrifices in s o ftware project business, the identified
elements represented important yet not that troublesome issues for the company. In our case,
e.g. the schedule problems emerged as essential value sacrifices but it was clear to the
customer, that with a more careful planning these kinds of challenges could have been
overcome. Thus, we located the project business logic in the low end of the dimension of
complexity of the customer’s perception of value sacrifices.
In the product business case, the value benefits were rather easy to identify and not
considered any major managerial challenges for the case company. Therefore, we can place
the product business at the low end of the complexity of the value sacrifice continuum. On the
other hand, the value sacrifices presented major managerial problems for the customer
company and solving these required intensive interaction with the supplier (e.g. in terms of
pricing and contracting) but also internally between different units of the company (e.g. in
terms of legal department in pricing and contracting and globally different units in terms of
managing the component life-cycle). Therefore, we can place the software product business
logic to the high end of the second dimension concerning the complexity of the perception of
the sacrifices.
Conclusions
This paper has addressed the concept of perceived customer value in a specific empirical
context, the software business. We aimed to find out how customer perceived value can be
understood in the software business and how the business logic is intertwined with the
customer’s perception of value. With respect to the first part of the question, concerning the
understanding of the customer perceived value in the software business; we identified the
different value elements from the two cases. We argue those elements within these particular
cases enable us to examine the value perceived by the customer and that a supplier’s efforts in
developing marketing and relationship strategies could benefit from this understanding. Thus,
we argue, that in the software project business, customer perceived value includes benefits
related to acquiring a total system solution from a single supplier and that supplier having a
deeper understanding of and ability to support the customer’s overall value creation process.
Sacrifices include issues such as schedule problems and increasing the commitment to the
supplier.
The current study establishes that different value elements are highly context-dependent.
Thus, our results are in line with the existing research on customer perceived value in
different contexts, as it indeed seems that the industry context and the business logic does
have an impact on the value perception and the types of value benefits and sacrifices the
customers perceive. Our strategy in identifying the elements was empirically driven as we did
not use any theoretically predetermined classification but let the elements emerge rather freely
from the data. This of course further emphasized the context-dependency of multifaceted
values. However, the way our study involved one industry context (the software industry) but
two independent cases representing different business logics within the same industry brings
forth the importance of the context: value perceptions in these two cases clearly differed
despite the industry context being the same. This enabled us to draw the conclusion that
business logic does indeed have an impact on the value perception of the customer.
The second part of our research question dealt with the connection between the business logic
and the value perception and in that context we presented a two-dimensional framework
illustrating the level of complexity of the customer’s perception of sacrifices and benefits in
the two business logics studied. This leads to our conclusion that software business logics are
intertwined with the customer’s value perception through complexity of perception of the
value of benefits and sacrifices.
The framework does not of course fully explain the interconnection between the business
logic and value perception, but it illustrates in a simple way the way these two business logics
result in different types of value perceptions. The contribution of the framework in terms of
managerial relevance is connected to the management of multiple business logics or those
hybrid ones combining elements from project and product businesses. In terms of
understanding the customer and striving towards creating value for that customer the
framework illustrates the need to carefully consider the role and nature of the elements in the
two logics. A company aiming to move from the project business towards the product
business needs to understand the complexities of the value perception and alter its marketing
strategies and customer communication accordingly.
One of our key findings concerned the way business logic influences the value perception of
the customer in the software business. This suggests that in business logics combining the two
logics, the value perception of the customer has its distinct complexities. One of the avenues
of future research within this theme really should involve an examination of the hybrid modes
of software business logics and the value perceived by the customers within those contexts.
To evaluate the present study, we used the criteria for trustworthiness developed by Lincoln
and Cuba (1985). To increase the dependability of our study, we have carefully conducted our
research in a logical way and made our analysis process as traceable as possible.
Transferability has been generated through explaining the theoretical approaches we have
used. The presented results can be transferred to other high-technology industry contexts
where similar types of business logics exist. To enable transferability, we have also carefully
described the empirical context of the study and the two studied case companies. With respect
to ensuring the credibility, the present study employs our previously-acquired knowledge of
customer perceived value in business relationships. Moreover, we have collected the data so
that it acceptably represents the research phenomena of the value perceived by the buyer
companies. Finally, with respect to conformability, we have put effort into making the chain
of evidence visible in the analysis of the empirical data. The confirmability of the
interpretations was also improved by creating a study database. The database includes the
interview transcripts and research notes that retrace the development of the analysis over time.
References
Alajoutsijärvi K, Mannermaa K & Tikkanen H (1999). Customer relationships and the small
software firm. A framework for understanding obstacles faced in marketing. Information &
Management Vol. 37, No. 3, pp. 153-159
Berry, L & Yadav, M (1996) Capture and Communicate Value in the Pricing of Services.
Sloan Management Review (Summer), pp. 41-51.
Cusumano, M. 2004. The business of software: what every manager, programmer, and
entrepreneur must know to thrive and survive in good times and bad. New York. Free
Press. 344 p.
Eggert, A. and Ulaga, W. (2002), Customer perceived value: a substitute for satisfaction in
business markets?, Journal of Business & Industrial marketing, Vol. 17, No.2/3, pp. 107118.
Eggert, A., Ulaga, W. and Schultz, F. (2006), Value creation in the relationship life cycle: A
quasi-longitudinal analysis, Industrial Marketing Management, Vol. 35, No. 1, pp. 20-27.
Flint, D. J., Woodruff, R. B. and Gardial, F. S. (2002), Exploring the phenomenon of
customers’ desired value change in a business-to-business context, Journal of Marketing,
Vol. 66, No. 4, pp. 102-117.
Hoch D, Roeding C, Pukert G, Lindner S & Mueller, R (1999) Secrets of Software Success:
Management Insights from 100 Software Firms around the World. Harvard Business
School Press, Boston.
Komulainen, H., Mainela, T., Tähtinen J. and Ulkuniemi, P. (2008), Retailer’s different value
perceptions of mobile advertising service, International Journal of Service Industry
Management, Vol. 18, No. 4, pp. 368-393.
Kothandaraman, P & Wilson, D (2001) The Future of Competition: Value-Creating Networks.
Industrial Marketing Management Vol. 30, No. 4, pp. 379-389.
Lapierre, J (2000) Customer-Perceived Value in Industrial Contexts. Journal of Business &
Industrial Marketing Vol. 15, No. 2/3, pp. 122-140.
Lindgreen, A. Wynstra, F. (2005) Value in business markets: What do we know? Where are
we going? Industrial Marketing Management, Vol. 34, Iss. 7, pp. 732-748.
Messerschmitt, D & Szyperski, C (2003) Software Ecosystem. Understanding an
Indispensable Technology and Industry. The MIT Press, Cambridge, Massachusetts.
Morisio, M, Ezran, M & Tully, C (2002). Success and Failure Factors in Software Reuse.
IEEE Transactions on Software Engineering Vol. 28, No. 4, pp. 340-357.
Parolini, C (1999) The Value Net. A Tool for Competitive Strategy. John Wiley & Sons Ltd.
Ravald, A & Grönroos, C (1996) The Value Concept and Relationship Marketing. European
Journal of Marketing Vol. 30, No. 2, pp. 19-30.
Sallinen, S (2002) Development of Industrial Software Supplier Firms in the ICT Cluster. An
Analysis of Firm Types, Technological Change and Capability Development. Acta
Universitaties Ouluensis, Faculty of Economics and Industrial Management, University of
Oulu, Oulu.
Slater, S (1997) Developing a Customer Value-Based Theory of the Firm. Journal of the
Academy of Marketing Science Vol. 25, No. 2, pp. 162-167.
Thomas, S & Wilson, D (2003) Creating and Dividing Value in a Value Creating Network.
Work-in-progress paper, IMP 2003 conference.
Tähtinen, J (2001) The Dissolution Process of a Business Relationship. A Case Study from
Tailored Software Business. Acta Universitaties Ouluensis, Faculty of Economics and
Industrial Management, University of Oulu, Oulu.
Ulaga, W. (2003) Capturing value creation in business relationships: A customer perspective,
Industrial Marketing Management, Vol. 32, No. 8, pp. 677-93.
Walter, A, Ritter, T & Gemünden, H (2001) Value Creation in Buyer-Seller Relationships.
Industrial Marketing Management Vol.30, No. 4, pp. 365-377.