Try the integration queue.

Your backlog, one active request

Bring a prioritized backlog of new connectors, vendor API updates, fixes, and tests. We work one request at a time and agree its scope and acceptance criteria in writing before work starts.

When a request is finished, we move to the next agreed priority. Larger requests are split into milestones your team can test and review; the trial does not promise a fixed number of completed requests or a complete integration in two weeks.

An access-ready kickoff

The two-week window starts at a mutually agreed kickoff once access is ready. Before kickoff, we agree the first priority, a realistic first reviewable milestone, your reviewer, and the review plan.

The trial contains 14 counted calendar days, with the kickoff date counted as day one. Active client-review days and weekends count; this is not a promise of daily or weekend availability. Sandbox or test credentials are preferred; do not send them through the contact form.

Timing, priorities, and corrections

Client or vendor delays

Recorded client or vendor blocks that prevent all agreed work stop both the trial-day count and first-week decision window. If another agreed queued request can proceed, work and the clock continue. Both parties confirm revised dates and restart availability in writing.

Request priorities and scope

You may reorder requests that have not started. Changes to an active request need written agreement on scope, acceptance criteria, and the remaining trial schedule; a new priority does not add trial days or change the trial fee.

Reviews and corrections

Name the reviewer and review dates before kickoff. Active client-review days count as trial days. QCC-caused delay or corrections are not client or vendor blocks; missed milestones and any remedy are recorded explicitly. The end of the trial does not imply that unfinished work was completed or accepted.

Trial schedule adjustments are not banked subscription days. Subscription pauses and Subscription cancellation do not apply to this paid queue trial.

The trial does not automatically start a subscription. Ongoing work is a separate agreement.

Scope and acceptance first

Each request starts with a written scope and acceptance criteria your reviewer agrees to. Larger requests are split into smaller milestones, each one testable and reviewable on its own.

Estimates you can follow

• An initial estimate once scope, access and vendor requirements are understood.
• Uncertain discovery work, such as undocumented vendor behavior, is named and timeboxed.
• When facts change, QCC updates the estimate explicitly and says what changed.

Progress in your existing tools

QCC reports in the issue tracker and repository your team already uses:

• Status and the current milestone
• Reviewable pull requests with test evidence
• The next step and any blockers
• A weekly asynchronous progress summary

The subscription is not sold by hours or connector count, and turnaround depends on each request's agreed scope.

These rules apply only to the monthly subscription, not the paid queue trial.

Cancelling is separate from pausing. Pausing stops work and the paid-day clock; cancelling stops future renewals.

Cancelling does not have to stop the service you have already paid for. When you cancel, QCC asks whether you want to use your remaining balance now or pause it for later.

After an ordinary cancellation, unused paid days remain as non-refundable service credit. The credit does not expire and restarts on a mutually confirmed date, like any other pause.

Using that credit never re-enrolls you or triggers another charge. Renewed service after it runs out needs a separate agreement.

Ordinary cancellation does not produce a pro-rata refund. If QCC ends the relationship or cannot reasonably provide the remaining service, QCC refunds the unused portion. Refunds required by law still apply.