Skip to main content

Speech Insights Retro Processing

Retro Processing is the WinnerWare Speech Insights screen for applying new or changed transcript tags and indicators to calls that were already processed. Use it when you add a tag, fix an indicator prompt, or want older calls to carry the same insight as new calls.

Overview​

New calls get tags and indicators while they are processed. Older calls do not change on their own when you create or edit a tag or indicator later. Retro Processing closes that gap: you pick the tags and indicators to re-apply, optionally narrow the calls, and WinnerWare works through every matching completed transcript in the background.

A retro run can take hours on a large call history and can use a lot of AI capacity. For that reason, WinnerWare lets only one run be active at a time, saves progress after each small batch of calls, and can pause, resume, retry, and recover a run without starting over.

Key Features​

  • Re-applies selected Tags and Indicators to completed transcripts.
  • Narrows a run by Clients, Ingestion Sources, and a recording date range (Recorded From / Recorded To).
  • Starts a run only when you click Process Now, so a request can be reviewed first.
  • Shows live progress (Processed, Updated, Failed) and the date of the Last progress report.
  • Lets you Pause, Resume, Retry, and Cancel Run a run, and continue from the last saved checkpoint.
  • Counts each call that fails on its own instead of failing the whole run, and lists those calls under Failed transcripts.
  • Lets you Retry Failed to re-evaluate only the calls that failed, without redoing the calls that already succeeded.
  • Recovers a run that stops reporting progress (for example after an application restart) and resumes it automatically.
  • Includes a Delete Finished clean-up action for old run records.

How It Works​

1. Create a request​

Go to Speech Insights -> Retro Processing and click Create Retro Process. The request form has these options:

OptionWhat it does
TagsThe transcript tags to re-evaluate. Inactive tags are listed with (Inactive) after the name and can also be selected.
IndicatorsThe indicators to re-extract. Inactive indicators are listed with (Inactive) after the name and can also be selected.
ClientsLimits the run to calls from the selected clients. Leave empty to include every client.
Ingestion SourcesLimits the run to calls from the selected ingestion sources. Leave empty to include every source.
Recorded FromOnly evaluates recordings on or after this date.
Recorded ToOnly evaluates recordings on or before this date.

You must select at least one tag or indicator. When no filters are set, every completed transcript is evaluated.

Saving the form creates the request with the status Not Started. Nothing runs yet. You cannot create a new request while another run is not started, in progress, or paused. WinnerWare shows View Current Run so you can open that run instead.

2. Start the run​

Open the request and click Process Now. WinnerWare first counts the matching completed transcripts, so the progress shows 0 / Total as soon as the run starts. It then works through the calls in small batches.

For each call, WinnerWare checks each selected tag and indicator against that rule's own filters (clients, sources, dates, dispositions, and so on). A narrow filter on one rule never stops another rule from being applied to the same call.

  • Keyword and Expression tags are matched inside WinnerWare. They do not use AI.
  • Semantics tags and all indicators are sent to the AI deployment. Each indicator gets its own AI request.

3. How results are saved​

  • Tags: for each selected tag, the old result is replaced. The tag is added when the call matches and removed when it no longer matches. Tags that you did not select are not changed.
  • Indicators: a selected indicator is replaced only when it was evaluated again. If its AI request did not complete, the call keeps its previous value.
  • A call is saved only when something changed. The Updated count shows how many calls were saved with new values.

4. Watch progress​

The run list and the detail page show:

ItemMeaning
Processed: X/YHow many of the matching calls the run has worked through.
UpdatedCalls saved with new values.
FailedCalls that could not be evaluated. They keep their previous values.
Last progressWhen the run last reported progress.
Processing timeHow long the run has been working.

The detail page also shows the selected tags and indicators, Created by, Queued, Started, Completed, and the Recording date range. Refresh the page to see new counts.

Under Failed transcripts, the detail page can also show a number of calls marked as dropped (transcript deleted). These are calls that were deleted while the run was working.

Process Now, Pause, Resume, Retry, and Retry Failed are available from both the run list and the detail page. Cancel Run is available on the detail page.

Run statuses​

