⇓ More from ICTworks

Why Our Cash Catalog Was A Failure

By Guest Writer on November 30, 2017

Cash Catalog Failure

The Electronic Cash Transfer Learning Action Network (ELAN) works to improve the effectiveness and impact of digital payments in humanitarian response. Within this remit, we’ve hosted trade fairs where financial service providers showcased their products for humanitarian clients.

At these trade fairs, humanitarian attendees appreciated the opportunity to learn about available digital financial services, and financial service providers enjoyed showcasing their solutions and connecting with potential clients. ELAN members emphasized that no such ongoing forum existed and encouraged us to facilitate additional opportunities.

Others had already tried to meet this need, including NetHope’s Solutions Center Products and Services comparison tool, USAID’s Global Innovation Exchange, and CaLP’s cash tenders forum. All of these platforms have larger or slightly different scopes than what the ELAN was attempting to facilitate. The NetHope and USAID tools did not make it easy to filter to find technology suitable for cash transfer programming.

If We Build It, They Will Come

So we jumped in! We began by hosting an informal, online discussion to explore the concept of a catalog, and what it should and should not include. The catalog’s goal was to facilitate new connections between humanitarians and financial service providers.

Please RSVP Now to Hear More Fail Stories at Fail Festival

Armed with basic parameters – and with support from Oxfam and a human-centered design firm – the ELAN hosted open-invitation requirements workshops in Washington, D.C. and London. The events allowed us to collect user requirements for different personas, including:

  • Field-based NGO program staff.
  • HQ- based NGO program staff.
  • Field and HQ NGO operations/procurement staff.
  • Service provider staff.
  • Donors and researchers.

Based on the workshop requirements, the design firm proposed components of a minimum viable solution (MVS), along with basic wireframes. At this point, the design resembled a simplified dating site: using a set of filters, humanitarian users could search for FSP products to arrive at a suitable match or matches.

Armed with some “hits,” they could follow up directly with providers or invite providers to a tender process. The site listed provider contact information, but not price information since financial service providers use different pricing models.

Next, Oxfam and the ELAN worked with web designers to build out the wireframes and then a fully-functional website. In this stage, we also chose which specific filter criteria would be used and how they would work.

With a beta version of the website, the ELAN reached out to about a dozen known providers (via emails, calls and at workshops) to input their product information and provide feedback on challenges with the registration process.

But They Did Not Come.

Four providers created accounts and provided product information. Based on this feedback, we simplified a few steps of the provider registration process. Our web designers also created a screencast example that showed how to register a product.

For user testing with humanitarians, we needed enough products in the catalog to test the filter mechanisms, so we emailed over 200 financial service providers to encourage them to register. After receiving little response, we also offered to directly input financial service providers’ product information. (We had initially wanted to avoid this given concerns about accuracy and catalog sustainability). Despite these outreach efforts, over several months, no additional providers registered their products.

As a final attempt to encourage use, the ELAN rolled out the Cash Catalog in a single market (Uganda) to test viability with a more limited set of users. The hope was to get all providers in the country to list their products, since Uganda’s Cash Working Group members confirmed they also had difficulty locating potential providers.

Yet despite emails and outreach to several providers during an active humanitarian response (when, presumably, business contacts were being made), no providers in Uganda registered their product information.

What Went Wrong?

  1. FSP Needs Underexplored – The design sessions emphasized humanitarian users’ needs. When they did engage financial service provider representatives, participants were users who were already familiar with humanitarian clients. In hindsight, we missed an opportunity to engage financial service provider representatives who were skeptical: skeptical about the tool, skeptical about humanitarians as a viable client group who may have pushed us to better define our value proposition for providers.
  2. Inconsistent roll-out and messaging; competing priorities – The roll-out and messaging around the tool was slow, because we wanted to iterate before releasing a final version of the Cash Catalog. However, testing and broader roll-out was stymied by lack of provider and product entries. In addition, other ELAN commitments limited concentration on this product roll out.
  3. Lack of standard terminology; rapidly changing technology – The technology used in cash transfer programs has changed rapidly over the last several years. The ELAN has worked to standardize some of the terminology used by financial service providers and humanitarian clients, but the filters in the catalog still may not have been universally understood by users. In addition, humanitarian users still have trouble identifying the key technology features required for their program, limiting their ability to use the catalog to filter for suitable matches. Both of these factors relate to the current state of the industry but may change in the future.
  4. More filters than matches – The total number of providers who have recently engaged with humanitarian programs is still relatively small (between 50-100 globally). When you look at a particular program location – a likely search filter for a humanitarian user – that number decreases even further (often to fewer than 10). Further filtering from this small number of options may but more restricting than helpful.
  5. Comparing with physical cash providers – Humanitarian users are often looking for a snapshot of the available financial service providers in their project area, whether electronic or not. The catalog was limited to digital delivery mechanisms and therefore did not necessarily meet this need.

