Previous by Date Index by Date
Threaded Index
Next by Date

Previous by Thread Next by Thread

Simultaneous User Pricing

Okay, let me further try to articulate my discomfort with simultaneous
user pricing and see if writing this down makes the discomfort seem
logical or illogical.  (I've not had this discussion out loud with more
than about one person, so the list can be a very helpful critique and
could disabuse me of the error of my ways!) 

I.  When no. of simultaneous user pricing model makes sense: 

Simultaneous user pricing makes sense (to me) when the electronic resource
is accessed remotely from a publisher or vendor.  In that case, the
deliverer must ramp up services to accommodate a certain kind of load on
his system.  The provider is there not only to sell an information product
but to deliver a service (access, at the least). In order to offer that
access the provider must have a good idea of how many folks might come
knocking at the door and be prepared to deliver.  If customers get poor
access and service, the producer and his product are not viable.  So, in
the remote-access-case, the producer might reasonably ask the customer to
pay based on anticipated maximum demand.  The customer in turn decides
what that might be; the provider will then, ideally, offer the customer
data that will allow the customer to fine-tune the numbers of simultaneous
users paid for.  The customer may choose to pay for as many simultaneous
users as desire the service, or may set an economic cap.

Note that not every provider of remote access asks for simultaneous user
pricing, by any means. 

II.  When simultaneous user pricing makes less sense (to me): 

When the product is delivered to our institution and we in turn serve it
up locally (through the "Intranet" if that is the right word here) or
through a CD-ROM network, then the cost of the delivery is borne by us. 
We have to worry about the wires, pipelines, storage, backup, user
support, and so on.  In this case, I fail to see why, simply because we
are investing more at our end to deliver a producer's product to a user,
we (the institutional subscriber) should be charged additional $$$ by the
provider.  The provider should charge for the product in that case, not
the access portion.

III.  My discomfort with the simultaneous user model is further increased
by the fact that with many systems and products, calculating how many
simultaneous users one needs is a total guess.  It is an art (to be kind
to it) and not a science.  While there are some systems -- and some
skilled individuals -- that provide good management information -- and
people who know how to interpret it -- it does seem to me that until we
know what our needs as producers and subscribers are, this model is as
full of holes as a swiss cheese.  Again, this is not true for all
electronic systems and products, but it is true (I believe) of the
majority of them.  Mind you, likely we will get better at it over time,
but that's in the future. 

Reactions? Corrections?

thanks, Ann Okerson
On the topic of simultaneous user prices, Keith Ostertag wrote: 

>I'm surprised, because I have generally felt that simultaneous users is a
>very good model. You can start small, then add licenses if need be, and
>not feel you are paying for a lot of access that is not being used. Of
>course it depends on how mission critical the service is; I think
>universities can afford a small amount of queueing for general research
>type databases (Proquest, IAC, Ebsco,etc). It also tends to promote
>better planning for port needs, bandwidth, etc.

>I agree that FTE's is a very bad model to use for pricing. Some of our
>campuses are still in the process of building adequate computer
>facilities, so many of our students would not be able to use the
>licenses. Many database products are used primarily by specific
>departments; why use the total campus FTE's to determine pricing for a
>product that will only be used by one department? The simultaneous use
>model takes care of these kinds of inequities by customizing the access
>according to anticipated use- which can easily be modified when needed. 
>Keith Ostertag, Network Applications Librarian
>Memorial Library, SUNY- Cortland
>607-753-2528		fax: 607-753-5669
© 1996, 1997 Yale University Library
Please read our Disclaimer
E-mail us with feedback