Last month, I wrote an amusing email about not making assumptions. The topic was personal, so here is a short story about one that’s professional.

My tax receipt application for Canadian nonprofits requires the managed package called Salesforce Nonprofit Success Pack (NPSP). Among other customizations, the package installs two record types for accounts, called “Household” and “Organization”. It also creates an object called “Payment”, related to the opportunity.

When a potential client recently approached me, they used a managed package called “Patron Manager” (PM), and asked whether my app was compatible with it. In the sales call, they did a screen share, and sure enough, households, organizations, and payments were there. Cool.

So they signed the contract and made the first year’s payment. However, when it came time to actually install my app in their sandbox, I hit a wall. The installation process complained that NPSP wasn’t installed. A quick inspection of Setup > Managed Packages showed PM, but NPSP was nowhere to be found.

It seems PM replicates most of the functionality of NPSP, but they obviously are not the same.

I apologized to the client and took responsibility for the confusion. I proposed several alternatives and asked how I can refund their payment.

The takeaway
There are several lessons here:

  1. When something has hard requirements, double check it’s compatibility
  2. When you make a mistake, own it
  3. When your service/product isn’t a fit for a potential client, propose alternatives
  4. Listen to your own advice, lol
Category:
Salesforce