> ## Documentation Index > Fetch the complete documentation index at: https://docs.altheahealth.io/llms.txt > Use this file to discover all available pages before exploring further. # Call reporting Individual Call Reporting provides a structured record for each call handled by an Althea Voice Agent (inbound, outbound, test, campaign). You can export call records as a CSV for reporting, QA, compliance, and analytics workflows. This page explains: * What data is captured per call * How to interpret exported CSV or JSON files * The meaning of each analytics field * How teams typically use call reporting data *** ## What Is Individual Call Reporting? Every inbound, outbound, test, or campaign call produces a **call record** containing: * Metadata (IDs, timestamps, duration, direction, type) * Outcomes and analytics extracted from the conversation * Summaries and transcript content These records are visible in the UI under **Call History** and can be **exported as CSV** for external analysis. *** ## CSV export format You can export individual calls or batches of calls as a CSV file. * **One row = one call** * **One column = one field** * Timestamps are exported in **ISO 8601** (UTC, with `Z`) unless otherwise noted. The export is designed to support: * Operational monitoring * Clinical review * Compliance audits * BI dashboards * QA and model evaluation *** ## Field reference The table below documents columns in the individual call CSV export. > **Legend** > > * **Type** is the data type as exported in CSV (string/number/boolean/date/time). > * **Enum** lists all allowed values (where applicable). > * Fields marked **Analytics** are derived from the call transcript using the call analytics schema. *** ## Call metadata fields | Field | Type | Enum (all options) | Description | | ------------------ | ------------------: | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | `call_id` | `string` | — | Unique identifier for the call record (primary key). Example: `call-uva-a75a7b1f`. | | `org_id` | `string` | — | Organization ID (tenant identifier). | | `org_name` | `string` | — | Organization display name. Example: `Althea Health`. | | `patient_id` | `string` | — | Patient identifier in your tenant (may be internal or external). | | `patient_name` | `string` | — | Patient display name captured at export time. | | `patient_dob` | `string (date)` | — | Patient date of birth in `YYYY-MM-DD` format. | | `campaign_id` | `string` | — | Campaign identifier when the call is campaign-driven; may also represent an inbound routing or channel identifier depending on your setup. | | `campaign_name` | `string` | — | Campaign display name. For test calls, may reflect “Test Call”. | | `workflow_id` | `string` | — | Workflow identifier used to run the call flow. | | `workflow_name` | `string` | — | Workflow display name. | | `status` | `string` | `completed`, `initiated`, `ringing`, `in-progress`, `failed`, `no_answer`, `n/a` | Call status in the reporting layer. (Shown in the Call History UI.) | | `type` | `string` | `test`, `campaign`, `single` | Call type category. (Matches Call History tabs.) | | `direction` | `string` | `inbound`, `outbound` | Whether the call was inbound (patient called in) or outbound (agent placed the call). | | `duration_seconds` | `number` | — | Call duration in seconds (from call start to end). | | `created_at` | `string (datetime)` | — | When the call record was created in the system (ISO 8601). | | `updated_at` | `string (datetime)` | — | When the call record was last updated (ISO 8601). | *** ## Summary & transcript fields | Field | Type | Enum (all options) | Description | | --------------- | -------: | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------- | | `summary` | `string` | — | Long-form call summary (typically 3–5 paragraphs). This corresponds to the **extensive call summary** concept in the analytics schema. | | `short_summary` | `string` | — | One-sentence summary for tables and quick review (15–25 words). This corresponds to the **brief call summary** concept in the analytics schema. | | `transcript` | `string` | — | Full transcript for the call, usually including role labels like `User:` and `Agent:`. | *** ## Analytics and outcome fields The following fields are **derived analytics signals** extracted from the transcript. Types and enums below are defined by your call analytics schema. ### Routing, safety, and escalation | Field | Type | Enum (all options) | Description | | --------------------------- | --------: | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | `call_answered_by` | `string` | `human`, `voicemail`, `answering_machine`, `unclear` | **Who/what answered** the call, inferred from transcript patterns (interactive conversation vs voicemail greeting vs generic automated response). | | `call_purpose` | `string` | `post_discharge_followup`, `medication_reminder`, `appointment_reminder`, `health_check_in`, `symptom_monitoring`, `patient_education`, `satisfaction_survey`, `care_coordination`, `test_results_discussion`, `general_inquiry`, `complaint_resolution`, `other` | Primary purpose classification for the call based on content. | | `call_authenticated` | `boolean` | — | Whether the caller was successfully authenticated/verified as the patient. Nullable in schema; may appear blank when not applicable or not performed. | | `call_transferred` | `boolean` | — | Whether the call was transferred/forwarded to a human agent or another destination. Nullable in schema. | | `call_escalated` | `boolean` | — | Whether the caller requested escalation to a human agent. Nullable in schema. | | `urgent_follow_up_required` | `boolean` | — | Whether the call suggests urgent follow-up within 24–48 hours (clinical concern, worsening symptoms, critical issue). Nullable in schema. | | `do_not_call_again` | `boolean` | — | Whether the caller explicitly requests no future contact. Nullable in schema. | *** ### Callback and scheduling analytics | Field | Type | Enum (all options) | Description | | ------------------------- | --------------: | ------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `call_back_requested` | `boolean` | — | Whether the caller asked for a callback (explicitly). Nullable in schema. | | `preferred_callback_date` | `string (date)` | — | Specific requested callback date in `YYYY-MM-DD`, if specified. Nullable in schema. | | `preferred_callback_time` | `string (time)` | — | Specific requested callback time in `HH:MM` (24-hour), if specified. Nullable in schema. | | `callback_timeframe` | `string` | `today`, `tomorrow`, `this_week`, `next_week`, `this_month`, `next_month`, `in_2_weeks`, `in_3_weeks`, `specific_date`, `unspecified` | Generalized timeframe when the user requests a callback but doesn’t give a precise date/time. Use `specific_date` if an exact date was provided; `unspecified` if callback requested but no timeframe. Nullable in schema. | *** ### Sentiment and satisfaction analytics | Field | Type | Enum (all options) | Description | | --------------------- | -------: | ---------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | | `sentiment` | `string` | `very_positive`, `positive`, `neutral`, `negative`, `very_negative`, `mixed` | Overall emotional sentiment of the caller during the interaction. | | `caller_satisfaction` | `string` | `very_satisfied`, `satisfied`, `neutral`, `dissatisfied`, `very_dissatisfied`, `unclear` | Satisfaction with the interaction/outcome (distinct from sentiment; focuses on service experience). | **Why these differ** * Sentiment reflects *emotion* * Satisfaction reflects *service perception* *** ## Notes on blanks / nulls in CSV Some analytics fields are **nullable** in the schema and may export as blank values in CSV. Common reasons: * The topic was not discussed (e.g., no callback requested) * The feature was not enabled (e.g., authentication off) * The transcript did not contain enough signal to extract confidently *** ## How teams use call reporting ### Ops / QA * Filter by `status`, `type`, `direction` * Track answer outcomes with `call_answered_by` * Spot escalation rate using `call_escalated` and `call_transferred` ### Clinical / Care teams * Use `short_summary` for fast triage * Use `summary` for deeper review * Route calls where `urgent_follow_up_required = true` to human queues ### Analytics / BI * Aggregate by `campaign_id`, `workflow_id`, and `call_purpose` * Trend sentiment/satisfaction over time and by workflow * Measure callback demand and preferred timeframes *** ## Best Practices * Treat call analytics as **decision-support**, not clinical judgment * Use `extensive_call_summary` for review, not raw transcripts * Always honor `do_not_call_again` * Route `urgent_follow_up_required` signals to humans promptly * Combine CSV exports with campaign-level analytics for context *** ## Related pages * [Call History](call-history) * [Campaign History](campaign-history) * [Campaign Scheduling](campaign-schedule) * [Agent Settings](agent-settings) * [Prompting](prompting)