TBYB is not a new type of soft serve yogurt. Instead “Try Before You Buy,” or TBYB seems
to be one of the current fads in the treasury software sales process. TBYB in treasury software is currently specific
to the genre of software known as ASP (Application Software Provider) or SaaS (Software
as a Service), software with which the client uses a web-based application to
manage a treasury function. In an ASP environment,
user data and other tools are housed, maintained, upgraded and managed by the software
provider usually, for a monthly or annual fee.
In treasury workstation software, an ASP has been typically targeted at
the client, with a low to moderate degree of treasury complexity, needing a
product that primarily operates along the lines of Cash Management. The ASP
world is changing, however, with some vendors offering additional modules such
as debt, investment, bank account management, and reconciliation, with most of
the major vendors adding services or modules rapidly. As modules keep being added, the competition continues
to heat up.
As a result of the perceived similarity in services the
marketing teams of the TWS providers have been working on a way to court
clients and show distinction, leading to the introduction of TBYB. So far TBYB has been limited to the ASP
offerings has not been used with any installed or enterprise type systems.
So what’s good about TBYB?
TBYB as a sales tool has historically worked well with certain types of
software that are somewhat intuitive, well documented, and simple. The pitch generally goes like this: “Try it free for 30 days, and if you like it,
call us, and we can arrange for the full product.” TBYB has seemed to work well with simple,
easily configured and intuitive software across the data spectrum from Adobe
Acrobat to WinZip and just about every app that you can add to your phone or
PDA. The question is, “Will this work
for Treasury-oriented software that is typically not simple, quickly configured
or intuitive?”
This marketing tool may help some agile software vendors
attract targets at the lower end of the complexity spectrum. A prospect with little complexity in business
structure, with one or two main bank relationships, and with simple viewing or
reporting desires may be able to quickly configure and test the product using
downloadable bank prior day files. The
rationale is that this method demonstrates the product’s ease of use, intuitive
interface (or lack of the same), and the ability to implement a solution
quickly. It also is an easy way to
demonstrate the productivity tools, standard reports and capabilities of the
product without excess time spent customizing a demo or answering a RFP.
However, there are some pitfalls both for the potential
client as well as for the vendor.
Pitfalls for the prospective client:
To the client trying this TBYB approach, there are at least
3 major pitfalls: sunk costs, implementation
without information, and unintentional decision making.
1. Sunk Costs. Any treasury system takes some time to
configure - even if it is just a basic mapping of the bank account to the
correct BAI file account number (where things like leading zeros cause
problems). This time, once spent, is
sunk. A natural aversion to doing all
the work two or three times will cause most folks just to accept the product,
even if it doesn’t meet all the requirements.
Who wants to do all the grunt work all over again?
2. Implementation without information. Often there is a lack of clear understanding
during the implementation process of the implications of decisions made in
account, corporate or accounting structures that may impact later reporting,
display or later functionality of the software.
Without the aid of the professional services group, it may be easy to
create a potential problem. Examples of
this type of problem could be issues with company structure and its impact on
reporting, cash codes or general ledger mapping etc.
3. Unintentional decision making. The client has adopted software solely on the
basis of the free trial (and has unnecessarily limited the field) possibility
due to a lack of an intentional decision making process (needs, requirements,
capabilities and references). Realistically,
how many products can a corporate treasury practitioner test drive at one
time? If a corporation is in the market
for software, they most likely won’t be able to work on the setup of more than
one or two systems at a time, due largely to their own availability and
resource bandwidth. They will unintentionally
limit the field to the couple of products they are able to try.
The next post will cover pitfalls for Vendor.
Comments