What We Learned & What’s Next

Without sufficient buy-in from a wide range of providers, the Cash Catalog could never grow to be a robust, online marketplace. While a variety of ELAN process choices likely contributed to this failure, our effort was one in series of responses to this on-going challenge.

Any future solutions should carefully consider how to engage all potential users early on in their design process and emphasize the roll-out process and relevant incentives.

Since humanitarian struggle to locate appropriate and available providers, the ELAN is still working on this issue. We’ve refocused to look at the tools humanitarians use to identify and evaluate potential financial service providers. This model places the onus of action on the humanitarian staff person seeking an immediate solution, instead of on the financial service provider, whose customer acquisition priorities may vary.

The forthcoming Delivery Guide will also help humanitarians compare non-digital cash transfer options with electronic delivery mechanisms.

By Bree Oswill and Lily Frey and original published as Failure Brief: Cash Catalog

Filed Under: Finance
More About: , , , ,

Written by
This Guest Post is an ICTworks community knowledge-sharing effort. We actively solicit original content and search for and re-publish quality ICT-related posts we find online. Please suggest a post (even your own) to add to our collective insight.
Stay Current with ICTworksGet Regular Updates via Email

3 Comments to “Why Our Cash Catalog Was A Failure”

  1. Excellent article!! I shared this with my team already as it highlights some things we have seen as well in development of systems (especially the overfiltering of data and generating taxonomies from perceptions of data vs actual data).

    A couple of things, though, that the article didn’t address or implied that would be interesting to talk about:

    1. how the lack of focus on financial and data sustainability contributed to the lack of focus on financial service providers – the catalog could have been pitched as a sales and marketing tool to the FSPs, both potentially generating funding sources as well as building their incentives to provide up to date content. But without FSPs seeing the catalog as benefiting their bottom line, the catalog cannot function. And without the data from the FSPs, there is no MVP.

    2. The order of prioritization on user needs for the platform and not on collecting, managing, and curating the actual data, is a common weakness in literal user-centered design. The fact is, the team had a product it wanted to sell to users – i.e. a brokering /aggregation of data – but it focused overly on user experience with the platform and not enough on the data the catalog was “selling” to the users. The MVP in this case should have been defined as not the system to collect the data, but rather the *actual data*.

    This fact underscores something that I among others have been repeating in the ICT4D space – SEPARATE PLATFORM FROM DATA. Data has value. Platform is a means to get, store, manage, collect, access and use data. Platform is a means to an end. The end is DATA.

    Thanks again for an excellent article and I hope to continue the conversation.

    • Bree Oswill says:

      Siobhan,

      Thanks for responding and so glad to hear that our story was useful. On your first point: We did see this as a potential marketing tool for FSPs, but maybe underestimated the investment it would take on our end to convince them of that. We also realized that we’re only a small portion of their total target market. FSPs absolutely needed to see the Catalog as helping their bottom line, but we never got enough companies to participate to fully demonstrate its value. Bit of a chicken-and-egg there…

  2. Dear authors,
    Very interesting (and honest!) piece. We are facing on some aspects similar challenges with our NOMAD project comparing Mobile Data Collection tools: https://humanitarian-nomad.org/
    The project have been running for some years, we managed to get most of the major providers to fill in information directly in the tool initially, and periodically receive applications from new tools. However we face challenges in the follow up: we struggle to have providers update information about their tools (hence we know our database is partly outdated unfortunately), and to curate the contents posted by existing providers.
    For us the challenge is therefore more on finding time (i.e. funding actually, since NOMAD is implemented by 2 light tech NGOs, CartONG and iMMAP with limited own funds) to keep the platform living than really getting interest from actors (we also manage to organize quite successful events on the topic when funding allow it). We tried to extend part of these responsibilities to members of our communities but didn’t manage (again, for lack of time first, both from the coordinators and participants).
    So the challenge we see is more on finding a business model to cover the costs (limited but existing) inherent to maintaining such a platform. It is directly connected to the challenge of funding “general interest” Humanitarian2Humanitarian permanent information tools like these outside of a time-bound project or research grant.
    Happy to discuss it if you’re interested!
    Martin for the CartONG / NOMAD team