XPARK — Extended Park

What XPARK Means

A call that was parked for an extended period and remained parked beyond the normal park timeout. The contact may have been waiting on hold for an unusually long time during a complex transfer scenario.

When This Status Is Set

XPARK is assigned when a parked call exceeds the configured park timeout duration — meaning the contact was placed on hold in a parking lot extension and waited beyond the maximum allowed hold time without being retrieved by an agent. When the park timeout fires, the system either routes the call to a fallback destination (overflow queue, voicemail, or specific agent) or drops the call entirely, depending on the Asterisk dialplan configuration. XPARK indicates a breakdown in the transfer workflow: either the original agent parked the call and forgot about it, the receiving agent was unavailable, or the transfer coordination took longer than anticipated. The contact experienced an extended hold with no human interaction, which almost always results in frustration.

Impact on List Management

XPARK leads should be excluded from standard dial_status_filter recycling because these contacts had a negative experience and need careful re-engagement. Rather than throwing XPARK leads back into the predictive dialer, route them to a manual-dial campaign where a senior agent can call back with context about the failed transfer and offer an apology. The call notes and park duration data from the original interaction should be available to the callback agent so they can acknowledge the inconvenience. Track XPARK volumes as a quality metric — any XPARK events indicate that the transfer workflow has a failure point that needs to be addressed operationally. High XPARK counts mean either the closer team is understaffed for the transfer volume, agents are parking calls without proper handoff coordination, or the park timeout is set too short for the complexity of the transfer process.

Best Practices

• High XPARK counts indicate transfer workflow issues — investigate the root cause before it becomes a systemic problem

• XPARK contacts should be flagged for priority manual callback with an apology and a brief explanation — this preserves the relationship and often recovers the opportunity

• Review park timeout configuration to prevent excessive hold times — increase the timeout if the transfer process legitimately requires more time, or add a fallback queue that catches timed-out parks

• Train agents to verify closer availability before parking a call — parking a contact when no closer is available guarantees an XPARK outcome

• Track XPARK-to-SALE conversion rate on manual callbacks to measure how effectively your team recovers from failed transfers

Admin Configuration

XPARK is a system-level status defined in Admin → System Statuses with callable set to N. The park timeout duration that triggers XPARK is configured in the Asterisk dialplan’s parking context — typically parkingtime in features.conf or the equivalent ARI/AMI configuration. The fallback routing for timed-out parks (where the call goes after XPARK fires) is defined in the dialplan’s park-timeout context. Campaign Detail → Transfer Options controls the parking features available to agents. To monitor XPARK events, query vicidial_log for status = 'XPARK' or use the real-time report to watch for active parked calls approaching the timeout threshold. Recurring XPARK issues should trigger a review of closer team staffing levels relative to transfer volume.

ViciStack’s List Management module monitors disposition distribution in real time — automatically adjusting recycling logic, dial_status_filter priorities, and hopper fill strategies based on how your dispositions are trending. No manual SQL, no spreadsheet audits.