From clerk to clerkless.

The solution

Three steps the clerk supervises.

Clerkless compresses the mechanical 90% of that workflow into seconds, and routes only the parts that actually require a human's judgment back to the clerk.

When the model isn't sure, it asks.

Anything below the confidence threshold (currently 85%) is flagged yellow with a "⚠ needs confirmation" pill and an inline editor. The "Render Packet" button stays disabled until the clerk has confirmed every flagged field. The model can return "Unknown" with 10% confidence rather than gambling — exactly the behavior you want from a system that ships into a regulated workflow.

In Salesforce

This isn't a side tool. It lives inside the CRM.

Clicklease's title-and-registration team already works inside Salesforce all day. Production Clerkless slots in as a Lightning Web Component on the Equipment record page, calls out to the Lambda via a Named Credential, and writes the rendered packet back as a ContentVersion attached to the record.

The data flow

  ┌──────────────────────────────────────────────────────────────────────┐
  │  Salesforce Equipment record                                         │
  │  ┌────────────────────────────────────────────────────────────────┐  │
  │  │  <c-clerkless-wizard>  (Lightning Web Component)              │  │
  │  │    [ Drop MCO ]   [ Extract ]   [ Review ]   [ Render Packet ] │  │
  │  └────────────────────────────────────────────────────────────────┘  │
  └──────────────┬─────────────────────────────────────┬─────────────────┘
                 │  Apex callout via Named Credential  │  ContentVersion
                 │     CLERKLESS_API                   │  written back
                 ▼                                     ▲
  ┌──────────────────────────┐                ┌────────────────────────┐
  │  Clerkless Lambda (AWS)  │                │  ContentDocument       │
  │   POST /api/extract      │ ─── reads ──▶  │  attached to Equipment │
  │   POST /api/packet       │                │  (signed PDF artifact) │
  └────────┬─────────────────┘                └────────────────────────┘
           │
           ├── Anthropic API (vision extract from MCO)
           ├── Lease__c (customer lookup by VIN)
           ├── Dealer__c (originating dealer normalization)
           └── State_Rule__c (fee + tax math, per state)
    

Salesforce objects we read from

Why State_Rule__c is the load-bearing piece

Fifty states, three fee regimes, dozens of edge cases — that's not code, that's configuration. One record per state. Putting the rules in Salesforce means:

• The T&R team owns it. Tax-rate changes happen on a record, not in a deploy. When Utah raises the title fee in July, an ops lead opens a record and types 8.00.
• Audit trail comes for free. Salesforce field history tracks every rule change with timestamp + actor — exactly the audit a state DMV examiner would ask to see.
• The Lambda stays stateless. It pulls the state rule on every render, so a config change is visible on the next packet without redeploying anything.
• State rollout is just data. Adding Texas means inserting one State_Rule__c record. The Handlebars template for TX 130-U is the only code touch.

Apex sketch

@AuraEnabled(cacheable=false)
public static String generatePacket(Id equipmentId) {
    Equipment__c eq = [
        SELECT Id, VIN__c, Year__c, Make__c, Model__c, Color__c, MSRP__c,
               (SELECT Lessee__r.Name, Lessee__r.BillingState,
                       Start_Date__c, Term_Months__c, Monthly_Payment__c
                FROM Leases__r LIMIT 1)
        FROM Equipment__c
        WHERE Id = :equipmentId
    ];
    Lease__c lease = eq.Leases__r[0];
    State_Rule__c rule = [
        SELECT Form_Code__c, Title_Fee__c, Registration_Formula__c,
               Sales_Tax_Rate__c, Packet_Template_Id__c
        FROM State_Rule__c
        WHERE State_Code__c = :lease.Lessee__r.BillingState
        LIMIT 1
    ];

    HttpRequest req = new HttpRequest();
    req.setEndpoint('callout:CLERKLESS_API/api/packet');   // Named Credential
    req.setMethod('POST');
    req.setHeader('Content-Type', 'application/json');
    req.setBody(JSON.serialize(new PacketRequest(eq, lease, rule)));

    HttpResponse res = new Http().send(req);
    // Write the returned PDF as a ContentVersion attached to the Equipment record
    return ContentVersionService.attach(equipmentId, 'TC-' + eq.VIN__c + '.pdf', res.getBody());
}

That's it. ~30 lines of Apex, one Named Credential, one LWC, the existing State_Rule__c records the team already maintains for the current TITAN system. The Lambda doesn't change between Clicklease and any other vehicle-finance company that wants to run the same pattern.

Beyond the MCO

Same flag-and-confirm pattern. Second document type.

The MCO is the hard input on the dealer side. On the customer side, the driver's license is the equivalent — and it's where most title packets actually come back wrong. The DL on file in Salesforce was captured at lease origination; by the time the title application ships, the lessee may have moved, renewed their license, gotten married and changed their name, or had their address transposed by an intake agent.

Clerkless treats the DL exactly like the MCO: vision extraction → compare to the Salesforce record of truth → flag every mismatch for the clerk to confirm via Teams.

What conflicts get flagged

Same Teams card, different fields

The clerk gets a single Adaptive Card per packet — MCO flags and DL conflicts in the same card. They review once, confirm once, the packet renders with both the model's MCO extraction and the human-vetted DL data baked in. One review, two documents resolved.