Quo

View saved version →

---
name: quo
description: How to use the Quo MCP tools well. Covers picking the right tool, chaining IDs between tools, texting and calling customers safely, and working with Sona, Quo's AI agent. Use whenever the user asks about their Quo (formerly OpenPhone) workspace, for example their messages, calls, voicemails, contacts or tasks, or asks to text or call someone, have Sona handle a conversation, or check, correct or add to what Quo's AI agents know about their business, including feedback like "the agent quoted the wrong price".
---

# Using Quo

Quo is a business phone system. The Quo tools work on the user's real workspace. Texts and calls reach real people and can't be taken back, so read carefully and confirm before acting.

## Start here

- **Find the user's numbers first.** Call `list-inboxes` before any tool that needs an inbox (`from`, `inboxPhoneNumber`). Don't guess a number. If the user has several inboxes and it isn't clear which one they mean, ask.
- **Find people with `list-users`.** It returns user IDs (`US…`) for filters and task assignment.
- **Phone numbers:** pass bare E.164 to tools (`+15555555555`). Show them to the user as click-to-call links, e.g. [(555) 555-5555](tel:+15555555555).
- **Copy IDs, never invent them.** Every ID comes from an earlier tool result: `PN…` inbox, `CN…` conversation, `AC…` call or message activity, `US…` user, `TK…` task, plus run, interview and message IDs.

## Reading the inbox

| The user wants | Use |
|---|---|
| Recent texts, or one thread | `fetch-messages` |
| What was said on calls | `fetch-call-transcripts` (Business plan, transcription on) |
| Missed calls and voicemails | `fetch-missed-calls` |
| Who someone is | `list-contacts`, `get-contact`, `list-contact-notes` |

- Pass `participantPhoneNumber` to read one person's full history. Leave it out for an overview of the whole inbox.
- For a group thread, pass the group's exact roster as `participantPhoneNumbers`. Copy it from an inbox overview rather than building it by hand.
- Narrow by time with `createdAfter` / `createdBefore`, written as ISO 8601 with a timezone (`2026-01-01T00:00:00Z`). Work out relative dates ("yesterday", "this week") in the user's timezone.
- `excludeDoneConversations: true` skips threads the user has already marked done.
- To get more results, pass `pageToken` / `conversationPageToken` from the previous result, with the same other parameters. Stop once you have enough to answer; don't page through everything.
- "0 messages" or "0 transcripts" is a real answer, not an error.

## Acting on what you read

Result rows carry IDs you can pass straight on:

- **Follow-ups:** `create-task`. Link the task to the most specific thing available: `activityId` (`AC…`, one call or message) beats `conversationId` (`CN…`, the whole thread), which beats `inboxPhoneNumber`. `update-task` makes one change per call.
- **Triage:** `mark-conversations` marks up to 50 `CN…` IDs as `read`, `done` or `open`. It never sends anything.
- **Contacts:** `create-contact` / `update-contact`. Pass `null` to clear a field. Add context with `create-contact-note`.

## Texting people

Pick by what the user actually wants:

| The user wants | Use |
|---|---|
| One text, sent exactly as written | `send-message` |
| The same text to many people, each privately | `send-bulk-messages` (up to 40) |
| One shared thread where everyone sees everyone | `send-group-message` (2–10) |
| Sona to handle a back-and-forth until a goal is met | `start-agent-conversation` |

- Before sending, show the from number, the recipients and the exact text, and wait for a clear yes.
- A group message reveals every recipient's number to the others. If the user didn't clearly ask for a group thread, use `send-bulk-messages` or `send-message`.
- `send-message` doesn't watch for replies. If the user expects replies to be handled ("confirm her appointment", "find a time that works for him"), that's a job for Sona.
- Maximum 1,600 characters per text.

## Wo

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: quo-conversation-insight-log
description: Create a bounded, passive, prioritized insight log from recent Quo messages, transcribed calls, missed calls, and voicemail transcripts through the Quo MCP. Use for call-log templates, recent customer-conversation reviews, daily or weekly communication digests, and finding important requests, risks, opportunities, commitments, or follow-ups in Quo with ChatGPT or Claude. Do not use it to claim complete call analytics, call volumes, or coverage of answered calls without transcripts.
---

# Quo Conversation Insight Log

Build a decision-useful log of recent customer conversations. Treat this as qualitative conversation review, not an analytics export.

Before running, read [prioritization.md](prioritization.md) and [output-template.md](output-template.md).

## Set the window

1. Use the user's explicit start and end when provided.
2. Otherwise, set `since` to 00:00 seven calendar days before the run in the user's timezone and set `through` to the current time.
3. If the user asks for changes since a previous run, use the previous log's exact `through` timestamp. If it is unavailable, use the seven-day default and disclose the fallback.
4. State the human-readable window, timezone, and exact ISO-8601 boundaries at the top of the result.
5. Never silently query all history. Do not default to more than seven days.

