Dental provider check-in guide and follow-up templates

Provider retention pilot plan

For DSO and multi-practice teams | Suggested worksheet to agree during the demo and onboarding Use a small agreed scope and synthetic test records to prove the workflow. These are suggested acceptance checks, not additional product features, service commitments or a promised rollout timetable.

Pilot practices or provider group Pilot lead and decision owner Review date and agreed scope

Record evidence against each check

For each row, mark Pass, Fail or Not tested. Record evidence or an open action; leave untested items open.

Decision: Proceed / revise / stop Decision owner: ____________________

Open actions and next review: _________________________________________________

Confirm trial availability, duration and any payment requirements in your written quote before activation. Ask the DentalXpand team to confirm the trial start, included allowances, training and any setup or connected-service charges. The team handles account setup; use the walkthrough to agree the scope before activation. A trial can test the workflow; it cannot establish improvement in annual retention.

Run the weekly review

Suggested agenda and provider launch message | Adapt to your team before use Review date: __________________ Facilitator: __________________

Suggested weekly operating agenda

1. Check delivery and review exceptions. Identify failed invitations, missing eligible reviewers and practice-mapping issues. Agree who investigates each exception.

2. Review new concerns. Keep the provider's account separate from interpretation. Use the agreed alternate contact when a concern involves the usual manager.

3. Review due and overdue work. Confirm each action owner, review date and promised next update. Identify decisions requiring an authorized leader.

4. Confirm handoffs and outcomes. Check that the receiving owner accepts a handoff. Capture provider replies and distinguish closure from provider-confirmed resolution.

5. Leave with named next steps. Record the action, owner and due date for each open issue. Review actual workforce retention separately over a defined period.

Provider launch message to customize

Fill every bracket, confirm the response mode and access scope, and use only after the relevant services and reviewer assignments have been tested. This template has not been sent.

Subject: Your provider check-ins at [practice or group] Hello [provider or team], We are introducing DentalXpand check-ins to hear about your experience after joining and give concerns a clear owner and next step.

Your invitations will come from [verified sender]. The private email link opens without an Xpand login. Our response mode is [named or unnamed; confirm before sending]. [Authorized reviewer role or team] can read feedback for [confirmed scope]; [case-handling role] coordinates follow-up.

If unnamed responses are offered, the direct provider link is omitted from the response record. Invitation, participation and delivery records can still identify the intended recipient, and practice context or written details may reveal the author.

We will acknowledge concerns within [agreed standard] and provide the next update by [agreed standard or date]. If your concern involves your usual manager, contact [alternate review contact]. For help with an invitation, contact [support contact].

Thank you, [Name and role]

Assign system responsibilities

Suggested responsibility worksheet | Complete with your HR, operations and DentalXpand teams Decide which system is authoritative for each record and who keeps it current. This worksheet does not imply an integration or automatic synchronization. Confirm supported entry or import steps and service responsibilities during onboarding.

Agree maintenance and exception owners

For each change, name the responsible person or team and record how they will hand the work over. Confirm the available product steps during the walkthrough; do not assume that transfers or offboarding happen automatically.

Change or exception Responsible person or team Review or handoff route New hire, practice transfer or departure ______________________ ______________________

Reviewer leaves or access needs change ______________________ ______________________

Invitation fails or no reviewer is assigned ______________________ ______________________

Before launch: confirm each practice's eligible reviewer, alternate review contact, decision authority, service-activation owner and next-update standard.

Import and access field guide

Provider retention: prepare source records, review permissions and plan staff handoffs. This guide describes source-reviewed workflows. Confirm your deployed version and account permissions before using it as a launch checklist.

Start with the in-app workbook

Open Excel import and choose Download template & examples. Use the downloaded workbook for the current headers. This guide explains the process; it is not an import file.

