Skip to main content
TPSCheck is a service that verifies in real-time if a phone number is registered with the UK’s Telephone Preference Service (TPS) or Corporate Telephone Preference Service (CTPS), providing insights on validity, location, type, and provider of the number.
Use Tpscheck with DialNexa when where, when, route, address, delivery, dispatch, phone validity, or appointment constraints affect the next step.

​
Where Tpscheck fits in a DialNexa workflow

Tpscheck should receive DialNexa output when the conversation affects a address, route, appointment, booking, shipment, service job, phone validation, or site record. The handoff should explain what the caller asked for, what DialNexa learned, which record or object is affected, and who owns the next step.

Reduce failed visits

Flag invalid addresses, no-access risk, wrong region, unreachable number, or outside-service-area cases.

Validate location details

Confirm address, unit, landmark, timezone, territory, service area, and phone while the caller can correct errors.

Schedule with constraints

Capture preferred window, access notes, weather risk, delivery deadline, attendee count, or cancellation reason.

Prepare field teams

Send site context, equipment, safety notes, parts, parking, route, and customer expectations to the owner.

​
What DialNexa should capture for Tpscheck

  • Customer, phone, email, address, coordinates, region, timezone, booking ID, job ID, or shipment ID
  • Requested time, access note, delivery status, service issue, cancellation reason, weather or route risk
  • Territory, branch, technician, host, owner, SLA, and next window
  • Transcript link, recording link, DialNexa call ID, calendar link, order link, map link, and ticket link
  • Risk flags such as invalid address, no access, unsafe condition, VIP, or outside service area

​
High-value Tpscheck workflows

For this workflow, DialNexa should confirm location details, access notes, timing constraints, and the operational owner before updating Tpscheck. Low-confidence addresses or risky visits should go to review.
For this workflow, DialNexa should confirm location details, access notes, timing constraints, and the operational owner before updating Tpscheck. Low-confidence addresses or risky visits should go to review.
DialNexa should capture the preferred time, timezone, owner, promise made, and contact channel before updating Tpscheck. The receiving team should see exactly why the follow-up exists and what the caller expects next.
For this workflow, DialNexa should confirm location details, access notes, timing constraints, and the operational owner before updating Tpscheck. Low-confidence addresses or risky visits should go to review.
For this scenario, DialNexa should treat Tpscheck as an escalation destination. Send the impact, urgency, affected customer or object, owner, and transcript link so the right team can act before the issue gets colder.
For this workflow, DialNexa should send Tpscheck a concise, action-ready handoff: matched caller, affected record, reason for the update, urgency, owner, next step, and links to call evidence.
Use check phone number when the call outcome maps clearly to that operation and the required fields, owner, review state, and evidence links are known.

​
Workflows that pair Tpscheck with other integrations

​
Implementation notes

  • Use the DialNexa call ID as the idempotency key before running Tpscheck actions.
  • Write a short operational summary into Tpscheck and link to the full transcript or recording for audit.
  • Map required fields before launch: destination object, owner, status, urgency, next step, and record URL.
  • Create review paths for low-confidence matches, sensitive requests, high-value customers, and actions that change money, access, legal terms, or customer commitments.

​
FAQs

Use order value, loyalty status, subscription status, repeat purchase, account tier, or urgent deadline to route faster.
Update the booking or calendar, send confirmation, log the reason, and notify operations if capacity or timing is tight.
Verify identity and match order ID, phone, email, product, and recent activity before making changes.
Only safe lifecycle signals such as product interest, return outcome, or follow-up need. Do not send sensitive support details.
Only for low-risk changes with clear identity and policy rules. Address changes, refunds, cancellations, and substitutions often need review.
Customer match, order ID, fulfillment status, payment status, delivery promise, prior support notes, and return eligibility.