Example default for a run on July 24, 2026 in America/Toronto:

```text
Since: 2026-07-17T00:00:00-04:00
Through: <current time in America/Toronto>
```

## Read Quo safely

Use the Quo MCP tools by capability; exact tool prefixes may differ between ChatGPT and Claude.

**Run every Quo fetch sequentially. Never issue parallel, concurrent, batched, or `Promise.all`-style MCP requests. Only one inbox and one fetch operation may be active at a time.**

1. Call `list-inboxes` to discover accessible inboxes. Respect an inbox or owner filter from the user; otherwise review all accessible inboxes.
2. Choose the first inbox. Do not start work on any other inbox yet.
3. Call `fetch-messages` for that inbox with `createdAfter` and `createdBefore`. When `participantPhoneNumber` is omitted, do not rely on `maxResults`: the whole-inbox handler ignores it. Review and normalize the result before making another MCP call.
4. Interpret whole-inbox message coverage signals exactly:
   - `[next_conversations: TOKEN]`: continue sequentially with `conversationPageToken: TOKEN`.
   - `[incomplete: N more participant(s) ...]`: there is no pagination token for the omitted participants. Narrow the time window or query a known high-priority contact with `participantPhoneNumber`; otherwise disclose incomplete participant coverage.
5. Finish or stop the inbox's message stream before proceeding. Do not treat `[incomplete]` as a `conversationPageToken` signal.
6. Call `fetch-call-transcripts` for the same inbox and window with `maxResults: 100`. Review and normalize the result before making another MCP call. Follow `conversationPageToken` for older discovery batches; use `participantPhoneNumber` with `pageToken` only for a requested or high-priority contact drill-down.
7. Call `fetch-missed-calls` for the same inbox and window as a third sequential stream when the tool is available. Include useful voicemail transcripts and preserve returned recording URLs as sources. Pass only arguments supported by the active tool schema and follow its returned pagination or coverage signals exactly. If the tool is unavailable, state that missed calls and voicemails were not reviewed.
8. Finalize and compact that inbox's candidates. Discard full raw transcript and message text that is no longer needed.
9. Only then move to the next inbox and repeat steps 3–8. Do not prefetch, overlap, or queue calls for later inboxes.
10. Default to at most three tokenized pages per stream and inbox; stop earlier once the boundary is covered. If the window is still incomplete, disclose the cap and offer a narrower inbox, owner, conta

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: "quo-sales-lead-scoring"
description: Score and prioritize new sales leads from a small business's Quo calls, voicemails and texts, then write results back into Quo — a 0–100 score, tier and stage on saved contacts, a note explaining it, and a follow-up task with assignee, due time and draft text. Runs twice daily (morning covers after hours, evening covers the business day) for home services, cleaning, law firms, agencies and franchise locations. Use whenever someone asks to score, rank or prioritize leads, "who should we call back first", "which leads are hot", "run lead scoring", "set up lead scoring", "adjust my lead scoring weights", or wants follow-up tasks from recent sales calls. Do NOT use for a general what-came-in digest (quo-daily-report), texting every missed caller (quo-missed-call-followup), call quality coaching (sales-call-coaching, daily-call-review), win-loss analysis, real-time urgent alerts, or call volume and answer-rate metrics.
---

# Quo Sales Lead Scoring

Owners of small businesses don't want a lead score for its own sake. They want to know who to call back first, what to say, and who is about to go to a competitor. This skill reads the Quo line, scores every new sales lead, picks one next step per lead, and leaves the result inside Quo where the team already works. The score is how the list gets sorted; the task is what gets the work done.

Two runs a day cover the whole day with no gaps and no overlap:

| Run | Default time | Window | Leads with |
|---|---|---|---|
| **Morning** | 30 min before open | last evening run → now | Callback order: unanswered leads first, with draft texts |
| **Evening** | 45 min after close | last morning run → now | Scored pipeline, follow-ups due tomorrow, response-time check on the morning's Hot leads |
| **Backfill** | on request | explicit range, max 7 days | Used at setup to calibrate. Never writes to Quo and never moves the run cursors |

If the user names a mode, use it. Otherwise infer from local time in the configured timezone: before 12:00 → morning, 12:00 or later → evening. Say which mode ran and why in one clause, so a wrong guess is easy to spot.

**What this skill is not.** It is not an alert system. A burst pipe at 9pm can't wait for a twice-daily report; urgent alerts belong in Quo's own routing, AI call tags, or a webhook. This skill sees what those systems did only through what reaches Quo's conversations, tasks and contact fields (for example, an outbound reply), and checks the next run that urgent leads were actually handled. The Quo MCP does not expose call tags or contact tags today, so don't look for them or claim to have read them.