Import requirement Supported format or limit Workbook .xlsx, up to 8 MB and 2,000 populated import rows Record sheets Candidates and/or Openings, one source record per row Reference sheets Instructions, Practices and Examples are not imported records Unsupported files Encrypted and macro-enabled workbooks Larger or unusually complex workbooks may need to be split into smaller batches.

Review before creating operational records

1. Confirm that the operational practices already exist and are accessible to the importing user.

2. Keep the template's sheet names and row-one headers unchanged. Prepare one source record per row.

3. Upload the workbook to stage source rows for review.

4. Review the original cells, identity, dates, office and hours. Record the review decision.

5. Mark an eligible row Reviewed, then create the appropriate operational record and explicitly confirm its fields.

Uploading stages evidence

An upload does not automatically create practices, update existing provider records, confirm hires or first days, send messages, verify credentials or sign agreements.

Keep restricted data out: do not include patient information, passwords, Social Security numbers or other credentials in the workbook.

Prepare the workbook fields

Use the current downloaded template | Preserve exact sheet names and header order

Candidates sheet

Exact supported header order Candidate; First name; Last name; NPI; Email; Phone; Target Office; Position; Status; Hired date; Hours; Hours period; Daily rate (USD); Production percentage; Bonus (USD); Misc; H1B; Referred by; Source; Notes Required: Candidate for each populated source row. Target Office can be blank for an unassigned candidate.

A source row is not a verified identity; names, contact information and NPI support review but do not trigger an automatic merge.

Openings sheet

Exact supported header order Target Office; Position; Opening title; State; Providers needed; Status; Date identified; Target start date; Hours; Hours period; Daily rate (USD); Production percentage; Bonus (USD); Misc; Notes Required: Target Office and Position for each populated source row. Use the exact existing practice name, then select the matching practice during review. Workbook text does not establish a practice link; an authorized user must create a new location first.

Apply these format rules

– Headers: do not add unrecognized columns or duplicate headers.

– Dates: use a real calendar date in YYYY-MM-DD format, such as 2026-11-02. Review dates even when raw staging accepts the source text.

– Hours: use a number and record the period. Leave unknown hours blank rather than treating them as zero.

– Rates: daily rate and bonus are USD numbers. Enter 30 for a 30% production percentage, not 0.30.

– Identifiers: preserve NPI as text; use a verified identifier when available or leave it blank. Use the appropriate two-letter U.S. state code when applicable.

– Unknown fields: leave them blank. Additional identity, ownership, status, evidence and practice fields may be needed when creating an operational record.

Create versus update

The review flow creates a new operational record from an eligible reviewed source row. It is not a bulk update or automatic merge. If the intended provider or application already exists, reconcile the identity and use the appropriate existing-record workflow rather than creating a duplicate.

Review rows and exceptions

Clearly fictional teaching examples | Not customer data, screenshots, completed tests or live import records Re-uploading an identical file resumes the same batch without recreating already staged source rows. A changed file is a new batch. Repeated content within a workbook is flagged and cannot be promoted through the normal review action. This does not promise detection of every cross-file identity duplicate.

Example A Clean candidate source row

Field Fictional value Candidate / name EXAMPLE Provider A / first name: Example / last name: Provider A Email / office provider-a@example.test / DEMO North Clinic Position / status General Dentist / candidate Hours / period 24 / weekly Source / notes Fictional training example / Synthetic record for an isolated demonstration only All other fields Blank, including NPI and Hired date. No phone number or personal address is invented.

The reviewer still confirms identity and maps the practice. This row does not establish employment or actual worked capacity.

Example B Repeated source content

The same complete Candidate row appears twice. The importer flags it and points to the earlier row. Reconcile the repeated content; the duplicate row cannot be promoted normally.

Example C Missing or unmatched practice

Blank Openings office: rejected at upload because Target Office is required. Unmatched DEMO New Clinic: nonblank text can stage; create or obtain access to the correct practice and select it during review. Blank Candidate office: allowed at staging; decide the office later.

