ABOLTUSA Brighter Tomorrow, Together.
← All research notes

CRM from documents

Keep original dates alongside interpreted timelines

Document date, event date and import time describe different parts of a customer history.

Share this article
LinkedInXFacebookTelegramWhatsApp

The research question

A signed agreement from March is scanned in July and imported in October. Sorting account activity by file modification time places the agreement after later correspondence and can make the business sequence appear impossible. The dates are not interchangeable: each describes a different observation or event, and some may be known only approximately from the available evidence. Provenance research distinguishes contributing data from its source locations. In a document-derived CRM, both help a reviewer understand how a conclusion was formed and inspect the particular evidence on which it depends.

A concrete design choice

The proposed record stores the source’s stated date separately from ingestion time and any confirmed business-event time. A timeline should identify which axis it uses and retain the original timezone or date precision where known. If a document provides only a month, the system should not invent a day to make ordering convenient. Late arrival can update what the CRM knows about an earlier period without implying that the event happened again. This also lets reviewers distinguish a newly discovered historical fact from a recent change in the customer relationship.

What would demonstrate usefulness

Evaluate late scans, undated notes and messages with explicit timestamps. Ask reviewers to reconstruct the supported sequence and identify the uncertain intervals. A useful timeline makes uncertainty visible and avoids generating a process violation solely because evidence was imported after the event it describes.

Research sources

Prepared 17 October 2026 from the project's research materials. Examples and proposed workflows are editorial interpretations. ABOLTUS is in development; a research method or design proposal does not establish that a feature is available or validated in customer use.

Make the research practical.

Tell us which documents you work with and the decisions you need to make.

Share your use case ↗