> ## Documentation Index
> Fetch the complete documentation index at: https://dialnexa.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Tpscheck

> Connect DialNexa calls to Tpscheck for address, route, appointment, booking, shipment, service job, phone validation, or site record workflows.

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.

<Note>
  Use Tpscheck with DialNexa when where, when, route, address, delivery, dispatch, phone validity, or appointment constraints affect the next step.
</Note>

## 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.

<CardGroup cols={2}>
  <Card title="Reduce failed visits" icon="check-circle">
    Flag invalid addresses, no-access risk, wrong region, unreachable number, or outside-service-area cases.
  </Card>

  <Card title="Validate location details" icon="check-circle">
    Confirm address, unit, landmark, timezone, territory, service area, and phone while the caller can correct errors.
  </Card>

  <Card title="Schedule with constraints" icon="check-circle">
    Capture preferred window, access notes, weather risk, delivery deadline, attendee count, or cancellation reason.
  </Card>

  <Card title="Prepare field teams" icon="check-circle">
    Send site context, equipment, safety notes, parts, parking, route, and customer expectations to the owner.
  </Card>
</CardGroup>

## 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

<AccordionGroup>
  <Accordion title="Route or branch owner must be selected">
    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.
  </Accordion>

  <Accordion title="Caller provides a new address">
    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.
  </Accordion>

  <Accordion title="Appointment needs rescheduling">
    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.
  </Accordion>

  <Accordion title="Dispatch needs access instructions">
    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.
  </Accordion>

  <Accordion title="Delivery is at risk">
    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.
  </Accordion>

  <Accordion title="Caller is outside service area">
    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.
  </Accordion>

  <Accordion title="Use check phone number">
    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.
  </Accordion>
</AccordionGroup>

## Workflows that pair Tpscheck with other integrations

* [Tpscheck](/integrations/tpscheck) + [Zendesk](/integrations/zendesk): Zendesk for field-service support tickets.
* [Tpscheck](/integrations/tpscheck) + [Google Maps](/integrations/google_maps): Google Maps for address and route context.
* [Tpscheck](/integrations/tpscheck) + [Google Calendar](/integrations/googlecalendar): Google Calendar for bookings and callbacks.
* [Tpscheck](/integrations/tpscheck) + [Slack](/integrations/slack): Slack for dispatch or operations alerts.
* [Tpscheck](/integrations/tpscheck) + [Gmail](/integrations/gmail): Gmail for confirmations after the call.
* [Tpscheck](/integrations/tpscheck) + [HubSpot](/integrations/hubspot): HubSpot for account territory context.
* [Tpscheck](/integrations/tpscheck) + [Shopify](/integrations/shopify): Shopify for delivery or order calls.
* [Tpscheck](/integrations/tpscheck) + [Google Sheets](/integrations/googlesheets): Google Sheets for low-confidence address review.

## 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

<AccordionGroup>
  <Accordion title="How should VIP buyers be prioritized?">
    Use order value, loyalty status, subscription status, repeat purchase, account tier, or urgent deadline to route faster.
  </Accordion>

  <Accordion title="What happens after a booking change?">
    Update the booking or calendar, send confirmation, log the reason, and notify operations if capacity or timing is tight.
  </Accordion>

  <Accordion title="How do you avoid acting on the wrong order?">
    Verify identity and match order ID, phone, email, product, and recent activity before making changes.
  </Accordion>

  <Accordion title="What should be sent to marketing afterward?">
    Only safe lifecycle signals such as product interest, return outcome, or follow-up need. Do not send sensitive support details.
  </Accordion>

  <Accordion title="Should DialNexa change orders automatically?">
    Only for low-risk changes with clear identity and policy rules. Address changes, refunds, cancellations, and substitutions often need review.
  </Accordion>

  <Accordion title="What order data should be checked first?">
    Customer match, order ID, fulfillment status, payment status, delivery promise, prior support notes, and return eligibility.
  </Accordion>
</AccordionGroup>