StatusWhat it meansWhat you can do
Not StartedThe request is saved but has not run.Process Now or Cancel Run.
In ProgressThe run is working through calls.Pause or Cancel Run.
PausedThe run stopped after its current batch and kept its checkpoint.Resume or Cancel Run.
SucceededThe run reached the end. Some calls can still be listed as failed.Retry Failed if any calls failed. Delete the run record.
FailedThe run stopped before the end. The failure message is shown on the detail page.Retry (continue from the checkpoint), Retry Failed, or delete the run record.
CanceledSomeone canceled the run on purpose. This is not a failure.Retry Failed if any calls failed. Delete the run record.

Pause, resume, and cancel​

  • Pause moves the run to Paused right away. The background work stops after the current batch is saved. Until then, the page shows that a pause was requested.
  • Resume continues a paused run from where it stopped.
  • Cancel Run stops a not-started, in-progress, or paused run. Like pause, the stop happens at the next batch boundary.

Calls that were already processed are never evaluated again when a run is resumed or retried.

Retry and Retry Failed​

These two actions do different things:

ActionAvailable whenWhat it does
RetryThe run status is Failed.Continues the whole run from the last saved checkpoint.
Retry Failed (N)The run is finished (Succeeded, Failed, or Canceled) and N calls failed.Re-evaluates only the N failed calls. Everything the run already saved is left alone. Each call that succeeds leaves the failed list.

While a Retry Failed pass runs, the detail page shows how many failed calls were attempted and how many were healed. After it finishes, the page shows the number of heal attempts and how many calls the last attempt recovered.

The Failed transcripts table lists each failed call with Attempts, Last attempt, and the Error. The page lists the first failed calls only, but Retry Failed works on all of them.

What happens when something fails​

One call fails​

A single call that cannot be evaluated is counted as failed and the run continues. The call keeps the values it already had. Use Retry Failed after the run finishes.

These cases do not count as failures:

  • Content-policy rejection. If the AI provider refuses a call's text because of its content policy, that tag batch or indicator is skipped for that call and keeps its previous value. The rest of the call is still evaluated. Retrying gives the same result.
  • AI rate limits (HTTP 429). WinnerWare pauses all requests for a short time and tries again. If a request is still throttled after many tries, that rule is left for a later run instead of stopping the run.
  • Short network problems or a request timeout. WinnerWare retries the request a few times, then leaves that rule for a later run.

Many calls fail in a row​

If every call in several batches in a row fails (three batches by default), WinnerWare stops the run with the status Failed. This usually means a system problem, not bad calls. Examples are a wrong or deleted AI deployment, expired credentials, or an exhausted quota. Fix the cause, then click Retry.

The run stops reporting progress​

A run that reports no progress for 30 minutes (by default) is marked Failed so it cannot block new runs. This usually happens when the application restarts or is redeployed during a run.

WinnerWare then resumes the run automatically from its last checkpoint:

  • A background task named Speech Transcript Retro Processing Recovery checks for stalled runs every 5 minutes, even when nobody has the admin screen open.
  • Automatic resume stops after 3 attempts in a row that make no new progress. The count starts again each time the run saves new progress, so a long run that is interrupted by several deployments keeps going.
  • When automatic resume stops, the run stays Failed with the message "The run was automatically failed after stalling...". Find the cause (see below), then click Retry.

A batch that legitimately takes a long time, for example because the AI deployment is slow or throttled, does not count as stalled. While a batch is still working, the run refreshes Last progress regularly (at most every 5 minutes).

Checklist when a run fails​

  1. Open the run and read the failure message and the Error column in Failed transcripts.
  2. Confirm that the default AI utility or chat deployment exists, has quota, and responds. See AI Deployments.
  3. If the deployment uses a non-reasoning model, clear the ReasoningEffort value (see Configuration).
  4. Click Retry for a failed run, or Retry Failed for the calls that failed.

Configuration​

Permissions​

PermissionPurpose
Manage Speech Transcript Retro ProcessingOpen the Retro Processing screen, create requests, and start, pause, resume, retry, and cancel runs.
Delete Speech Transcript Retro Processing RunsDelete finished run records, one at a time or with Delete Finished.

AI deployment​

Retro Processing uses the tenant's default Utility deployment, or the default Chat deployment when no utility deployment is set (Settings -> Artificial Intelligence). Only Semantics tags and indicators use AI. See AI Deployments.

Tuning settings​

