Managing your Volunteer Score Board with MOW Scheduler

Our new and improved “Job Settings” page makes it super easy to update the miles and hours that volunteers contribute on each job.

Most of the time you probably don’t even notice that MOWscheduler is quietly keeping volunteer score for you: who drove which route on what day, and the mileage and time they spent doing that. When those numbers are needed, whether tax season, PR or grant-writing time, they are right there with a few simple clicks on the “Volunteer Credits” page.

Occasionally though, work is needed when clients are added, deleted, and/or reshuffled from one route to another. That’s when estimated shift duration and distance required to deliver the impacted routes need to be reviewed and adjusted to keep the records accurate. To make that work as easy as possible, we recently redesigned the “job settings” page.

Screenshot: Job Settings Page

Volunteer resource requirements such as miles and hours, plus volunteer head counts and the weekdays applicable to each job, can all be reviewed and adjusted in one intuitive and productive environment.

Finding a Substitute Driver with MOW Scheduler

Our “Advanced Search” tab makes it easier to find a substitute driver for a route.

Figuring out where to start when looking for someone to substitute for a route isn’t always simple. Determining which volunteers are likely to “step up” can depend on a number of factors that may be hard to remember, especially in a rush. There are several tools in MOW Scheduler to help you with that.

Screenshot of Advanced Search

For example, some routes may be tricky to navigate, so volunteers who have driven the same route before might be the best candidates. Or, possibly a pool of “regular substitutes” is the place to start. MOW Scheduler keeps track of the factors that may be most useful to you, and puts that information right where you might need it.

So next time when you need to fill an open route, the “Advanced Search” tab is here to help.

MOW Scheduler New Feature: “Service Anniversary”

The Volunteer Coordinator’s dashboard now includes a widget for “Upcoming Anniversaries”. This new widget, and alongside its older sibling the “Upcoming Birthdays” widget, prepares the coordinator to greet and congratulate his/her volunteers every week.

This new feature was suggested by our users at @MOWDurham. We liked it, so we did it. Thanks for the suggestion!

MOW Scheduler Feature Update: “Available Shifts” Public Page

The “Available Shifts” page in the MOW Scheduler is a public page that can be linked from your social media or email requests for volunteers to help in filling “open routes”. The Available Shifts page shows current route and other job openings, and is continuously and automatically updated as openings occur and are filled in the system.

New feature: Volunteers can respond by phone, text, or email, but previously we allowed only one email address to be used for receiving volunteer responses. Thanks to a suggestion by our users at Senior Connections in Atlanta (@SrConnections), you can now list multiple emails so that several people can be “keeping an eye” on volunteer responses at the same time.

MOW Scheduler Feature Update: A Slicker “Ongoing Assignments”

At Meals on Wheels, we rely on many volunteers who come in regularly to drive a route or pack meals. Even though they are “regulars”, they often have very different schedules. Mary may drive route 3 every 2nd and 4th Wednesdays, while Bob drives route 10 only on 1st and 3rd Tuesdays. MOW Scheduler’s “Ongoing Assignments” feature, which stores different types of recurring schedules and uses them to automatically populate the job calendar, has been a major time-saver for the volunteer coordinators.

The following additional improvements to this feature were introduced recently:

1. Multiple weeks of the month can be added (or cancelled) in one action.
2. An existing schedule can now be simply modified without having to vacate and start over.

MOW Scheduler – State of the Union

Our MOW Scheduler product was officially launched about 8 months ago (although we’d been in production use at beta sites for over a year at that point), and since then we’ve been busy! A few highlights:

  • focus on usability: we’re constantly striving to make the every day tasks as simple as possible (but no simpler!), and the complicated stuff doable.
  • new features, including “monthly” ongoing assignments, job groups, performance reports, etc.
  • easier setup, improved administration tools for adding new routes, importing volunteer data, etc.
  • new users: in our first few months we’ve helped a number of customers successfully implement the Scheduler, and received a lot of valuable feedback in the process.
  • conferences: it was great to meet so many motivated people at the national MoW conference in Nashville and the NY state conference. It’s nice to be able to put a face to the names, and our “early adopter” customers have become our most enthusiastic supporters.

What’s next for MOW Scheduler? 

  • more features… what do you want to see?
  • continuous improvement in performance and usability
  • we’ll be at the national MoW conference again this year, plan to stop by our booth in Denver

