Browse Prior Art Database

Method of Tracking the Reason Mailpieces are Sent to a Presort Vendor in an ADF Environment

IP.com Disclosure Number: IPCOM000240962D
Publication Date: 2015-Mar-13
Document File: 2 page(s) / 197K

Publishing Venue

The IP.com Prior Art Database

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 2

Method of tracking the reason mailpieces are sent to a presort vendor in an ADF environment

Authors: Brent Winters, Adam Swartz, Ned Otey Date: 3/31/15

Within an Automated Document Factory (ADF) environment using Presort Accuracy, Validation, and Evaluation (PAVE) postal optimization and direct presentment of the mail, it is typical for a subset of the mail to continue to be sent to an external mail presort vendor. There are many reasons why this can happen. For example, the mail simply may not qualify for PAVE or the customer may feel they will pay less for certain mail (even though it qualifies for PAVE) to be sent to the presort vendor, to name just two. Given that there is significant volume of presort vendor mail and multiple reasons why mail is being processed in that manner as opposed to through the normal PAVE process, customers want to understand how much mail is still going to the presort vendor and the reasons why and to be able to create historical reports on this data.

In an ADF solution delivered in phases, new functionality may introduce new actions that result in mail being sent to the presort vendor. During development it may seem wise to track each potential new action separately and to simply analyze the actions to determine if they result in the mailpiece being sent to the presort vendor. But over time, this can become cumbersome and error prone leading to logic that might read: If action A = Yes and action B = No, then the reason is X, unless action C = Yes. This logic may need to exist in both processing logic and reports which may span multiple development platforms and thus cannot be common code. This leads to the undesirable effect of having the same logic in multiple places all of which need to give the same results in all cases and all of which need to be updated whenever the logic changes.

Given the problem of multiple actions that can lead to mailpieces being sent to a presort vendor and potential conflicts between those actions that make understanding how they interact difficult, a more reasonable solution is to define a single Presort Vendor...