A system administrator can tune retro runs in the CloudSolutions_SpeechInsights_RetroProcessing configuration section (for example in appsettings.json or the tenant configuration):

{
"CloudSolutions_SpeechInsights_RetroProcessing": {
"BatchSize": 10,
"MaxDegreeOfParallelism": 16,
"MaxConcurrentAiRequests": 32,
"RateLimitCooldown": "00:00:05",
"MaxRateLimitCooldown": "00:01:00",
"MaxRateLimitJitter": "00:00:01",
"MaxRateLimitRequeues": 10,
"MaxTransientRetries": 3,
"MaxConsecutiveFailedBatches": 3,
"AiRequestTimeout": "00:02:00",
"StaleProcessingAfter": "00:30:00",
"AutoResumeStalledRuns": true,
"MaxConsecutiveAutoResumes": 3,
"MaxSemanticTagsPerCall": 20,
"MaxSemanticTagCharsPerCall": 8000,
"ReasoningEffort": "Low"
}
}
SettingDefaultPurpose
BatchSize10Number of calls loaded and saved per batch. Progress is saved after each batch.
MaxDegreeOfParallelism16Number of calls prepared and sent to the AI pipeline at the same time.
MaxConcurrentAiRequests32Maximum number of AI requests in flight for the whole run. This is the main speed setting. Set it to match the deployment's quota. Throttled requests wait and try again, so a value that is too high slows down instead of failing.
RateLimitCooldown00:00:05Wait time after an HTTP 429 response that has no Retry-After hint. It grows under continued throttling.
MaxRateLimitCooldown00:01:00Longest wait after throttling, including the provider's Retry-After hint.
MaxRateLimitJitter00:00:01Small random extra wait so throttled requests do not all start again at the same moment. 00:00:00 turns it off.
MaxRateLimitRequeues10How many times one throttled request tries again before that rule is left for a later run.
MaxTransientRetries3How many times one request is retried after a network problem or timeout before that rule is left for a later run.
MaxConsecutiveFailedBatches3Number of batches in a row in which every call failed before the run is stopped as Failed. 0 turns this guard off.
AiRequestTimeout00:02:00Maximum time for one AI request. 00:00:00 turns the timeout off.
StaleProcessingAfter00:30:00Time without progress before a run is treated as stalled.
AutoResumeStalledRunstrueWhether a stalled run is resumed automatically.
MaxConsecutiveAutoResumes3Number of automatic resumes in a row, without new progress, before WinnerWare stops and leaves the run Failed. 0 turns automatic resume off.
MaxSemanticTagsPerCall20Maximum number of Semantics tags classified in one AI request. 0 removes the limit.
MaxSemanticTagCharsPerCall8000Maximum combined length of tag names and descriptions in one AI request. 0 removes the limit.
ReasoningEffortLowReasoning effort sent with each request: None, Low, Medium, High, or ExtraHigh. Leave it empty ("") when the deployment uses a non-reasoning model (for example GPT-4o), because those models reject the setting.

For more about reasoning effort and semantic tag batching, see Reduce latency on reasoning-capable models.

Usage​

Apply a new tag to older calls​

  1. Create the tag in Speech Insights -> Transcript Tags. Leave Active? off while you test it.
  2. Use Evaluate against existing transcripts on the tag to check a sample (see Speech Insights).
  3. Turn on Active? so new calls get the tag.
  4. Go to Speech Insights -> Retro Processing, click Create Retro Process, select the tag, and set a date range if you only need recent calls.
  5. Click Process Now and watch the progress.
  6. When the run finishes, use Retry Failed if any calls failed.

Keep runs small and focused​

  • Select only the tags and indicators that changed.
  • Use Clients, Ingestion Sources, and the date range to limit the run.
  • Run large back-fills outside busy hours, because retro AI requests share the same deployment quota as new call processing.

Operational Notes​

  • Only completed transcripts are evaluated. Calls that are still processing, failed, or abandoned are skipped.
  • Only one run can be active at a time. Finish, pause, or cancel the current run before you start another.
  • A run stores only the IDs of the selected tags and indicators. The detail page always shows the current names. A tag or indicator deleted after the run was created is skipped.
  • Deleting a run record removes only the record. The transcripts it evaluated keep their values.
  • Delete Finished deletes every succeeded, failed, or canceled run that matches the current filters. Active runs are not touched.