Practice matching is an explicit review step, not an automatic importer lookup warning.

Example D An invalid date

Target start date = 2026-02-30. Raw staging preserves source text and does not fully validate every date.

Confirm the intended date, document the decision and enter a valid calendar date when creating the operational record, retaining the original source evidence. Do not treat this as an automatically detected upload error.

Review DSO access defaults

Survey results, delivery records and internal notes | A starting point for account-by-account review These defaults describe a newly configured DSO workspace, with active accounts and the relevant product access. They are not guarantees based on job title. Existing organizations, explicit per-person grants, exclusions and assigned practices can differ.

Check the permission layers separately

– Survey-review authority, case-handling authority and internal-note authority are separately configured. One does not automatically imply the others.

– Access controls can explicitly grant or revoke survey, feedback and internal-note permissions for non-admin members. An added grant remains limited by account and practice scope.

– Internal-note access requires feedback/case authority as well as the relevant internal-note grant.

– Organization owner/admin access is managed through role assignment, rather than individual feedback toggles.

– A provider's ability to submit through an invitation link does not make them a survey reviewer.

– A practice-summary survey score is separate from raw feedback access. The standard DSO summary suppresses scores with fewer than three scored responses.

Before requesting feedback: inspect the actual intended accounts and practice assignments, including any explicit grants or exclusions.

Cases and practice transfers

Case visibility and historical practice context | Review the actual workspace configuration The role defaults below use the same newly configured DSO assumptions as the access-defaults section above. Private manual cases and survey-linked cases use different authority and ownership rules.

Explain named and unnamed responses accurately

Named responses retain a provider link. Unnamed responses omit the direct provider link but retain practice context. Invitation and delivery tracking remain separate; participation tracking does not prove who wrote a particular unnamed response. Comments or a small group can still make a person recognizable.

Do not promise complete anonymity or immediate deletion of information someone has already viewed.

Fictional transfer DEMO North to DEMO South

An authorized administrator updates the provider's current assignments. If the provider works at both practices, record both explicitly. Changing the primary location alone does not remove every previous assignment.

Existing cases and support requests keep their original practice context. A survey response stays with the practice on its invitation, even when submitted after the transfer; named responses also retain their provider link. New work uses its selected or current practice context.

A destination-practice reviewer does not automatically gain access to historical survey responses from the original practice. Evaluate current permissions and practice assignments separately from historical record ownership.

Prepare reviewer continuity

Plan handoffs before removing access | Proposed checks for an isolated prelaunch test

When a reviewer leaves

1. Identify open cases, pending handoffs and promised update dates.

2. While the current manual-case owner still has access, use the ownership handoff and have an eligible recipient accept it. Review dates do not reset.

3. For DSO survey-linked cases, an authorized survey/case reviewer can select another eligible active owner through the survey follow-up workflow and record a due date, status and note.

4. Separately, have the authorized administrator remove or change the departing reviewer's account and practice access.

5. Verify that the remaining team can see and act on the appropriate records, and that each intended practice still has an eligible survey handler.

Important exception: account deactivation is not a verified automatic reassignment of all open work. The reviewed source does not establish a universal automatic takeover process for every private manual case after its owner has already left. Rehearse that exception with the implementation team.

Prelaunch review checklist

These are proposed checks. This guide does not claim they have been executed against a customer or production workspace.

Confirm the customer workspace's access model, deployed version and assigned practices.

Verify the exact downloaded import template, one clean row and each relevant exception in an isolated test.

Verify actual role views with the intended provider, practice and regional-reviewer accounts.

Demonstrate a provider transfer without moving historical responses to the wrong practice.

Demonstrate an accepted manual-case handoff and survey-case reassignment before reviewer access removal.

Confirm the no-eligible-reviewer response path and agree an operational recovery contact.

Review owner: _____________________ Date: _____________________

Open exceptions and recovery contact: ______________________________________