In / Out Metrics

Submittals received:

• The number of incoming folders created for the selected sources for the selected period of time.
• We use the date of the folder

Files assigned (from submittals):

• The number of files assigned from the incoming folders of the selected sources for the selected period of time

Submittals sent:

• The number of submittals made to the selected sources for the selected period of time.
• We use the date of the folder
• We exclude VOID and AD-HOC

Files sent:

• The number of documents in submittals made to the selected sources for the selected period of time.
• We exclude VOID and AD-HOC

Files per submittal:

• Total # Documents OUT / Total Transmittals OUT.

Submittals per card:

• Total # Documents OUT / Total number of cards submitted
• e.g. If only one card was transmitted, but that card was sent 5 times, the result would be 5/1 = 5

Average days out (returned files only):

• Sum of days out with source (date returned - date sent) of all files which were submitted and returned during the selected period of time for selected sources.

• We include EACH return for every file. If one card has been sent/returned multiple times in the period, each send/receive cycle is included separately.

• We IGNORE files which which have NOT been returned.

• We include only files which have been returned via the incoming documents dashboard, or set as returned va auto reclaim. We ignore any card where status was changed via edit, or attached from obsolete.

Files sent which have ALSO been returned:

• Number of files sent and returned during the period.

Files processed via auto-reclaim:

• Number of files auto-reclaimed in the period

Files sent via Ad-Hoc submittals:

• Number of documents sent via ad-hoc transmittal. WE do NOT consider “SOURCE” value here. Just total number of docs in ad-hoc transmittals.

Due date metrics

Commitment based

All due date metrics are based on the commitments you have made. Those are measured (and reported to you) based on the DUE DATE for each workflow.

What is a workflow?

A workflow is a period of time punctuated by submittals. A card can be submitted many times. When looking at on time delivery, we want to be sure an measure each commitment, and whether it was upheld. If a card is due and submitted, then due again in the period, it has 2 workflows.

Once a card is submitted, the data associated with its due date is locked.

How are workflows grouped into the report periods?

Workflows appear in the report based on their DUE DATE, not submitted date.

This may require some thought, but it allows us to report on commitments made for each period.

A KEY example:

Assume a report based on a monthly period. If a card workflow has a DUE DATE of FEB 1, but is issued to the customer on JAN 30. That workflow (and on time delivery) is included in the FEB column. It was a commitment for FEBRUARY, which was kept (even if it was executed in January). It IS counted as a a FILE SENT in JAN. (helpful when calculating how much work was done in Jan).

If file is submitted in an earlier period (vs due date), then why not count it in the submitted period?

We could have. There are certainly different ways to view the a similar problem. For us, we decided to base our calculation on the commitment. If you commit to deliver in a certain period, and you meet that commitment, we give you credit in the period of the commitment.

Overall, as long as the analysis is consistent, what might appear in month one as a penalty (or bonus) will be offset in the subsequent period.

Also , we looked at this solution as a consistent measurement that was easily validated. In this case, the due date always establishes teh commitement period.

So - yes - could have been different, but the result is the same.

What if a user changes the due date?

In effect, we look at all commitments at the END of a period. This data is drawn from evaluating the historical logs up to the period end date.

If a user changes the due date before the period ends, then it the workflow is not considered a commitment for that period, so if not included in the numbers.

If a user forgets to update the date in one month, but changes it early the next month, it will appear as a missed commitment for the period. It will ALSO appear as another commitment for the next period.

Example: Report is set with period = month. If a card was due on FEB 28, and not submitted, but due date cahnged on MAR 1, the card would be a failed commitment for the FEB period, and an active commitment for MAR. If the due date was changed on Feb 27 to MAR 30, then the FEB reproting period would not include that card as missed.

Why is there no "on time delivery" metric for SENT files?

The key measurement is whether you are meeting your deliver commitments. If you have 100 cards scheduled for delivery on June 30, and you only send 10 of them, what is the important number? That you were 100% on time for the files you sent, or 10% on time for the commitment you made? Our reporting shows you the later of those values.

Workflow definitions

# of workflows with due dates in period:

• Includes both historical due dates (punctuated by submittals) plus current due dates
  • Historical due dates
    • Each time a card had a due date during the period, AND was submitted during the period, it will be counted separately.
  • Current due date
    • If the card is currently due during the period, it is counted. If you change the current due date out of the period, it will be removed from the calculation.

Files submitted on time:

• How many files – from the above list, were transmitted PRIOR to the due date.

Instance on time delivery:

• # of docs due during period / # of docs delivered before due date

Count of overdue cards:

• Number of cards which were
  • overdue when submitted PLUS
  • overdue and NOT submitted.
• ** NOTE: One card may be counted multiple times if it had multiple workflows in the period.

Avg days overdue (only for overdue docs):

• Days overdue / Cards overdue ** only for overdue cards **
  • Cards overdue:
    • Number of cards which were
      • overdue when submitted PLUS
      • overdue and NOT submitted.
  • Days Overdue
    • Sum the number of days of delay (due date - submittal date) for each workflow PLUS
    • end date of the period - due date for cards NOT submitted
• ** NOTE: One card may be counted multiple times if it had multiple workflows in the period.

Expected date metrics

# of workflows expected in period:

• Same as # of docs due during period (but using documents due to be returned to DocBoss).
• ** NOTE: One card may be counted multiple times if it had multiple workflows in the period.

# of workflows received before expected date:

• Same as # of docs delivered before due date (but using expected date field)
• ** NOTE: One card may be counted multiple times if it had multiple workflows in the period.

On time receipt %

• # of docs expected during period / # of docs received before expected date

General card metrics

Approved

• Number of cards which have received "status complete" setting during the period

Return to Revise

• Number of cards which have NOT received "Stage complete" setting during the period

OUT with Customer

• Cards with a + status at the end of the period

OUT with customer, overdue

• Cards with a + status at the end of the period, AND are overdue from customer

OUT with customer, not due yet

• Cards with a + status at the end of the period, AND are NOT overdue (i.e. scheduled)

Project metrics

Total projects started (or converted from quote to order)

• Projects which were initiated during the period

Total projects closed

• Projects which were completed or hidden during the period

Reviewer metrics

Average routing TAD for Admin, Tech, Drafter, Construction

• For all actions COMPLETED during the period by the described role
  • Not specific to a user – it is for the role only.
  • For all projects in the report.
• Sum for every completed card: Day completed – day assigned

Note: All of this data is built from the HISTORY of each individual file, and the scheduled delivery date of the document at the end of each reporting period. So - really, the only way to recreate this data is to look at the history of each card in the project, and follow the entries in the historical record.

e.g: if, in Sept 2019, a card was overdue, and then its due date was updated on Oct 2019 (and it was subsequently returned on time in Oct), it would show in this report as an overdue card in the September report, and an on time return in the October report. It was a long process to get it right, but this is a report built by interpreting the historical record of each card. It cannot be "fudged".