Skip to content
Use-case play

Implementation & go-live exception tracking

Customer-specific requirements start as detailed conversations, then become vague tickets as they move from onboarding to product and engineering. Threada keeps the captured request context, exceptions, evidence, open questions, and decision attached through the handoff.

What it is

An implementation or go-live exception is anything that threatens a planned launch and does not fit the happy-path checklist: a late customer request, a customer-side or vendor-side dependency, an integration blocker, a compliance or security ask raised close to the date, a discovered go-live risk, or a scope change. Each one is a small decision with a deadline, an owner, and consequences — and each one tends to live in a different inbox, ticket, or call until someone chases it down. The work is real; the record of it usually is not.

Why it gets stuck

  • 01 Informal requirements are compressed into setup notes or tickets, so triggers, affected systems, business rationale, and edge cases turn into conflicting assumptions and rework.
  • 02 The evidence is split across email threads, support tickets, and call notes, so no one can see the whole exception in one place.
  • 03 Ownership is unclear: it is half a customer task, half an internal one, and it falls between the implementation lead, product, and engineering.
  • 04 Product and engineering have to prioritise the ask against committed roadmap work, and that decision happens in a separate tool.
  • 05 Customer-side IT or vendor dependencies block progress, and the wait is invisible until the date slips.
  • 06 There is no decision trail: when the launch is reviewed, no one can show who approved the exception, on what evidence, or when.

What good looks like

One exception, on the record — every field accounted for.

REC-01 Exception record
Requester Implementation lead (raised on behalf of the customer)
Customer / account Named in the WorkItem, scoped to the tenant
Deadline Go-live date the exception is measured against
Impacted milestone The specific launch step the exception puts at risk
Owner One accountable person, assigned and visible
Evidence The customer request, dependency note, and security ask, attached and cited
Decision Approve, defer, or descope — recorded with the reasoning
Approver The reviewer who signed off the decision step
Next action What happens next, with the system and owner named
Audit trail Every state change, comment, and approval, time-stamped end to end
Resolved · on the record

Original proof assets

Concrete sample records make the workflow inspectable: the WorkItem shows the structured unit of work, and the audit export shows the receipt trail.

Sample output

WorkItem JSON

A concrete record showing the request, extracted fields, confidence, risk flags, evidence links, policy version, SLA, and queue state.

{
  "work_item_id": "wi_3f9a2b7c1d",
  "intent": "vendor_security_review",
  "confidence_score": 0.92,
  "risk_flags": ["external_requester"],
  "policy_set_version": 3,
  "status": "WORK_ITEM_STATUS_IN_REVIEW"
}
generation_mode: illustrative_sample · provenance_citation: docs/spec/product.md#design-principles · Synthetic marketing sample; not tenant data · Replace example IDs, domains, roles, and thresholds before use.
Download WorkItem JSON
Sample export

Audit CSV

An exportable event trail tying intake, proposal, approval, and execution back to the same WorkItem.

event_id,occurred_at,action,actor_email,work_item_id,message
evt_1a2b3c4d,2026-06-18T09:12:00Z,CREATED,system@example.com,wi_3f9a2b7c1d,WorkItem created
evt_3c4d5e6f,2026-06-18T09:58:00Z,APPROVED,a.reviewer@example.com,wi_3f9a2b7c1d,Approval granted
evt_5d1e9b3a,2026-06-18T10:03:12Z,EXECUTED,a.reviewer@example.com,wi_3f9a2b7c1d,Executed governed action
generation_mode: illustrative_sample · provenance_citation: docs/spec/product.md#design-principles · Synthetic marketing sample; not tenant data · Replace example IDs, domains, roles, and thresholds before use.
Download audit CSV

How Threada helps

Each move maps to a real platform capability.

  • 01 Each exception becomes one governed WorkItem — a lifecycle-managed unit of work — instead of a thread that lives in someone's inbox. Intake from email, forms, or messaging is normalised into a structured item with a typed schema. WorkItem
  • 02 The customer request, the dependency note, and the security ask are attached and cited as evidence on the item, so the reasoning behind the decision is grounded and reviewable, not reconstructed from memory. EvidenceBundle
  • 03 One owner is assigned and visible on the item, so the exception stops falling between the implementation lead, product, and engineering. WorkItem ownership
  • 04 Approve, defer, and descope run through an explicit decision step — a human-review or approval gate — so the exception is not closed until the right reviewer signs off. DecisionStep
  • 05 The agreed next step can run as a governed action on a connected system (create or update an issue, notify a channel), executed with idempotency and an auditable execution record rather than a manual hand-off. Action
  • 06 Every state change, comment, and approval is captured as a time-stamped event, so the launch review can show who decided what, on what evidence, and when. TelemetryEvent / audit trail

A worked example

Illustrative scenario (not a customer story)

A bank is days from going live on a new workflow when its security team asks for an extra control that was not in the original scope. Today that request might arrive by email, get forwarded to engineering, get discussed on a call, and sit unowned while the date approaches. As a Threada WorkItem, the same request is captured once: the security ask is attached as evidence, the implementation lead is the owner, the impacted go-live milestone and deadline are on the record, and the approve-or-defer decision runs through an explicit approval step. The launch review can later see exactly how the exception was handled — names, dates, and reasoning all on the record. This is an illustrative example to show the shape of the work; it is not a real customer, and no metrics are claimed.

Explore the capabilities

WorkItemsEvidenceActionsGlossaryTrust centerIntegrationsFAQ

Common questions

Is this a separate product from the rest of Threada?
No. An implementation exception is just a WorkItem — the same governed unit of work Threada uses everywhere — configured for go-live exceptions. You are not buying a new tool; you are routing this class of request through the same intake, evidence, approval, and audit machinery.
How is this different from a ticket in our project tracker?
Threada is not a replacement project tracker. Jira or Zendesk can remain where the task is assigned and completed; Threada preserves the request context it receives, including business rationale, exceptions, unresolved questions, evidence, and the decision, then creates a downstream Jira issue or Zendesk ticket with that context attached. The distinction is preserving captured context through the handoff, not adding another configurable ticket.
Can the exception still create or update an issue in our existing systems?
Yes. The agreed next action can run as a governed action against a connected integration — for example creating or updating an issue, or notifying a channel — with idempotency and an auditable execution record. The WorkItem stays the system of record for the decision.
Does the audit trail capture who approved an exception?
Yes. Approvals run through an explicit decision step, and every state change, comment, and approval is captured as a time-stamped event. A launch or compliance review can see who approved the exception, on what evidence, and when.

Turn your exceptions into records

Start free with one workflow, or talk to our team about your exceptions.

Start free Talk to sales
All use-case plays