Before: Arbitrator UlrichSchroeter (A), Respondent: CAcert (R), Claimant: Marcus M (C1), Paul J (C2), Case: a20111001.1

History Log

Original Dispute, Discovery (Private Part)

EOT Private Part

Discovery

The Facts

Considerations

... over revoke assurance / reapply assurance process

How does re-applying assurances affects AP?

CCA and side effects

... over automated mailing script

Procedural steps on requests

Part I

Intermediate Ruling #1

Deliberations

Frankfurt/Main, 2011-11-30

Considerations II

Part 1

Intermediate Ruling #2

This ruling is a followup to the Intermediate ruling #1 dated 2011-11-30 regarding individual cases "Revoke Assurance/Re-apply Assurance" following the "Thawte points removal" project

Part 1

In step 4 execution of "revoke assurance/re-apply assurance" process by a Support-Engineer who stays in contact with one or more Assurees and one or more Assurers (depends on who initiated the request and how many records are affected by the identified 0 points or decreased points bug) its likely that additional problems with user account data may block continuation of the running process - the repair of old assurance records as identified in the Riscs section under Considerations II to this case.

So here we have to seperate two cases:

  1. Support-Engineer detects a name mismatch with current AP and current practice.
  2. Assurer detects a name- or DoB mismatch in the Assurees online account.

Both issues blocks the running process as a potential name- or DoB mismatch cannot be passed in Re-appliance of an old assurance.

To work around the Assurance re-appliance, Support-Engineer (for case 1) or Assurer (for case 2) is allowed to pickup the issue as a new issue.

Support-Engineer (in case 1) or Assurer (in case 2) should start an intermediate new dispute filing that contains the following infos as addtl. infos:

  1. revoke assurance/re-apply assurance case ticket number (ticket id of order received by Support (case 2)) under which the data inconsistency has been identified
  2. The name + email of the involved parties
    1. case 2: (C) Assurer (R) Assuree
    2. case 1: (C) Support (R) Assuree or Assurer x1)

x1) if the data mismatch relates to the assurer, Support-Engineer is allowed to send a notification to the Assurer, and Assurer starts the new dispute filing by his own

The running Support ticket should be set on hold temporarely.

The Support-Engineer is allowed to move the new dispute filing by documenting the new ticket id number to the running case for later reference with high priority to the disputes queue. The Support-Engineer is further allowed to contact a potential Initial Case Manager (iCM) to transfer the new dispute filing from the Disputes queue to the Arbitration list, to get a new Arbitration case number selected for further documentation references.

In the case no iCM responds within a 24 hours period, Support-Engineer is allowed to act as iCM (DRP 1.3 Case Manager) to transfer the new dispute filing from the Disputes queue into the Arbitration queue, creating a new Arbitration case # under Arbitrations list with the ticket number of the new dispute filing ticket # under Synopsis column.

Support should document the new Arbitration case number to the current running case (Support ticket) as a ticket note:

The on-hold current running case should be reset by the Support-Engineer to unhold and Support-Engineer should continue with the execution orders in the running "revoke assurance/re-apply assurance" processing to the Assurer

Support-Engineer and Assurer have to enhance the documentation regarding the "revoke assurance/re-apply assurance" documentation with the information regarding the new dispute filing infos:

into the running Support ticket (by Support-Engineer) and to the affected CAP form (by Assurer)

I hereby gave the Assurer the permission with reference to this current Arbitration case # and documentation of the new Arbitration case # where the new dispute filing has been initiated to continue with order given by a Support-Engineer to re-apply the assurance.

Reason given: the data mismatch will be handled under the new arbitration case number. An identified data mismatch can be accepted temporarely until this data mismatch will be fixed finaly through another arbitration case, but is not subject to the current case. This procedure follows each common arbitration handling, where disputed data mismatches aren't fixed before arbitrators interaction.

In cases where a precedent case exist to handle the identified data mismatch, a second Support-Engineer is allowed to pickup the case and to proceed with the precedent ruling of such a case. If such a case happens, the dispute filing can be moved to the Support-Engineer queue instead of the Dispute filing queue.

The documentation has to cover the ticket id and the precedent arbitration case # under which the data mismatch dispute is handled instead of a new Arbitration case #

In the event a new dispute filing is started, the acting Support-Engineer is explicitly allowed to pickup the new dispute filing from the Triage queue to move it to the correct OTRS queue or to instruct a Triage member to move the ticket to the appprobiate queue (case can be handled with precedent - move into SE queue, case has be handled by new arbitration - move into disputes queue) so the ticket ends in the correct queue.

The reasons to take intermediate actions is, that delays in processing the revoke-assurance/re-apply assurance process should be prevented, to keep the process flow intact and to not delay the issues longer as needed.

The fast track processing of the revoke-assurance/re-apply assurance cases that relates to the "Thawte points removal" project is running under a deadline (that is currently not set, but may be set in the near future). It can be assumed, that the deadline setting will not take into account open running arbitration cases or open Support tickets. A sequentiell processing may break the current running process (old assurance records becoming not re-applyed) and will potentialy open another problem, that data inconsistency will still continue to be in the database. So therefor the running case should be finished with all the exceptions given, and the new issue is transfered to a new dispute to be handled under another precedent # or under a new arbitration case.

Support should deploy a handbook page that covers this current special case with current state steps 1 to 4 on processing with remarks to the potential exceptions handlings and the reference to current arbitration case number.

I hereby give Support the permission to handle the current received tickets with the similiar "revoke my assurance/re-apply assurance" requests accordingly to the current case upto todays date, with reference to the current case to be the proposed precedent for this cases.

I hereby request from the handling Support-Engineer(s) a short written exec meta report summary, regarding the next couple of cases to handle until today, how the current procedural steps fits to the processing in practice. If Support-Engineer identified further blocking issues? or if a ruled step needs further clarification.

Frankfurt/Main, 2011-12-05 Ulrich Schroeter

Ruling

Execution

Similiar Cases


Arbitrations/a20111001.1 (last edited 2013-02-25 23:05:37 by UlrichSchroeter)