Recent Changes

Here in one compressed article is a list of recent changes. Some of these have merited their own independent post. Where that’s the case, you’ll see a link to that article. Otherwise, we’ll show a short explanation of the change.

Financial

On Queries => Financial Transactions, you can now enter a check number, check amount, or both. So, for example, if someone says, “I mailed in check 1234 for $85.00,” you’ll be able to quickly track whether you received and posted that check; and you’ll be able to tell at a glance the categories to which that money was applied.

On Queries => Financial Transactions, if you export data, you’ll see two changes:

  1. The export now contains the family’s formal name
  2. Debits (charges) and Credits (payments) appear in separate columns.

On Financial => Statements, the choice of which statements to print had been limited to either everyone, or any one specific family. The point of the “one specific family” was to handle the case where you may have reapplied a transaction, and wanted to produce an updated statement. Or, of course, if the family did not receive the original statement, and wanted a replacement. Now, as is the case with the directory, you can more finely select who will receive statements. You can select by billing status, and/or select by family attribute.

Membership communications

On Queries => Produce Directory, you can now select which families appear in the directory. You can select by billing status, by family attributes, or a combination. Also, if you mark the family with a special attribute named _EXCL, the program will exclude that household from the directory. Moreover, the Exclude attribute overrides all the other selection criteria.

When sending emails from Queries => Members, you now can choose from your own defined set of sender email addresses, in addition to your logged-in ID. Please see this blog post devoted to this topic.

The Turnaround Document offers the flexibility to either print it or email it. In early January 2019, we added the capability to print the Turnaround Document only for those families with no email address.

Yahrzeits

From Queries => Yahrzeits, you can now produce a formatted report, meant to provide lists of Yahrzeits read from the Bimah. Please see this blog post for details and report options.

In ShalomCloud, each Yahrzeit “notifee” can choose notification by Gregorian date, by Hebrew date, or none. Because of this, we show Yahrzeits by both sets of dates. However, if your congregation has all notifications set to Hebrew date (or none), the Gregorian portion will not appear.

Smarter Contribution Portal

Non-logged-in-portal
Non-logged-in portal

The contribution portal has added a smarter search for contributors who might be Temple members.

What do we mean by that?  First of all, if you watch the video about the non-logged-in portal,  you’ll have the background for this post.  Regardless, let’s squeeze an explanation into a few sentences.

The non-logged-in portal accepts payments and contributions without needing a login. Its biggest advantage–it can identify contributors who are Temple members.  That saves your admin the time of looking up contributors, and manually making entries.

Prior to this change, the portal did a look-up based on email address alone.  If it didn’t find the email address, it created a Family record.

With this change,  the portal tries a few other techniques to find the user.  We shan’t go into the details here.  Let it be known, though, that we’re using more fields entered into the contribution form–with the goal of doing better on finding known contributors.

One other point–suppose that, despite the “smarter” search, the system can’t find the giver, and creates a family record like Smith-1.  Later, you discover this was actually Smith, and you’d like to merge the Smith-1 activity into Smith.  There has been a screen to move that money in one fell swoop.  In addition, we’ve now added a check box to delete the Smith-1 record.

reassign payer
Reassign Payer

Bulk Billing

Our newest feature, Bulk Billing, comes into play when you want to create many receivable transactions, for the same amount, in the same category.

Probably the most typical example would be a pledge drive.  Let’s say you have a standard membership of $1000 and a Young Member rate of $300.  With ShalomCloud, you can designate memberships by billing status, by family attributes, or by some combination.  Then, using this feature, you can create pledges with just a few mouse clicks.

Or, let’s say you’re accepting orders for sets of Lulav and Etrog.  Accordingly, you could create a family attribute called, fittingly, “Ordered Lulav and Etrog.”  As the orders come in, you could simply assign that attribute to the respective families.  When the ordering period closes, you could use the Bulk Billing feature to create a receivable for each order, all at once.

Here’s a video (3m, 25s) that shows how this feature works.

ShalomCloud Bulk Billing from Norman Snyder on Vimeo.

Deposit Assistant

Until now, ShalomCloud offered three ways to record funds–checks, cash, and credit cards entered into ShalomCloud.

With this enhancement, you’ll be able to enter other sources of income.  For example, you may have PayPal transactions; you may have card activity coming in from sources other than ShalomCloud.

Whether or not you use the new “other” sources of income, you’ll be able to take advantage of a new report, expressly formatted for printing–the Deposit Assistant.

 

deposit report

Here is a video that shows the entire end-to-end process.

There are two pieces to this enhancement.  First–under the Configuration menu, you can designate your various sources of income.  Cash, check, and credit cards done via ShalomCloud are automatically included.  Then, as you enter financial activity into the system, you can pull down any of those sources of income, type in a reference number, and enter the amount.

Second–at a time of your choosing, go into Financial -> Deposit Assistant and enter a date range.  You’ll immediately see all the activity in the date range, broken down by category, with subtotals by category and by source of funds.  At the end, there will be a grand total.

Last–you can print, or save to PDF, this deposit report.

 