MOW Scheduler is a web application that helps Meals on Wheels and similar home meal delivery nonprofit organizations schedule their routes and other recurring volunteer commitments. Visit the website at — then contact Cha through the form on the site, or by phone (315) 234-0079 x301 to talk about your needs or to schedule a demo.

Acquiring Technology for the Channel: A Quick Checklist

We all know (or have heard) that technology can solve many of the challenges facing the channel. But how do we capitalize on the opportunity? A good first step is to identify where problems and opportunities lie in the first place, and uncovering problems turns out to be one thing technology can be good for. We discussed that in an earlier article: “Solving problems or finding problems, what’s more important?“.

Once we have determined the areas that need improvement, how do we implement the best technology solution for the problems? Here are a few quick suggestions to consider:

  1. Don’t try to use technology to mimic your current business process exactly. Some parts of your process may be based on ideas that have become outdated over time, and are now ready for the recycling bin. Time may be right for some process re-engineering. Be opportunistic, and don’t accept “we’ve always done it that way” as sufficient rationale.
  2. Automation is good. Controlled automation is better. Make sure the control knobs are there when you need them and choose the right ones based on your business needs.
  3. Design/choose your solution with views from both sides of the channel. Remember many of your partners do business with multiple vendors. What looks like a complete streamlining of business interaction from the vendor perspective, can often have limited or even negative impact on the partner’s lifestyle.
  4. Before you decide that you have to build something because nothing you find in the marketplace does exactly what you want, think some more about (1).


Solving Problems or Finding Problems, What’s More Important?

We’ve all heard about how business process automation can increase channel revenue and customer loyalty, and reduce support headaches.But will automation really work for us? If you are running a thriving business, you probably already have a process that works. Why and where does it need improvement?What parts of the business can be automated, and more importantly what parts should be automated?

The right answer usually comes from both business intuition and factual data. Take sales leads management as an example, managers usually know in their gut when marketing activities are not making a real difference in sales.  However the reason for that is often not as intuitive. Are qualified leads too few and far in-between? Are they getting to the hands of the right people too late? Were they sent to the wrong people? Were they followed-up promptly? Getting feedback from the channel on these questions can be a challenge because of the size and diversity of your channel, and the simple fact that everyone’s busy. Can automation help us find the right problems first?

The answer is yes. We are so used to thinking about automation as a problem-solving tool, sometimes we overlook its ability to identify problems that require attention at the first place. Back to managing sales leads as an example, we can:

  • automate the process of collecting sales leads so that leads from all sources are cataloged and accounted for in one place.
  • automatically track where leads are sent and systematically follow up to get status updates.
  • use automation to make it as easy as possible for our distributions to provide feedback, and automate the way inputs are tallied to produce insightful and instant metrics

Consider this when you plan your process automation projects:  First make your business process transparent. Better visibility will lead to intelligent and faster improvements.

Announcing ChannelSUITE 7

Purplewire is proud to announce channelSUITE 7, featuring an all new user interface that’s easier to use, faster, more consistent, mobile-device-friendly, and better looking.

Usability Improvements
  • Fresh look and feel – the new theme is modern and easy on the eyes

    Partner Contact list

    Partner Contact list

  • More consistent interface across the various channelSUITE modules (channelADMIN, channelLEADS, and channelFUNDS)
  • Responsive design – the interface layout adapts to use available screen space effectively for optimum user productivity across the array of modern Internet devices (desktops, laptops, tablets, and phones)
  • Better performance, due to extensive update of client-side code
Technical Details
  • The new interface uses the popular Bootstrap toolkit and the LESS CSS language. Benefits include increased consistency and maintainability of client-side code, and more consistent behavior across different browsers and devices
  • Client-side code has been extensively refactored. The previous versions spanned many UI and javascript frameworks. Now, all client code uses Bootstrap with JQuery for javascript
  • The interface theme is easily customizable to meet specific requirements of client installations
channelLEADS Lead list

channelLEADS Lead list

We’re excited to use this new foundation to bring you more new and exciting features in the future.

Sign up for a web demo today to check it out!

screenshot of Partner list

Partner list

The Problem with Old Code

We’ve been thinking lately about the pros and cons of updating some older B2B client sites that have been chugging away successfully for years.

If it ain’t broke, don’t fix it”

