1. Status and scope
DRAFT — requires professional review before launch. Bracketed items must be completed, and this policy must be reconciled with the final production configuration before AnswerWing receives real patient traffic.
This draft covers the AnswerWing website, trial-request form, authenticated client dashboard, post-call webhook service, alert delivery, and weekly reporting. It does not replace a dental or medical practice's own privacy notice and does not describe independent practices by which a voice, hosting, communications, or scheduling provider uses data outside AnswerWing's instructions.
2. Our role
For account, website, and trial-request data, [Legal entity name] determines why and how the data is used. For patient call information processed to provide services to a customer practice, AnswerWing generally acts on that practice's instructions, while the practice remains responsible for its relationship with patients, lawful notices, recording consent, clinical protocols, and data requests.
This description is operational, not a legal conclusion. Counsel must determine the correct privacy and healthcare-law roles for each deployment.
3. Information we collect
Trial and business inquiries
The trial form collects the requester's name, practice name, business email address, and telephone number. The current service stores these fields encrypted and makes them available only to a founder-role account for follow-up.
Practice and account data
We store practice name, time zone, configured appointment value, alert destinations and verification status, approved service settings, user email, password hash, role, session records, and account timestamps. Passwords are not stored in readable form.
Patient call and message data
After a connected voice provider completes a call, AnswerWing may receive a call identifier, caller telephone number and name, start and end times, transcript, recording URL, summary, language, outcome, urgency, transfer result, appointment-channel flags, booking-failure flags, message content, and other structured fields in the documented webhook contract. Transcript and recording fields are optional and depend on voice-provider configuration.
Operational data
We store delivery status, provider message identifiers, retry counts, report calculations, scheduler and worker heartbeat timestamps, and opaque request identifiers. The application logger is allow-listed and is designed not to log caller names, telephone numbers, transcripts, summaries, recording URLs, request bodies, or provider response bodies.
Website and browser data
The current public site does not include an advertising tracker or analytics SDK. It loads fonts from Google Fonts and public JavaScript resources from cdnjs; those providers receive ordinary request metadata such as IP address and browser information. Hosting and network providers may also process standard request metadata. The public site uses browser session storage for presentation state, and the dashboard uses session storage for its signed-in session.
4. How we use information
- provide and secure the website, dashboard, webhook ingestion, message inbox, call history, and weekly reports;
- route completed-call outcomes and display call information to authorized users;
- send urgent practice alerts, founder lead alerts, calendar-failure alerts, service-health alerts, and report emails;
- respond to trial requests and perform manual onboarding;
- authenticate users, isolate practice data, prevent duplicate webhooks, investigate abuse, and maintain service reliability;
- comply with valid legal obligations and protect the rights and safety of users, practices, AnswerWing, and others.
The current service does not sell personal information or use patient call information for targeted advertising. Any future materially different use requires an updated notice and, where required, permission.
5. Calls, transcripts, and recording
The rented voice provider—not this repository—places or answers calls and may create audio recordings, transcripts, and analysis according to its configuration. AnswerWing receives post-call information and may store an encrypted recording URL rather than the audio file itself. Accessing that URL may cause the voice or recording provider to process the request.
Call-recording, wiretap, consent, and automated-assistant disclosure rules vary by jurisdiction. Each customer practice must obtain professional advice, configure legally sufficient notices and consent, and decide whether recording and transcription should be enabled. AnswerWing must not be treated as the practice's legal or clinical advisor.
6. Service providers and disclosures
The planned production configuration uses the following categories and providers. The founder must confirm the final list, eligible services, data locations, contracts, subprocessors, and any required BAAs before launch.
- Hosting and database: Railway and managed PostgreSQL host the application and stored records.
- Voice engine: Vapi is the primary provider for calls, transfers, recordings, transcripts, and post-call analysis before it sends an authenticated webhook. Synthflow is retained only as an alternate integration for deliberately configured legacy clients.
- SMS: Twilio processes alert recipient numbers, PHI-minimized alert text by default, and delivery status.
- Email: Resend processes alert/report recipient addresses, message content, and delivery status.
- Public-page resources: Google Fonts and cdnjs receive standard browser request metadata when those hosted assets load.
Information may also be disclosed when directed by the relevant customer practice, with the person's permission, during a properly structured business transaction, or when reasonably necessary to respond to lawful process or protect rights and safety. This paragraph requires counsel review.
7. Security
Current technical safeguards include HTTPS requirements in production; managed-database transport encryption; AES-256-GCM application encryption for caller phone and name, transcript, recording URL, summary, message body, trial-request fields, practice alert contacts, and delivery recipients; hashed passwords and webhook credentials; short-lived access tokens and rotating refresh tokens; practice-scoped authorization; verified alert contacts; and PHI-safe application logging.
No safeguard makes a system risk-free. Encryption and access controls are not a legal certification. The production launch remains gated on vendor-contract review, access and retention decisions, incident procedures, backups, restoration testing, and professional privacy/security review.
8. Retention and deletion
Retention schedule not yet approved. Before launch, the founder and counsel must define periods for call records, recordings at the voice provider, transcripts, messages, reports, delivery logs, account records, trial requests, backups, and provider copies.
Until a final schedule is implemented and documented, this draft must not promise a fixed deletion period. Backups and provider systems may retain copies for separate periods. Customer contracts should address return, export, deletion, legal holds, and termination.
9. Choices and privacy rights
People may ask about access, correction, deletion, or another applicable privacy right by contacting the address below. When the request concerns a patient call handled for a customer practice, AnswerWing may refer the request to that practice and assist it as contractually and legally required. Identity and authority must be verified before disclosing data.
Service alerts are operational communications, not marketing subscriptions. A practice that no longer wants them must update its verified alert contacts or service configuration without disabling safety-critical routing unintentionally.
Children
The AnswerWing website and business trial form are directed to practice operators, not children. Patient calls may concern minors as part of a practice's services; the practice remains responsible for its notices, authority, and instructions for that data.
10. Contact and policy changes
Privacy questions and requests should be sent to [privacy contact email] or [legal entity name and mailing address].
The final policy should state an effective date and explain how material changes are communicated. This draft date is not an effective date.