Implementation & go-live exceptions
When an implementation hits a late request, a dependency, or a go-live risk, the exception scatters across email, tickets, and calls. Threada turns each one into a governed WorkItem with owner, evidence, approval, and an audit trail.
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 The evidence is split across email threads, support tickets, and call notes, so no one can see the whole exception in one place.
- 02 Ownership is unclear: it is half a customer task, half an internal one, and it falls between the implementation lead, product, and engineering.
- 03 Product and engineering have to prioritise the ask against committed roadmap work, and that decision happens in a separate tool.
- 04 Customer-side IT or vendor dependencies block progress, and the wait is invisible until the date slips.
- 05 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.
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.
Common questions
Is this a separate product from the rest of Threada?
How is this different from a ticket in our project tracker?
Can the exception still create or update an issue in our existing systems?
Does the audit trail capture who approved an exception?
Turn your exceptions into records
Start free with one workflow, or talk to our team about your exceptions.