AI readiness for vertical software companies: your ticket and code history

What does AI readiness mean for a vertical software company?#

AI readiness for a vertical software company means having ticket, issue and code history that is complete, connected and usable for the purpose in mind. Most readiness checklists are written for data teams and focus on warehouses and pipelines; a software operator's real asset is the record of years spent building and supporting a product for a specific industry.

That record already exists across a handful of systems. The question for the CEO and CTO is whether those systems can show a full sequence: a customer reports a problem, support diagnoses it, engineering opens an issue, a pull request fixes it, a release ships it and the customer confirms. Where that chain is intact, both internal AI projects and outside uses have something to work with.

Readiness checklist by system#

A system-by-system check gives the CTO a quick picture without exporting anything. For each system, someone who administers it can answer these questions from the admin console and a few searches.

Linkage: the test that matters most#

Linkage is the readiness test that separates useful history from large but disconnected archives. A huge archive of unrelated tickets says less about how your product works than a smaller set where each escalation leads to the issue, the code change and the release that resolved it.

Run the test by hand before building anything. Pick a sample of escalated tickets from different years and try to follow each one forward; the share you can trace end to end is your real readiness, and the places the trail breaks tell you what to fix.

• 1Ticket to issue: does the helpdesk record the linked issue key through an integration or a field?
• 2Issue to code: do branch names, commit messages or pull request descriptions reference the issue?
• 3Code to review: do pull requests carry review comments, or were they merged without discussion?
• 4Code to release: do release notes or tags list the issues they shipped?
• 5Release to customer: did support close the ticket after the fix shipped, with a confirmed outcome?
• 6Incident to postmortem: does each major incident have a written review linked to its issues?

Outcome fields and accessible history#

Outcome fields and history depth decide whether linked records are worth much once you have them. An issue marked done with no resolution type, a ticket closed by an automation after silence, and a pull request later reverted without a link all leave the outcome unknown, so check resolution fields, reopen events and revert commits as part of readiness.

Depth means history you can still export, not years in business. Tracker migrations, helpdesk switches, Slack retention settings and plan downgrades each remove history quietly. Find the oldest record you can still open in each system and write it down; that date, not the founding year, is the start of your usable history.

Check deletion rules too. In Zendesk, for example, admins can create ticket deletion schedules that keep deleting archived tickets matching their criteria, and deleted tickets cannot be restored. Pause or narrow any such schedule while readiness is assessed.

Rights and sensitive content are part of readiness#

Rights and sensitive content checks belong inside readiness because they decide which records can be used at all. Customer agreements may limit how support conversations and usage data are used, contractor agreements decide who owns parts of the code, and open-source licenses attach conditions to some files.

Sensitive content shows up beyond code. Customers paste passwords and API keys into tickets, engineers share credentials in Slack, and wikis hold connection strings. Secret scanners are not limited to repositories: TruffleHog, for example, says it scans sources including Git, chats, wikis, logs, object stores and filesystems. Personal data in tickets needs its own review, and any legal questions are assessed with counsel.

Scoring readiness on a simple scale#

A three-level scale is enough to decide what to do next, and it keeps the conversation with the board grounded in specifics. Score each record family separately, since a company can be ready in engineering and far from ready in support.

Illustrative: a property inspection software company runs the check#

Illustrative: a fictional inspection software vendor serves commercial property managers. Its CEO wanted an honest view of readiness before committing to an internal support assistant, so the CTO and the head of support ran the system checklist and the linkage test together.

Engineering scored ready: GitHub pull requests referenced Jira keys for most of the company's history, and release notes listed issues. Support scored partly ready: older tickets had moved over from a previous helpdesk without internal notes, and an automation had been closing quiet tickets for years. Slack scored not ready because a plan change had shortened retention.

The company extended Slack retention for incident channels, turned on its helpdesk's Jira integration so new escalations stored the issue key, and backfilled links on older escalations only where a Jira comment named the ticket. It started the support assistant on the linked recent tickets and listed its engineering history for a metadata-only licensing fit check.

How SourceX uses the same signals#

SourceX assesses software companies with the same signals, organized by the SourceX Enterprise Data Value Framework: uniqueness, domain expertise, human-generated signal, scale, recency, data cleanliness, rights and AI utility increase value; exclusivity increases price; reproducibility reduces value; and preparation cost and privacy burden reduce net value. The framework is a SourceX methodology with qualitative ratings, not an industry standard or a price list.

Records that proceed move through the SourceX five-step transaction, Supply, Rights, Preparation, Approval and Delivery, and the first look collects only metadata about systems, history and record families.