## Before running

Read these files when you reach the step that needs them:

- [references/setup.md](references/setup.md) — config template and the setup interview. Read first if no config exists, or when the user asks to change settings or weights.
- [references/retrieval.md](references/retrieval.md) — how to pull Quo data without silently dropping activity. Read before step 2 of every run.
- [references/scoring.md](references/scoring.md) — factors, hard rules, tiers, confidence, re-scoring. Read before scoring.
- `references/rubrics/<industry>.md` — the signals for this business's industry. Read the one named in the config.
- [references/actions.md](references/actions.md) — which task to create, what to write to Quo, and the guardrails. Read before writing anything.
- [references/output-template.md](references/output-template.md) — the report format. Read before writing the report.

## Configuration

Look for a config before asking anything. It lives as a Notion page titled `Quo Sales Lead Scoring — [Business or Location]` when Notion is connected, otherwise as `quo-sales-lead-scoring-config-[slug].md` in the working folder. Franchises get one config, one pair of scheduled runs and one report per location.

No config means run setup per [references/setup.md](references/setup.md). A config with a blank fi

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 11 — file references are metadata, not package contents.

View saved version →

---
name: "quo-service-scorecard"
description: "Build a weekly customer service scorecard for each rep on a small business phone team (home services, cleaning, law firms, franchises, agencies), scored from Quo call transcripts on a weighted rubric (compliance gate, solution, empathy, tone, clarity, efficiency, closing, greeting). Outputs a Google Sheet with a team summary, per-rep scorecards with quoted evidence, a call log with manager overrides, and trends. Use whenever a manager or owner wants to score, grade, QA, or review their team's service calls, for example 'run the weekly scorecard', 'score my reps' calls', 'customer service QA for last week', 'how is my front desk doing on the phones', 'which CSR needs coaching', or wants Quo's scorecard template filled in from real calls. Not for one-person sales coaching (sales-call-coaching), daily team call scoring (daily-call-review), or call volume and answer-rate reporting."
---

# Quo customer service scorecard

This skill produces a weekly scorecard a manager uses to review every rep's customer service
calls. It is based on Quo's customer service scorecard template, adapted for phone calls:

- The template's **weighted criteria and auto-fail compliance gate** are kept.
- Criteria that only fit written channels are **swapped for phone equivalents**.
- Every score is **backed by evidence** taken from the call transcript.

The people using it run small businesses: home services, cleaning, law firms, franchises, and
agencies. The person scored is often an office manager, CSR, dispatcher, intake coordinator, or
front desk lead, and has probably never had a call reviewed before. Write for them.

Read these before scoring:

- `references/rubric.md`: the criteria, their 1–5 anchors, the compliance gate, and N/A rules.
  Read it on every run.
- `references/industry-presets.md`: the weights, what counts as a solution, the compliance
  defaults, and sample wording for each industry. Read only the section for the configured
  industry.
- `references/scoring-brief.md`: the fixed instructions and JSON format for scoring calls. Use it
  word for word every run, whether you score the calls yourself or hand batches to subagents.
  Scores only trend meaningfully if every week is scored the same way.
- `references/setup-cards.md`: the two setup cards the owner approves on the first run, with the
  exact format. Read it on the first run, or when the owner asks to change settings.
- `references/business-facts.md`: how to collect, confirm, store and use the business's own facts
  (prices, policies, service area). Read it on the first run and whenever the facts get refreshed.
- `references/sheet-layout.md`: the exact tabs, columns, and formatting for the Google Sheet. Read
  it before writing output.
- `scripts/score.py`: does all the weighted math. Use it, not mental arithmetic, so scores are
  identical from week to week.

## Design principles

1. **Evidence or silence.** Every criterion score comes with:
   - a timestamp,
   - a quote of roughly 15 words or fewer,
   - one line in the form "earned … / capped by …".

   If the transcript can't support a judgment, mark it N/A or low-confidence. Never guess.
2. **No bare numbers.** "Empathy 3/5" teaches nothing. "Empathy 3/5: acknowledged the leak was
   stressful, then talked over the customer twice while she described the damage" teaches
   something.
3. **Score against the anchors, not against the week.** A slow week does not make a 3 into a 4.
   If scores drift up or down with call volume, the trend line becomes meaningless, and the trend
   line is the main reason to run this weekly.
4. **Transcripts carry words, not voices.** Judge tone from word choice, interruptions, and how
   the customer responds. Don't claim things only audio would show, like warmth, pace, or sighs.
   Where tone is ambiguous, say so and keep the score near the middle.
5. **Coach behavior, not outcomes.** A rep controls whether they offered a specific arrival
   wind

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 8 — file references are metadata, not package contents.