Export Chart Data

NEW — you can now export chart data to CSV or Excel–or display the underlying data right on the page!

(see blue highlighted area in the screen shot)

 

Revenue by Category
Revenue by Category, with options to export

In case you haven’t seen our application, let’s list the available charts:

  • Families by year
    • Joined by year (this is the number of households who joined the congregation, year by year)
    • Joined minus resigned by year (which gives you a net membership count, by year)
  • Families by Zip (bar graph, showing number of households by zip, with hyperlinks to those households).
  • Pledges by Year (stacked bar graph, interactively showing pledged and paid, by year)
  • Revenue by Category (pictured above)
  • Pledged-Paid Gap (line graph, going back several years, showing the cumulative difference between pledged amounts and paid amounts).

For each chart, there is a little symbol toward the upper right that lets you export the chart to PDF, JPG, PNG, or just print it directly.

With this change, that same symbol allows you to export the data that goes into making the chart, into a spreadsheet-compatible format.

 

Better Queries

We have three improvements in which you might be interested, with a six-minute video that runs through all three:

Queries with ‘NOT’; bulk status changes.

  • Bulk change of family status:  when you run a family/household query, you will now see a button on the bottom left of the screen.  That button enables you to change the status of any families that you check.  For example, you might query for all families with attribute “moved away.”  From there, in one step, you could change all of those families to a status of “Inactive.”
  • On family/household queries, you can now pull lists of families who do not have a certain attribute.  There is one example in the video above.  Here’s another example–suppose you want to do a paper mailing, appealing to raise funds for a new roof.  You maintain an attribute called “Founding Families,” to whom you might make a personal appeal.  You would want to exclude from that query the Founding Families, so as not to send them the general appeal communication.
  • Likewise on individual member queries. There is a good example in the video, namely pulling a list of ladies in your congregation who are not in the Sisterhood.

 

 

Track Contributions–Automatically

Now available–accepting and tracking Internet contributions:

ShalomCloud Handling of Contributions from Norman Snyder on Vimeo.

  • Automatically stores information about the contributor–no need to download spreadsheets or copy and paste from emails.
  • Automatically enters financial activity into the system–no need to manually key the entries after the fact.
  • Offers the the option of including card processing fees.

Expanded capabilities on acknowledgment letters

ShalomCloud has, from the outset, provided the ability for the congregation to create letter templates, used primarily when acknowledging donations and sending Yahrzeit notifications.  Moreover, the software exposes a letter preview for each contribution letter, which the office can use to override the letter template for that specific missive.

However, until now the letter heading has been fixed per congregation.  With today’s release, both the letter template and the letter preview allow control of the following:

  • The heading text itself, including line breaks
  • Bold lettering anywhere in the heading–by line, by phrase, by word–even by individual character(s).
  • Italics anywhere in the heading–by line, by phrase, by word–even by individual character.
  • Font size–varying anywhere in the heading.
  • Option to center the heading or place it on the left margin.

In addition, several different fonts are now available for the entire letter.

Multi-donations on one letter

For some time, ShalomCloud Synagogue Management Software has been able to produce acknowledgment letters for contributions–not only to the contributor, but also to any congregation members whom the contributor wishes to let know.  For example, if Allen Abelson contributes $18 to the General Fund in honor of the birthday of Sam Silverstein, Mr. Abelson would typically like for Mr. Silverstein to be notified about the contribution.

However, there’s been a less-than-optimal facet of this process: namely that, if a payment included contributions to several different funds, the contributor would receive a separate letter for each granular contribution.

The enhancement implemented on 7/9/2017 groups such line items into one letter to the contributor.  Letters to “Notifees” remain as they were.

Recurring Payments Capability Added

We have broadened our payments function to include recurring payments.  There are some rather sophisticated ideas implemented herein:

  1. Validates the card information immediately
  2. Shows you all the unpaid items for a selected family
  3. Drag and drop(!) the order in which you’d like to pay the outstanding items (thus establishing a waterfall).
  4. Select a payment frequency and amount
  5. Optionally declare a maximum number of payments.

From there, the magic unfolds.  As each payment date arrives, the card is charged, of course.  Then, the payment is automatically applied to the outstanding items that you specified in step 3 above.

The system applies periodic payments until either (a) the maximum number of payments is reached, or (b) all outstanding items declared in the waterfall reach a $0 balance.  At that point, the program applies any remaining monies to credit on file, and sends an email to your office personnel to cancel the recurring payment.

As a synagogue back office, you would accomplish all of the above within ShalomCloud.  The actual card activity occurs within Stripe , but ShalomCloud handles the “conversation” with Stripe.

Many systems offer a recurring payment feature–however, you would typically find yourself making decisions on each individual payment as it arrives (“Here’s $100–let me look over the ledger–hmm, what should I apply it to??”).  Not the case here–when you set up the recurring payment, you’d make those decisions during setup.  The activity flows automatically from there.

If we’ve piqued your interest in this capability, please consider subscribing to this blog, by entering your email into the area at the top of the beige-colored box.