What functions are involved in the ASP or SaaS model for microfinance IS/CBS?

We are looking into the different pieces of the value chain for delivering information and core banking systems through an application service provider (ASP) OR software as a service (SaaS) model. These functions may be performed by a microfinance institution (MFI), a national or regional microfinance association (MFI-A), a local IT service provider (ITSP), the ASP or SaaS vendor (Vendor), or another, new party.

ASP or SaaS models would seem particularly likely to fall short of customer expectations when it comes to support functions. One reason that MFIs are so dissatisfied with existing microfinance software vendors is that they provide poor quality support after the sale – and in particular that most of these vendors do not have local support providers in the countries in which their MFI customers operate. For example, a vendor from Ecuador may have customers in Peru but no on-the-ground support staff in that country.

When we talk of ASP or SaaS models, there is even less personal interaction between supplier and MFI consumer. Software and servicing post-implementation is touted as being completely remote. To ensure that ASP and SaaS vendors aren’t painted with the same brush as traditional MFI software suppliers, these vendors must pay particular attention to the customer experience post-sale. Support functions, as well as other critical “soft” pieces of the value-chain are asterisked for emphasis. These pieces seem relatively more likely to influence whether an MFI will sign up for the service and how satisfied with the service it will be post sign-up.

In most cases the functions above can be matched easily with one or another actor’s competencies or potential capabilities. But for several functions, none of the actors on the scene seem best positioned to assume responsibility. In general, these functions require a combination of technical and microfinance abilities that typically neither a vendor nor microfinance association possesses. Most functions in this category relate to offering the service to the MFI community – they include the design of packages, the “onboarding” of an MFI onto the service platform, and perhaps most importantly, the handling of responses to MFIs who request bug fixes or adaptations to the service.