@Post Functional Requirements
Supplement to the United States of America Pending Patent Application Number 09/113,344, Group Art Unit 2751 Preliminary Class: 711
© Copyright: Ben Livson 1999. All rights reserved. Confidential.
Version 12, October 1999.
TOC \o "1-2" \h \z @Post Functional Requirements
1.2. Other Unified Messaging Types
1.3. Subscriber Attributes and Preferences
3.4. Overseas Postal Address Validation
3.5. Subscriber Send Confirmation
4.1. Support of Unified Messaging Types
4.7. Line Control for Envelope Printing
4.9. List Server Functionality
5. Usage and Billing Inquiries
5.1. Usage and Billing Information
7.1. Shop Front for potential customers
7.7. Seals for E-Trust and Web-Trust
7.8. E-commerce site in particular for add-on services
7.9. Advertising and Commercial Links Front
7.11. Free portal attraction services
8. Robotized @Post Email Services
8.1. Usage and bill presentment
8.3. Response to message-id.action@post
8.6. Advertising (no unsolicited bulk advertising)
9. Interface Requirements Postal Message Fulfillment
9.1. Message Spooling for Fulfillment
9.2. Sender and Receiver DPID Information
9.3. Print Fulfillment Parameters
9.5. Mailbag Spooling of Distribution Lists
9.6. Cover Letters and Filtering
9.7. Protocol for Postal Fulfillment Notification
10.2. IP addressing within the firewall are private class 10.x non-routable from outside.
10.4. Web traffic in a customer session is SSL v3 encrypted.
10.6. Message Authentication Types
10.7. Messaging Security Standards Compliance
10.8. Control of Authentication
10.13. Legal Protection Procedures
10.14. Optional services such as http://www.disappearing.com/
11. Logical Data Model for Message-ID Requirements
11.5. Message Status entity has message-id as the primary key.
11.11. @Post Data Model Retrieval Criteria
12. @Post Messaging Enabled Applications
12.1. Direct Mail Market Research Databases.
12.2. Web-Form driven @Post Applications
12.3. Templates and Windows Applications for Cards, Flyers and Brochures
12.4. Postal Messaging Alert Service
12.5. Selective Direct Mail Fulfillment Applications
12.6. Customer Name and Address Matching E-Service
12.7. Postal Forwarding Interface
12.9. Custom Made Messaging Applications
12.10. Mail House Applications
13.2. B-Party Preferences, Best Reach & Follow-me
13.3. 3rd Party Directory Services Alliances
14. Customer Administration, Inheritance and Profiles
14.2. Trusted Customer Officers
15. Core versus Non-Core Business
16. Automated Document Conversion
16.1. Input Microsoft Office - Mandatory
16.2. Input Lotus SmartSuite - Optional
16.3. Other Input Formats - Optional
16.6. Examples of Pricing - Eletter.com September 1999
16.7. Alternatives to Document Type Conversion
16.8. Problems with Document Type Conversion
16.9. Print Fulfillment Efficiency
17. Legally Admissible Messaging
17.1. Level 1 Legally Admissible Messaging
17.2. Level 2 Legally Admissible Messaging
17.3. Level 3 Legally Admissible Messaging
17.4. @Post General Offering for Legally Admissible Messaging
19. Print Fulfillment Queue Management
20. EDI Post Print Fulfillment
20.2. Notes on current EDI Post Printers
1. Services
1.1. Message Types Supported
1.1.1. Postal Messages
1.1.1.1. Print by default on envelope from-address and sender details from subscriber profile. Sender identification and address details may be suppressed by subscriber’s profile or per message – the latter via web-client.
1.1.1.2. Message-Id must always be printed on the envelope as plain text and bar-coded.
1.1.1.3. Subject-line line by default is not printed on the envelope unless option set by subscriber’s profile or per message – the latter via web-client.
1.1.1.4. Printed Message Header Information
The 1st page will be printed with the following message header information:
· Message-id
· Date-time originally sent by A-party and date-time entered into postal stream
· Public sender details by default are title, first name, optional middle initial or name, postal address, telephone, faxes and email contact details if available and not suppressed by subscriber. Automatically obtained from subscriber profile and can be set per message within a web session.
· Receiver details including a postal-address that has to translate to a valid DPID
· List of attachment file names, number of pages printed and document type
1.1.1.5. Message body print-out follows message header
1.1.1.6. Attachments print-out follows message body
1.1.1.7. Default will be for a page break between message header and body, between body and 1st attachment and for each successive attachment.
1.1.1.8. Attachment types to be supported as a minimum include html, pdf, postscript 2&3, all MS Office types, rtf and text. Adobe converters support some 200 additional document types.
1.1.1.9. Non-printable message types such as audio and video have to be specified in the message send options and will be delivered by post as a floppy disk or CD ROM.
1.1.1.10. Message preview function displays the whole message as if sent converted into pdf for the Adobe reader. Preview is optional but can be set pop up under A-party preferences.
1.1.1.11. A-party preferences include optional constraints for number of pages that can be printed per message.
1.1.1.12. System constraints will include upper limits for message body and attachment sizes, size of distribution lists and number of pages allowable for the A-party.
1.1.1.13. Each message-id is costed and compared to subscribers credit limit. The default is to send a message if within customer’s credit limit. Customer preferences may request a confirmation prior to sending for messages costing in excess of the limit specified by the customer. If the limit is set to zero dollars then the customer is always displayed the cost and prompted to confirm
1.1.1.14. Message cost is displayed as part of the message preview function.
1.1.1.15. Check whether color printing is allowed. A-party can specify black & white per message. The system will automatically select color printing when required and not blocked.
1.1.1.16. Print resolution is by default 300 dpi but higher resolutions such as 600 dpi or 1200 dpi selectable if supported.
1.1.1.17. Postal delivery class will be by default 1st class but selectable as express post or 2nd class bulk mail for direct mail customers.
1.1.1.18. A-party can request postal delivery receipt either per message or by default.
See Pitney Bowes DirectNET http://www.directnet.pb.com/main/tr_dov_home.htm as and example of postal message workflow, mail list handling and mail document templates.
1.2. Other Unified Messaging Types
1.2.1. SMTP-MIME email relay for and on behalf of subscribers
1.2.2. Voicemail
1.2.3. Fax
1.2.4. SMS - Pager - PDA
1.2.5. EDIFACT or EDI/XML
1.2.6. Tumbleweed Posta™ or docSPACE or similar secure delivery of e-packages
Re: http://www.jfax.com, http://www.ureach.com/ and http://www.messageblaster.com
1.2.7. Provide (toll free) numbers for fax and voice mail.
1.2.8. Support text-to-speech translation using advanced techniques such as http://www.lhs.com/ Lernout & Hauspie L&H RealSpeak™.
1.2.9. Support reverse natural language recognition as a value added service e.g. for message pickup, voicemail to email text translation, where desired, and IVR and voice activated responses, say to questions starting with simple yes/no confirmations.
1.2.10.SMS-Pager - PDA notification of incoming message headers sorted by B-party criteria with OK button downloading the message body and attachments in chunks by voice-to-text conversion and ability to respond by (voice converted back to text if required) by press of a button.
1.3. Subscriber Attributes and Preferences
The subscriber will be able to set her preferences for the following with defaults highlighted in bold:
Parameters to control cost:
1.3.1. Maximum expenditure per month
1.3.2. Alert for expenditure exceeding x% default 80%
1.3.3. Preview popup and confirmation before send: Y/N
1.3.4. Maximum cost per message
1.3.5. Postal class: express 1st and 2nd
1.3.6. Postal delivery receipt: Y/N
1.3.7. Notary service: Y/N
1.3.8. Email notification for postal delivery in addition to physical receipt: Y/N
1.3.9. DPID override: Y/N (override strongly discouraged)
1.3.10.Maximum percent of address rejects for bulk mail send: default 1%
1.3.11.Page setup: A4/Letter/A3 Portrait/Landscape Single-sided/Double-sided
1.3.12.Page break after: message header: Y/N, body: Y/N and between attachments: Y/N
1.3.13.Color allowed: Y/N
1.3.14.Print resolution: 300 dpi/600 dpi/1200 dpi/others if available
1.3.15.Non-printable media attachment (voice or video) allowed: Y/N
1.3.16.Envelope material: Standard/Glossy/Recycled
1.3.17.Envelope type: Standard Outer/Standard Outer & Reply Paid Inner/Postcard. The system automatically selects the right size of envelope. Envelope content can be sent via a web-form or as an email message body with @Post alerting the user if the maximum size for a post card is exceeded.
1.3.18.Voice mail allowed: Y/N
1.3.19.Fax allowed: Y/N
1.3.20.SMS/Pager allowed: Y/N
1.3.21.Email notification of incoming message: Y/N
1.3.22.Email confirmation and date-time stamp for message received for processing: Y/N
1.3.23.Email confirmation and date-time stamp for message entering postal stream: Y/N
1.3.24.Delivery receipt and date-time stamp for fax and voice mails: Y/N
1.3.25.Delivery receipt and date-time stamp for email: Y/N
1.3.26.Read receipt and date-time stamp for email: Y/N
1.3.27.Pickup by phone receipt and date-time stamp: Y/N
1.3.28.Pickup receipt and date-time stamp for secure e-package: Y/N
1.3.29.B-Party Receive Preferences: Does not apply / Postal / Fax / Voice / Web / Email
1.3.30.Method of authentication: Web log-on / Web log-on + IP-range / e-mail address + IP-range/ e-mail address / X.509 certificate / X.509 certificate + logon/ X.509 certificate + email address / X.509 certificate + address range / X.509 certificate + IP range + logon / X.509 certificate + IP range + email address
1.3.31.Subscriber details in the format attribute name attribute value printed on envelop: y/n are:
· User-Id Y/N selected by user but uniqueness enforced
· Customer-Id Y/N parent billing account id for user-id is system generated
· First Name Y/N
· Middle initial or name: Y/N optional
· Last name Y/N
· Or Business Name Y/N for business customers
· Australian Company Number Y/N when available
· Alternative Business License Y/N for businesses without A.C.N
· Unit name within Business Y/N optional for business accounts
· Belongs to Group name Y/N optional for business accounts
· Postal return address Y/N
· DPID Y/N
· Email Address Y/N optional
· Phone Number Y/N optional
· Alternative Phone Number Y/N optional
· Facsimile Number Y/N optional
· Message authentication method Y/N
· User-Id attributes u1, u2 to u10 Y/N optional users specify display names and allowable values
· Customer-Id attr. C1, c2 to c10 Y/N optional customer admin specifies display names and allowable values
· B-party messaging preference Y/N shows none set or top-to-bottom receive preferences. If set, then chargeable service for conversions.
1.3.32.Subject line printed on envelope Y/N
1.3.33.Retention period for messages Archive asp = 1 month / 3 months / > user specified/ forever=notary messages
Archive asp means deletion on confirmed delivery plus a service policy specified cool-off period (1 month). Keep messages with delivery under dispute. Messages with delivery failure notified are kept 1 month for re-submission.
All valued added messages sent are stored for the retention period in the subscription service web-mail / e-mail account and can be viewed or resubmitted or forwarded as new messages, of course attracting fees. Excess retention is chargeable. Retrieval from archive is chargeable.
2. Billing
2.1. Customer Types
2.1.1. Credit card. Aggregate until end of month not exceeding approved credit limit (default $100).
2.1.2. Debit card. Start with minimum balance (default $100), top up by $x (default $100) when y% used (default 80%).
2.1.3. Prepaid on account with minimum balance (default $100). Alert when x% (default 80%) used.
2.1.4. Scratch-stamp customers.
2.1.5. Major corporate mailers are invoiced with credit limit in excess of $1,000. Invoice EOM or when credit limit reached. Alert when x% (default 80%) of credit used.
2.1.6. Billing account attributes are:
2.1.7. Customer type: credit card /debit card /prepaid account /scratch stamp /corporate mailer
2.1.8. Credit requested and credit approved for credit card customers and corporate mailers.
2.1.9. Minimum balance and top up for debit card and prepaid accounts.
2.1.10.Alert when x% (default %) used.
2.1.11.Billing frequency (default monthly or when credit limit reached)
2.1.12.Customer profile is mandatory for all customer types bar scratch stamp. Scratch stamp customers without a customer profile have to specify A-party send preferences when sending a message or accept system defaults. Postal deliveries for such customers are marked as ‘sender and return address unknown’ unless specified for the message. Such customers’ access to customer care is limited to inquiring about specific message-ids with scratch stamp id serving as password authentication for the inquiry. Also, status of scratch cash card-id, e.g. amount unused and individual stamp id inquiries are available via the web interface. A customer profile is mandatory in all cases when a customer requests B-party preferences.
2.2. Global Fee Types
2.2.1. Service activation is free by default but may be charged to corporate mailers.
2.2.2. Service deactivation fee including return of monies on account and/or delivery of archived messages and information on media is charged to recover cost. Service deactivation procedure including archival of customer message files and information and postal delivery of archived messages have to be documented and automated.
2.2.3. Monthly service fee: free by default for customer’s using the automated web and email customer care interface but chargeable for telephone support. Telephone support is not charged for ‘service is not accessible’ or similar calls relating to service disruptions or degraded service. Customers joining will in any case be provided free telephone support for the 1st month. Telephone support can be purchased either as a service pack entitling a customer for x-calls or charged on a timed per call basis. Customer care must request customer permission before providing charged support.
2.2.4. Consulting, professional service and training fees such as direct mail marketing campaigns are charged as per contract. Customers will be offered packs of prepaid professional services including training.
2.2.5. Excess retention fees for message storage and recovery from archival fee
2.2.6. Notary service including insurance fees where @post acts as trusted party for legally admissible messages
2.2.7. Periodic Privacy Protection list service fee
2.2.8. Mailing list DPID maintenance is free for use within the system but export of a mailing list is charged $1 per 100 DPIDs.
2.3. Per Message Fee Types
2.3.1. Per postal message fees are:
2.3.2. @Post process fee is standardised as a markup on postal output fulfillment fees.
2.3.3. Postal output fulfillment (EDIPost/IDP) depends on number of pages printed, single or double sided, color or black and white, print resolution, paper and envelope quality or in the case of non-printable the type of media used for example CDROM and the amount of information storage content.
2.3.4. Postal delivery fee depends on postal class and weight as a function of the print or media fulfillment and whether postal delivery receipt is required.
2.3.5. Per message fees will be adjusted on the aggregated (monthly) bill by offering quantity discounts. @Post passes onto customers as much as possible its own discount as a bar-code compliant mass mailer with a strong bias to favor corporate mailers.
2.3.6. Other Value Added Messaging Fees
2.3.7. Voice mail, facsimile, EDI/XML and SMS fees are composed of @post process markup and carrier or service provider charges.
2.3.8. Secure e-package delivery is charged per transaction with extra package storage size fees.
2.3.9. Message pickup fees, if not otherwise stated, will be charged against the A-party and depends on the message type and pickup method.
2.3.10.Notary service charged depends on level of legal admissibility, the retention period, type and size of message and insurance cover required.
3. Message Handling
3.1. Inheritance
A message inherits customer profile preferences for all attributes not re-specified by the customer for the message.
3.2. Credit Handling
Message is sent only if customer account (or scratch cash) has cover or within credit limits.
3.3. DPIDs
A postal message is never sent within Australia unless the postal address translates to a valid unique DPID unless a customer overrides DPID enforcement in which case @post assumes no other responsibility except that the message has been onto postal fulfilment. Messages without a valid DPID will not be accepted for postal delivery receipting and will not be part of @post notary services.
3.4. Overseas Postal Address Validation
@Post endeavors to handle postal address validation for major overseas postal services under IDP, in particular the U.S. zip 5+4 and the future zip-11 validation.
3.5. Subscriber Send Confirmation
Subscriber is prompted for send confirmation in a web-session if a message has any non-fatal errors such as invalid addresses in a mailing list. The prompt will be whether to send the valid ones or not.
3.6. Bulk Message Handling
Messages sent ‘blind’ say by email to mailing lists, will be processed and sent to valid addresses but only if the number of errors is below system and user set limits.
4. Distribution Lists
4.1. Support of Unified Messaging Types
All types of messaging supported by @post can be addressed from a distribution list including postal, email, fax, voicemail and so on. Multiple message types may contact the same entity.
4.2. Upload
Distribution lists can be uploaded using the web administration interface from customer databases in MS Excel and Access, csv-file and fixed format flat files. Also, support import of address-books and distribution lists from major email systems and clients such as MS Outlook.
4.3. Syntax
The syntax shall be receiver-info followed by address. Each entry has to be a separate record/ or line. The parsing starts from right-to-left to identify message type. If an Australian postal address, it has to translate into a unique valid DPID. For overseas postal addresses and for other address types, @post validation capabilities will be gradually implemented.
4.4. Templates
Customers will be offered distribution list templates to minimise rejects.
4.5. Validation
Each creation or update of a distribution list creates a valid address file stored for use and a reject list. Reject corrections can be added in bulk. Similarly, addresses can be deleted in bulk. A web-interface will enable interactive add/change/delete.
4.6. Additions
New addresses can be automatically or via prompt added from messages sent into address books or distribution lists nominated.
4.7. Line Control for Envelope Printing
The following rules will be observed for envelope printing:
4.7.1. Postal address has priority.
4.7.2. The same attribute must not be split across lines.
4.7.3. Subscriber can control format by using templates or alternatively by control characters agreed.
4.8. Rejects and Approvals
New distribution lists are accepted for message sends if percent of address rejects is less than the maximum percentage of rejects allowed. Existing distribution lists are pre-approved and not submitted for re-validation unless so requested by customer.
4.9. List Server Functionality
Provide List Server functionality for distribution list member to unsubscribe by sending an email or by free call or fax at customer’s expense or prepaid return mail. @Post will not allow unsolicited bulk mail by direct mail advertisers. Recipients under the @post Privacy Protection List service will be removed.
5. Usage and Billing Inquiries
5.1. Usage and Billing Information
Customers can request by e-mail usage and billing information by send a blank message to account-id.bill@post the reply being always emailed to the email address in the customer profile. Group accounts have a single master account-id eligible to request group wide information.
5.2. Bill Presentment
Bill presentment is always emailed when a periodic or on demand invoice is generated. Similarly, bill presentment including usage and cost since last bill is available via the web administration logon. Bill presentment starts with summary information for the current period and for the last n-invoices. Each invoice then itemized at message-id level. Each message-id is a hyperlink to detailed per message information.
5.3. Group Accounts
Group accounts breakdown is at Group Level, User Level and Message Level. Groups within groups can be supported via the web-query interface to the subscriber directory information. Customer administrator can set the attribute Belongs to Group Account to reflect organizational hierarchy. Similarly, any other combination of customer profile attributes can be queried for usage and billing information. In particular, customers can extend the schema by setting user attributes 1,2 and 3.
5.4. Export
Billing and usage information is available for export in csv-file and Excel formats for customers to create their own reporting to go beyond @post reporting and graphical presentation capabilities.
6. Message Tracking
@Post support for message tracking functions follows.
6.1. Message Tracking
Message tracking is by message-id with result available by web pull or pushed by email to the sender’s email address in response to email queries addressed to message-id.status@post.
6.2. Anonymity
Status of messages paid anonymously by scratch stamps require both message-id and the id of the 1st scratch cash stamp used for payment
6.3. Message Status
Message statuses include:
6.3.1. Receipt and date-stamp from sender to @post
6.3.2. In queue for fulfillment
6.3.3. Receipt and date-stamp for fulfillment complete meaning delivery into postal stream for postal messages.
6.3.4. In-transit postal stream statuses are not normally available but such capability may be supported by Future Post bar coding and possibly made accessible to @post.
6.3.5. Delivery receipt by B-party is available only for registered mail.
6.3.6. Secure e-package delivery will be receipted and date-time stamped for pickup.
6.3.7. Fax, voicemail, SMS, email etc. delivery will be receipted and date-time stamped but will be repudiable. However, @post will provide affidavit for any legal proceeding on behalf of @post customers and such sworn declarations should reflect the normal trust placed in postal services even if the means of delivery is electronic.
7. @Post Portal Services
The @post web portal provides the following functions:
7.1. Shop Front for potential customers
7.2. Service Activation
7.3. Unified Messaging Centre
The portal needs a unified messaging centre capable of sending and receiving all types of messaging including postal messaging.
7.4. Customer Administration
7.5. Usage and Billing
7.6. Customer Care
7.7. Seals for E-Trust and Web-Trust
7.8. E-commerce site in particular for add-on services
7.9. Advertising and Commercial Links Front
7.10. Extranets
Support business-to-business with @post being the hub, facilitator and notary for transactions.
7.11. Free portal attraction services
Portal attraction includes directory services, calendaring & scheduling etc. free services to support and attract wealthy consumers, SOHOs and SMEs.
8. Robotized @Post Email Services
@Post provides a number of robotized email services for its customers:
8.1. Usage and bill presentment
8.2. Message-id status
8.3. Response to message-id.action@post
Responses actions include status, cost, trace and stop in-transit (if possible). Responses to queries and commands relating to specific users or specific message-ids are always emailed back to the email address listed in the customer regardless of the originating from e-mail address.
8.4. Keywords.search@post
Enable search of @post web site including knowledge bases for information according to the keywords.
8.5. Newsletter
8.6. Advertising (no unsolicited bulk advertising)
8.7. Privacy Protection
Privacy protection is a list service to the public for a small annual fee that ensures @post is not used to send any message of a type(s) not desired. Public joins the Privacy Protection List via @post web-interface for payment and maintenance of preferences including filtering conditions such as not receiving messages not exclusively addressed or other specific exclusions. This is in addition to the public anti-spam lists. Any mailer may subscribe to the Privacy Protection List to prune mailing lists from people and companies subscribing to the privacy protection service. Such mailers are entitled to use the @post privacy protection logo.
8.8. Status@post
Responds back about any known service difficulties and bottlenecks in processing
8.9. Service notices
An alternative @post web site hosted outside external to @post without any dependencies on @post will be maintained to provide information about @post status and service difficulties and resumption.
9. Interface Requirements Postal Message Fulfillment
9.1. Message Spooling for Fulfillment
Message header, body and attachments converted into a pdf (or postscript) spool file for postal fulfillment.
9.2. Sender and Receiver DPID Information
Provide sender and receiver DPID information when obtainable from address analysis and translation.
9.3. Print Fulfillment Parameters
Parameters to control print fulfilment include (colour, print resolution, 1 or 2-sided, paper size and type, envelope type), postal class and optional postal delivery receipt.
9.4. Multimedia Fulfillment
Multimedia fulfilment is as above but on media such as CD ROM. Message header will be printed as well as written into the CD ROM. A courier service jiffy bag, delivery and receipt information is prepared. Courier service web-tracking message-id is emailed to the sender and to receiver if the receiver’s email address is provided.
9.5. Mailbag Spooling of Distribution Lists
Messages to distribution lists are logically spooled into a mailbag with individual messages. The spool file and control parameters, if possible, are transmitted only once. The to and from blocks are preferably collated into a single address file. This has to be worked out with the postal fulfilment service provider.
9.6. Cover Letters and Filtering
Functionality such as generating cover letters from the distribution list and modifying content according to some filtering criteria embedded as additional attributes in a distribution list is possible (currently supported by EDIPost/IDP fulfilment).
9.7. Protocol for Postal Fulfillment Notification
A protocol for postal fulfilment notification for completing defined stages in the postal service fulfilment; querying and reporting of status and position in fulfilment queue are required.
10. Security
10.1. Firewalls
@Post has a 2-layer firewall service with all chargeable services firewall protected. Alarming and monitoring, rating and billing, @post mail switch and administration system are all behind a second firewall.
10.2. IP addressing within the firewall are private class 10.x non-routable from outside.
10.3. Message transfer between @post POPs and postal fulfillment is tunneled virtual private network.
10.4. Web traffic in a customer session is SSL v3 encrypted.
10.5. Secure MIME
Secure MIME is enforced for customers choosing X.509 authentication. In particular, @post will not accept any value added message for send unless encrypted and, of course, will not send any email back unless encrypted with the customer’s public key.
10.6. Message Authentication Types
Message authentication types range from the weakest = email address to the strongest = X.509 certificate + fixed IP address + email address.
10.7. Messaging Security Standards Compliance
10.7.1.S/MIME agent
10.7.2.Secure SMTP with TLS (RFC 2487)
10.7.3.Client authentication to SMTP server (RFC 2554)
10.8. Control of Authentication
A-party controls whether the authentication method is included in the message header information.
10.9. Audit
@Post is audited for auscert, e-trust and web-trust compliance.
10.10. Privacy Statement
@Post privacy statement and security policy will be public and comply with e-trust.
10.11. Security Policy
@Post postal messaging has to comply with postal services security policy
10.12. Law Enforcement
Procedures for dealing with law enforcement and security bodies are mandatory.
10.13. Legal Protection Procedures
Procedures for supporting customers against false authentication and non-delivery claims are mandatory but carry fees. Procedures for @post trusted party notary services and insurance claims are mandatory, re: G5 compliance.
10.14. Optional services such as http://www.disappearing.com/
11. Logical Data Model for Message-ID Requirements
11.1. Reference-Id
Reference-Id is the identifier of the incoming message sent to @post. The inbound message may have bee by any means supported by @post whether incoming email, web request, fax, voicemail or IVR, SMS, EDIFACT or EDI/XML or an inbound postal message. An incoming message even if rejected is allocated a reference-id. A reference-id is always associated with at least one message-id even is a null message for rejects. A single reference-id of an inbound message sent to a distribution may generate a very number of message-ids across all the message types that @post can generate. The Reference entity has reference-id as its primary key, originator from address information, where obtainable, and attributes to store or point to the inbound message header, body and attachments. Inbound messages must be stored for the minimum retention period required by the billing contestability and longer when requested by customer. The Inbound-to-Outbound messaging entity is the master-detail table with reference-id as its primary key and foreign key references to all the message-ids, outbound messages generated, e.g. from the to, cc, bcc lists of an inbound email message.
11.2. Message-Id
We simply refer to outbound messages generated by @post by the term message-id. The following characterises message-id:
11.3. Message-Id is mandatory and has to be displayed on the message header and on the envelope for postal messages.
11.4. Message-Id ties to the paying customer’s hierarchy starting with the A-party or B-party @post user id.
11.5. Message Status entity has message-id as the primary key.
11.6. Inbound Message Entity
Inbound message entity has message-id as the primary key, inbound message's reference-id as foreign key and includes as attributes header, body and attachment information.
11.7. Outbound Message Entity
Outbound message entity has message-id as the primary key and all the attributes set by the customer or inherited from the customer's profile required by the @Post message switch for fulfilment and rating, for example number of pages printed, colour, type of postal class and so on.
11.8. G5 Compliance
11.8.1.Inclusion of document/message metadata, viz. sender, recipient, subject, keywords in first MIME header file of the message
11.8.2.Electronic postmarking including time and date stamp, unique message ID, and an encrypted checksum (for message integrity).
11.9. Message Rating Entity
Message rating entity has message-id as the primary key, index on customer id paying for the message and message cost rating before discounts.
11.10. Message-Id Hot Links
11.10.1. Full information related for the paying customer
11.10.2. Public header and status for the non-paying B-party
11.11. @Post Data Model Retrieval Criteria
11.11.1. The inbound message can be always fetched
11.11.2. All the outbound messages generated from the inbound message can be fetched and if necessary reprocessed
11.11.3. Message rating can be verified
11.11.4. Message status can be tracked
11.11.5. Message information will be retained and kept online for a minimum of seven years regardless of any shorter message retention.
12. @Post Messaging Enabled Applications
12.1. Direct Mail Market Research Databases.
12.1.1.Geospend - @Post
12.1.2.Dunn & Bradstreet - @Post
12.1.3.Generic marketing or customer database @post interface
12.2. Web-Form driven @Post Applications
Bill Presentment and Payment application is driven by a customer database and billing database where for each customer-id a (postal) message is generated according to the billing address details and according to the billing web-form attributes. The bulk of customers get their hardcopy bill via @post. Customers that prefer bill presentment by email are sent the filled in web-form with links to e-payment if applicable. Customers failing to acknowledge or pay their e-bills within the specified period (default 72 hours) will be billed by postal message.
12.3. Templates and Windows Applications for Cards, Flyers and Brochures
12.4. Postal Messaging Alert Service
Alert services are event driven messaging applications. For example, respond to a request for information as a postal fulfillment. A customer may, for example, send a request for a share offer pack by email or by web, with information automatically posted by @post. Another type of alert service, are debt collection notices, say for overdue bills. @Post will have a generic alert engine enabling customers to define events and responses to events.
12.5. Selective Direct Mail Fulfillment Applications
These applications for direct mailers range from writing an individual cover letter generated from the customer database to selective inclusion of content by selective parts of the submitted e-package meeting the filtering criteria of specific customer database attributes.
12.6. Customer Name and Address Matching E-Service
@Post will offer customer name and address matching services for customers willing to clean their customer database. We will seek partnership will one of the Future Post specialist houses such as MasterSoft.
12.7. Postal Forwarding Interface
Some 15% of all postal addresses at any time are forwarded delaying and slowing the postal process. If eligible and feasible, @post will interface with the postal service(s) forwarding database(s) for improved quality of service by removing a point of failure and processing from the postal delivery process.
12.8. Inbound Mailroom
@Post will provide inbound mailroom application to scan in and archive documents, to support virtual e-mail and virtual fax addresses, and mailbag collation as per the US PTO patent application.
12.9. Custom Made Messaging Applications
@Post professional services will work with major corporate customers to develop custom-made value added messaging applications.
12.10. Mail House Applications
@Post will seek alliances with major mail houses and print-on-demand value adders, direct mailers and organisations for bill presentment and payment with open systems, integration and value adding in mind.
13. Directory Services
@Post will support the X.520 person object based directory services as well as the following two specialist uses:
13.1. Anti-spam Filters
Anti-spam filters enabling users to specify criteria against reserving messages e.g. blocking:
13.1.1.Specific message types
13.1.2.Specific uses such as direct mails
13.1.3.Targeted by distribution lists and cc-lists e.g. a user can specify that she is exclusively addressed
13.1.4.Block messages exceeding certain size
13.1.5.Time of day restrictions for certain message types such as SMS, voicemail and fax
13.1.6.Block specific users or domains or phone or fax etc. message sources
13.1.7.@Post enforces the above restrictions for anybody listed for its anti-spam service against all A-party subscribers. The A-party senders have the right of over-ride for postal messages but an @Post disclaimer will be inserted.
13.1.8.@Post offers its anti-spam directory information for other mailers.
13.2. B-Party Preferences, Best Reach & Follow-me
13.2.1.@Post enables conversion of incoming messages into types preferred by the B-party subscriber
13.2.2.B-party can publicly list her subscriber preferences
13.2.3.Auto-reply, on-vacation and follow me
13.3. 3rd Party Directory Services Alliances
14. Customer Administration, Inheritance and Profiles
14.1. Customer Administration
14.1.1.@Post customer administration for is 100% web-activated self-service by Trusted Customer Officers TCOs. Any corporate or franchise structure or closed user group structure with any hierarchy can be defined and supported by TCOs.
14.1.2.A corporation or franchise can have multiple customer-ids linked to the one Group Name.
14.1.3.A nested hierarchy of any depth can be built from user-id belongs to business unit belongs to group that may belong to another group and so on.
14.2. Trusted Customer Officers
14.2.1.The first user-id is the master TCO that creates all other TCOs and is financially responsible for all the customer-ids singly and jointly with the other TCOs.
14.2.2.The master TCO inherits a system-defined profile with restricted attributes such as the corporate credit limit. The master TCO creates a template profile for her TCOs, defines individual credit limits and may write-protect any or all cost control parameters. Similarly, the master TCO defines a corporate profile for users inherited from the system profile for users. For example, the master TCO defines all the customer attributes c1 to c10.
14.2.3.Only TCOs have the right to create user profiles and individual users under a profile. Any attribute for cost control parameter is always write-protected from users.
14.2.4.Users may not change their user-id, credit limit assigned by TCO or any other cost control parameter but has the right to view his complete profile including all the settings inherited whether from TCO, master TCO or system, and has the right to update any attribute not write-protected, for example define user attributes u1 to u10. Users can carry out all the messaging operations allowable under their profile and view their own usage. A TCO has the right to view all usage of her users.
14.2.5.Credit limit of all chargeable @Post messaging operations need only be checked against the user limit. The system will not allow the sum of the limits of users to exceed the TCO's limit for the customer-id. Similarly, @post prevents the sum of all TCO credit limits allocated by the master TCO from exceeding her total credit limit.
14.2.6.Individual @post customers are automatically master TCOs. Small corporate such as SOHOs or SMEs may have only a single TCO and thus automatically the master TCO.
15. Core versus Non-Core Business
The core business of @Post is postal messaging. Everything directly related to postal messaging will be developed and supported by @Post. In particular, @Post message switch, activation, authentication, billing, customer care, distribution management and tracking are core business.
All other messaging types are non-core and if possible will be bought off-the-shelf. The criteria for acquiring third party messaging systems is ability to interface with @Post messaging database, ability to integrate with the @Post message switch, scalability and ease of support.
@Post messaging platform functions are classified core versus non-core as follows:
Non-core System Management and Monitoring Services
Core Message and Customer Database
Core Message Routing Services
Core Message Handling Services
Core Message Integration Services
Core Postal Fulfillment Services by IDP/EDIPost
Non-core Internet Messaging Services
Non-core POP3 Mail Access Services
Non-core IMAP4 Mail Access Services
Non-core Web Mail Access Services
Core Distribution Lists Management Services
Non-core Anti-Virus Services
Non-core Anti-Spam Services
Non-core Message Encryption and Decryption Services
Non-core Message Content Filtering Services
Core Postal Application Integration Services
Non-core Computer-Telephony (CT) Integration Services
Non-core Fax Gateway Services
Non-core Pager, SMS and PDA Gateway Services
Non-core Software Customization Services
Non-core Directory Services
16. Automated Document Conversion
Automated document conversion is not just a significant competitive edge for @Post but a potential revenue stream. The input document types are all major word processing applications, spreadsheets and presentation types. The output is PostScript 3 for print fulfillment and PDF for viewing with HTML/XML being an optional type. In particular, convert the following desktop types:
16.1. Input Microsoft Office - Mandatory
Microsoft Excel 95, 97, 2000 (7.0, 8.0, 9.0)
Microsoft PowerPoint 95, 97, and 2000 (7.0, 8.0, 9.0)
Microsoft Word 95, 97, 2000 (7.0, 8.0, 9.0) and earlier (Windows: 1.0,
2.0, 6.0, 7.0, 8.0; DOS: 3.0, 3.1, 4.0, 5.0, 5.5, 6.0)
16.2. Input Lotus SmartSuite - Optional
Lotus 1-2-3 96, 97, and Millennium
Freelance 96, 97, and Millennium
Lotus WordPro 96, 97, and Millennium
16.3. Other Input Formats - Optional
Lotus AmiPro (1.1, 1.2, 2.0, 3.1)
Microsoft write (3.x)
Corel WordPerfect 8.0 and earlier (Windows and DOS: 5.x, 6.0, 6.1,
7.0, 8.0.0.225)
FrameMaker (3.0, 4.0, 5.0)
Interleaf (1.1, 5.0, 5.2, 6.0)
Rich Text Format (RTF) - RTF is mandatory.
ASCII Standard PC
HTML files - HTML is mandatory
XML
Converts these file formats:
BMP, CDR, CGM, DIB, DRW, DXF, EPS, GIF, HPGL, JPEG, MSP, PCC,
PCX, PNG, PIC, RAS, TIFF, WMF, WPG
16.4. Output Formats
16.4.1.Postscript 3 is the mandatory format for print fulfillment
16.4.2.PDF in one step is highly desirable (Postscript 3 can always be converted into PDF by Adobe Distiller)
16.4.3.HTML is highly desirable
16.4.4.@Post is a print fulfillment system that accepts email and web-mail SMTP-MIME attachments. The attachments are automatically detached into the file server for print fulfillment using the automated conversion software. The printing will be in Postscript 3 and optional viewing by html and/or pdf.
16.4.5.@Post's ability to support not just print fulfillment but also automated conversion of desktop document types into PDF and HTML is a value added chargeable service - worth perhaps 10c per document.
16.5. Jobs costing
@Post requires an SDK to obtain the number of pages per document to be printed, whether gray scale or color and if color then whether light color, medium color or heavy color based on ink content. This is info is important for costing of jobs. Infoaccess.com supports the automated conversion of the above document types into HTML and XML. See ftp://tcsdkdocs:nonda@ftp.infoaccess.com/pub/tcsdkdocs/HTMLformat/TCSDK40.exe for details about their SDK.
16.6. Examples of Pricing - Eletter.com September 1999
The below form must be viewed by Internet Explorer. For those with NS Navigator: the cost for 1-page grayscale letter for domestic U.S. is $53$ for 100 letters.
' | 1) Estimate color ink usage: (or login to test an actual document, or click to learn more) | |||||||||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |||||
|
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Copyright © 1999 ELetter Incorporated. All Rights Reserved. |
The above with heavy color would cost $124.00. Similarly the above as a 3-page letter would cost $65.00 or 6c per page grayscale or 23c per medium color.
Observe the above is quoted in $US. Note the $10 minimum. Add $5 for mail merge of 100 letters.
For up-to-date eletter.com pricing information see http://www4.eletter.com/pricing/letter/letter.asp.
16.7. Alternatives to Document Type Conversion
16.7.1.The fully automated document type enables users to send postal messages to @Post without having to install any print drivers or in any other way change their normal working environment. Infoaccess.com Transit SDK, http://PDFZone.com/products/software/tool_html2ps.html and Adobe Distiller could be integrated to demonstrate such technology. A fair amount of development is requirement. For example, html2ps is written as a slow Perl script. Also, for each document converted we need to know how many pages will be printed, graysacle vis color and if in color estimate the amount of color: light vs. medium vis heavy.
16.7.2.has excellent functionality for enabling any application to output to PDF. 5D Jaws is a well-known PS engine.
16.7.3.Outside In® is the world's leading file access technology. At Outside In's core is a filtering technology that understands the file formats of more than 225 current and legacy applications, including the most popular word-processor, spreadsheet, database, bitmap, drawing and presentation formats. Based on this core, Outside In delivers a number of powerful technologies to developers, see http://www.inso.com/develope/index.htm. Leading applications such as Lotus Notes®, cc:Mail®, Novell GroupWise® and Banyan Systems BeyondMail® all integrate Outside In Viewer Technology (OIVT) as a solution for handling and viewing file attachments. Also, note the MetaPrint ™ print driver technology.
16.8. Problems with Document Type Conversion
InfoAccess.Com, KeyPak.Com and all the relevant third-party document conversion solutions on the Microsoft and PDF-Zone web sites have been contacted. The following concerns have been expressed about automated document conversion into PostScript and PDF as automated page composition:
- Fully automated data conversion into PDF or PostScript is possible from a number of formats, provided that (1) the input, once defined, remains entirely constant in terms of its data structure, and (2) perfection is not required in the output. Software that will perform the diagnostics on the input files, correctly interpret the variable display commands that will most likely be embedded in the files, re-format the documents as necessary, and output to perfect PDF or PostScript with no manual intervention on a consistent basis, to our knowledge, no such toolkit exists. It takes a human eye to ensure that the visuals retain their meaning, after the original document has been ported to a platform other than the one for which it was specifically created. Depending upon the complexity of the documents involved, the formatting may or may not be preserved. There is really no reliable way to know or predict what will or will not make the transition well, without a thorough understanding of each format involved. That is not practical in most cases. - Re: apexinc.
- As a general rule, 100% automation is impossible, regardless of source and target data types. Perhaps the closest thing to full automation is paper conversion to PDF-image-only, which requires an operator only to load the scanner. All digital-to-digital conversions that preserve the quality and complexity of the source documents require custom filter development, manual intervention, editing or mark-up, and some degree of manual QA. Re: activesystems.ca.
The bottom line is that a PDF conversion for print pre-view and user confirmation before print must be offered unless the user wants to skip print preview. @Post e-mail users would receive by return email the converted PDF file(s) for viewing - a small conversion charge of 5-10c per document applies waived if the user confirms sending of the postal message - with a URL hotlink for print confirmation. @Post web-interface presents the above as an online process.
16.9. Print Fulfillment Efficiency
A significant problem could be that print fulfillment is generally used for long runs involving similar documents, in such situations the problem of generating and parsing vast amounts of postscript is simplified by splitting off text that changes from the rest of the document (aka "Decomposition"). The current print fulfillment providers may not have the computer power to accommodate low volume complex postscript and still run these fast printers at full speed. Eletter.com has made significant progress in resolving such issues.
17. Legally Admissible Messaging
@Post implements legally admissible messaging by combined secure electronic and postal messaging.
17.1. Level 1 Legally Admissible Messaging
Level 1 messaging combines secure strongly authenticated encrypted and check summed e-package with postal message with postal delivery receipt. Level 1 is insured for $10,000. L1 messages cost $25 per party plus postal message cost for pages printed in excess of ten pages. Thus, a L1 message involving four parties is priced at $100.
17.2. Level 2 Legally Admissible Messaging
Level 2 adds to L1 twin print fulfillment of the e-package with a reply paid envelope for receivers to return the second copy signed and witnessed in total with each page initialed. Level 2 is insured for $100,000. L2 message cost $50 per party plus postal message cost for pages printed in excess of ten pages.
17.3. Level 3 Legally Admissible Messaging
Level 3 adds L2 physical witnessing of all signatures with a 100-point identity check of all the signers in a post office or other authority such as Justice of Peace. Level 3 is insured for $1,000,000. Higher insurance can be made available for L3 on request. L2 message cost $100 per party plus postal message cost for pages printed in excess of ten pages.
17.4. @Post General Offering for Legally Admissible Messaging
17.4.1.E-packages will be accessible by all parties a minimum seven (7) years and longer if required. Additional payment applies for longer retention charged at $1/MB pa from eight year onwards. Thus, a 5MB message to be kept for 10 years instead of 7 would cost an additional $15.
17.4.2.All access information, delivery and read receipts included the scanned in postal delivery receipt will be available online.
17.4.3.@Post archives the print fulfillment of the e-package in a sealed envelope. In the case of L2 and L3 this includes the returned and signed copy.
17.4.4.@Post notary has to sign off the sealed envelope as having met all the criteria for a legally admissible message and notify all the parties to this effect.
17.4.5.@Post notary has to follow the procedures established by the QC or senior barrister and the insurer supervising and auditing the operation for legally admissible messages.
18. G5 Messaging Capabilities
G5 messaging has the following benefits:
1. MIME based
2. Inclusion of document/message metadata, viz. sender, recipient, subject, keywords in first MIME header file of the message
3. Electronic postmarking including time and date stamp, unique message ID, and an encrypted checksum (for message integrity).
4. Content negotiations (new subject of a Standards track document from the IETF)
5. Full message confirmation by recipient electronic postmark retained with the sender’s.
6. Automatic “Electronic Original” legally admissible retention and archiving in compliance with 5 International Codes of Good Practice.
7. 3 Standards based additional forms of authentication and encryption
8. Automatic drop down to Group 3 Fax (carrier) and Internet e-mail and/or Internet Fax and/or postal delivery
9. Carrier independent operation: GSTN, Internet, mobile, cable, internal network
10. A range of automatic service calls to help the user, e.g. Directory Enquiry
@Post requirements are closely aligned with G5. The additional benefits would be automatic drop down to the message type capable of achieving delivery. Also, G5 has established criteria for legally admissible messaging. See http://www.group5forum.org/, http://www.group5.net/ and http://www.5gm.com/ for further G5 information.
We have the " G5 Messaging Trial Interoperability Agreement" by the 5th Generation Messaging Ltd detailing what it takes to implement G5 messaging.
Observe that the automated drop down capability is to maximize the reliability of message transport to overcome message delivery failures as distinct from delivering the same message by multiple means. @Post not only supports multiple types of delivery but offers B-party receive preferences as a paid service. Drop down should be paid by A-party and will override B-party preferences. The exception is where the B-party has subscribed to a privacy protection service and specifically requests not to be contacted by specific message types.
@Post will explore possible partnership with 5th Generation Messaging Ltd. Software.com has been selected as the supplier of the 5G protocol stack and archiver, thus enabling us to expedite G5 functionality and compliance. @Post is analyzing
19. Print Fulfillment Queue Management
Print fulfillment queue management is a critical success factor ensuring customer satisfaction. Simplistic FIFO queue management is not satisfactory as a single job can tie a queue for hours or possibly days when handling a massive direct mail campaign. Simple postal messages no longer than three pages should be given priority to maximize overall customer satisfaction.
Customers will be given the nice option of lowering their priority into 2nd class best effort mail with a discount. Mailbag collation is a very valuable and cost efficient service for customers with B-party preferences wanting all their messages converted into postal messages or for customers using @Post for outsourced printing services. Such requirements are ideally supported by mailbag collation on DPID.
Certain resource such as colour printing are more limited but in general @Post intelligent distribution should have an algorithm for print on demand at the facility nearest to the postal destination for maximal delivery speed. However, the algorithm must weigh this against supporting optimised throughput. Another complicating factor is the ability to sustain full print fulfilment speed with very large amounts of variable PostScript resulting from single postal messages. In fact, bulk jobs and distribution list handling may maximize overall throughput and thus revenue at the expense of customer satisfaction. In summary, print fulfilment queue management is a very complex issue.
20. EDI Post Print Fulfillment
20.1. Issues
1. EDI Post production printers would be generally used for long runs involving similar documents, in such situations the problem of generating and parsing vast amounts of postscript is simplified by splitting off text that changes from the rest of the document (aka "Decomposition"). AP may not have the computer power to accommodate @post's low volume complex postscript and still run these fast printers at full speed.
2. EDI Post printing is black & white 300 dpi. At least Sydney and Melbourne would require color 600 dpi. The cost of the top Xerox 92 ppm production color printers is $265,000 a unit plus extra for folders and stuffers, altogether perhaps $350,000 each, re: Xerox DocuPrint 92C Enterprise Printing System
3. EDI Post will face block obsolescence of equipment being 7-8 years old by the time @Post goes live.
20.2. Notes on current EDI Post Printers
· Xerox Purchased Delphax about 1 year ago, and do not intend to continue to sell the existing machines but intend to use the technology to extend their existing printer range to greater speeds.
· The Xerox High End Printer (HEP) engineering group has taken over responsibility for servicing the Delphax machines in Australia (only Australia Post).
· Since Xerox became involved operations and quality have much improved - the printers are now comparable to equivalent Xerox products.
· There are a total of 18 printers in Australia used by the EDI post project, 3 in Sydney, 3 in Melbourne.
· They are approx 6 years old.
· Cut Sheet, 300 dpi, connected to Pitney Bowes folders & stuffers.
Question: Could Xerox justify replacing the Delphax printers with DP180s?
Answer 1 (Responsible Engineering Manager): "Our cost tracking systems have not been in place long enough for us to get an accurate picture of the costs of running the units. Given that the Delphax systems are fully owned by Australia post already I don't think it would be cheaper for Australia Post to lease DP180s instead - I don't know it might be very slightly cheaper."
Answer 2 (Responsible Sales Manager): "No chance of making a cost justification to replace the Delphax machines yet"
Background. The DP180 is Xerox's fastest HEP product, 180 sides per minute, 600 dpi physical and 2400 dpi in PostScript emulation, cut sheet and a list price of half a million dollars. In the past 18 months the larger Print bureaus have prospered at the expense of the smaller operations. Both Security Mailing Services (SMS) and Salmat have invested heavily in several DP180s each. The cost of operations is only marginally better than the previous 50 and 90 page per minute printers; the payback is primarily in increased productivity (one man can manage more machines and product more copies per hour) and to a lesser extent reduced downtime.
The DP 330/900/1300 are Xerox's continues feed HEP products and represent a quantum leap in capability in comparison to the old cut sheet printers. The question is whether continuous feed printing can be justified and at what stage. The Australian Market according to Xerox large account manager FAX is too small to justify the expense of offering printers faster than 180 ppm. A Docuprint 360 has been available for some time (really two 180s back to back) but there have been no takers. When a Xeroxified Delphax does become available, he still questions the commercial feasibility of offering such a printer down under. Also, note the approaching bulk obsolescence of AP's printers being already six years old, and 7-8 year when @post goes live.
In summary, the advantage/disadvantage of using the Delphax machines to be negligible in terms of production cost per page. However while 300 dpi is still considered to be acceptable in the volume print industry quality might be an issue. High speed postscript printers might also give some technical headaches in terms of their ability to ingest & our ability to provide complex postscript data streams.
Operating costs of a Xerox printer vary between $4/1000 for the latest & greatest and $12/1000 for the oldest; the Delphax units probably fall in the middle of this range. Total indicative costs per thousand, printing onto blank A4 stock:
Xerox Lease & Maintenance plan 4-12
Burdened operator Cost (6 mins & $60/hr) 6
Paper 7
Total 17-25
So the actual incremental cost of printing the document is at most 2.5c/sheet assuming the printers are fully occupied and your overheads are already being covered.
Obviously costs are usually far higher than this since overheads, management, sales, marketing and under-utilised equipment time has to also be covered. @Post is talking in terms of >$1 per postal message. Thus, the actual print production costs should be negligible. Success is far more likely to depend upon quality, speed of service etc.
21. EDI Post Bar-coding
EDI Post supports DPID appending, barcode printing, mail preparation and lodgment service.
If you have a database of addresses in which you would like to include Delivery Point Identifiers (DPID) this service will address match and link DPIDs to your customer addresses using AMAS certified software.
This service enables you to lodge bar-coded mail by supplying EDI Post with data files containing DPIDs. EDI Post converts the DPID (where present) into the appropriate barcode for printing. Your mail is sorted into bar-coded and non-bar-coded streams before lodgement to ensure you gain the maximum postal savings.
If your data file contains a mix of addresses with and without DPIDs, EDI Post can also sort and add DPIDs to new records or records for which DPIDs have become available. EDI Post will print barcodes with the updated addresses and lodge as bar-coded mail. The amended records can also be returned for updating of your database.
This is a comprehensive service that takes data files without appended DPIDs; an address match using AMAS certified software, barcodes and streams the mail before lodgement to optimise savings. The data file can be returned to you with DPID information appended for updating of your database.