Although there is obviously something to be said for that old adage, it doesn’t apply well to web software. On the surface, there may be little motivation to invest in updating old software as long as it’s still getting the job done. The current system has been battle tested, users are familiar with it, and most of the worst kinks have been found and fixed.

But there are real costs and risks associated with failing to update old software. Some are visible, some are hidden.

Visible Costs and Risks:

  • usability: older web software typically doesn’t adequately leverage client-side technologies that increase usability and user efficiency. Most older interface designs would benefit from various techniques and technologies, including:
    • increased use of client side interaction via javascript and AJAX to allow for relevant dynamic information to be displayed in the context of the user’s workflow, with fewer clicks between related pages and fewer complete page redraws.
    • consistent approaches to layout and interface features, aided by tools such as standard javascript UI libraries and Bootstrap, reduce user learning curve and increase cross-browser compatibility.
    • better adherence to REST principles to allow for better addressability of specific resources, easier collaboration between co-workers (for example, emailing links to specific warranty claim details), more reliable use of browser history, bookmarks, and the “back” button.
    • layout optimized for higher resolution displays, preferably utilizing a “responsive” design that is optimized for today’s typical sized monitors while adjusting gracefully to smaller devices such as netbooks, mobile phones, and tablets.
  • brand image: it’s usually obvious to users when a website or application interface looks “old”. Depending on the nature of your relationship to your users, this may send a bad message that you don’t care about the users’ needs, don’t care about the process the software supports, aren’t up on technology, etc.
  • performance: old web software often has relatively poor response time. Users today usually have fast Internet connections, and have higher expectations on web response time than in the past. A latency of 2 seconds at the server wasn’t much when it took 7 seconds to transfer the content, but as the content transfer becomes closer to instantaneous, the server response time becomes more of a noticeable bottleneck. For this reason, new development projects use modern web frameworks with performance features like memory-resident application code, template caching, and shared persistant database connection pools to greatly improve the time needed to service requests on the server side.

Hidden Costs and Risks:

  • testability: the industry has made great improvements in the software development process since the early days of web apps. New web apps are typically developed using an MVC (or similar) design pattern, with object oriented design and a solid suite of automated “unit tests” for the data model. Older software which was developed with a more procedural approach and mixed control logic and data access is inherently more difficult to test, and as a result old code is dramatically more prone to develop hidden “regression” bugs resulting from minor changes to application code or operating environment.
  • support skill set: as developers move on to newer (and better) development methodologies, patterns, and habits, the tech team’s facility with the older style code tends to fade over time. Add to this a certain amount of turnover in a software organization, and it’s not too surprising that older code starts to look very unfamiliar to the current support team.
  • platform dependencies: most software has numerous obvious or hidden dependencies on third-party application libraries, operating systems, and server software (e.g. database or http servers). Over time the versions of these dependencies originally used during development and deployment inevitably become obsolete and unsupported. This problem eventually becomes evident when trying to move the older code to a newer production platform, and the application code doesn’t work correctly with the new version of the dependencies (and the old versions are either no longer available or have serious security flaws).

It’s often tempting to downplay the hidden risks. However, investments in testability and maintainability can reduce the risk of major problems down the road.

A Word About Browser Support

It should be noted that updating client-side code to better service users with relatively current browsers will cause new compatibility problems for any users with very old browsers. Therefore, prior to any modernization project a baseline for browser support should be established on 2 levels:

  • the minimum browser versions required to be able to use all site features
  • the level of support offered to users with browsers older than that

Browser support isn’t as big an issue as it used to be, for several reasons:

  • the big web players (google, facebook, etc.) require relatively recent browsers and this motivates users to upgrade
  • Microsoft has been aggressively upgrading IE versions via the windows update mechanism, because they don’t like supporting older browsers (for security and other reasons)
  • popular client side libraries (Bootstrap, jQuery, etc.) do a pretty good job of “papering over” browser incompatibilities so the developer doesn’t need to worry about them

A reasonable strategy is to officially support only those browsers supported in the current stable release of Boostrap (currently IE7+, Firefox 5+, Safari 5+, Chrome 14+). IE7 has been out for 7 years now, and older versions of IE are very problematic from both capability and security perspectives. As a point of reference, Facebook requires IE8+ and Google supports only IE9+ (and equivalent generations of Firefox, etc.)

As of this writing, conventional wisdom is that users should be expected to have javascript and cookies enabled, but should not be expected to have extra client-side technologies such as ActiveX, Java, Flash or Silverlight.