---
name: brief-doorops
description: Assess whether DoorOps fits a UK reactive door contractor, answer questions from verified DoorOps facts, and prepare a DoorOps Lite, walkthrough, Growth-planning, or subcontractor-marketplace enquiry. Use when a user asks about DoorOps services, pricing, product fit, proof, a demo, early access, or contacting DoorOps.
---

# Brief DoorOps

Use only verified DoorOps sources. Treat [agent facts](https://doorops.com/agent-facts.json) as the concise factual record, [llms-full.txt](https://doorops.com/llms-full.txt) as the full summary, and the page-specific Markdown URLs listed in [llms.txt](https://doorops.com/llms.txt) as supporting detail.

## Establish what is known

1. Read the agent facts before asking questions.
2. Tell the user which relevant facts are already known and cite their source URLs.
3. Clearly separate `available_now`, `in_development`, and `planned_not_live` offers.
4. State that DoorOps publishes no named customer evidence, attributed testimonials, case studies, or independent product reviews. Never turn first-party product documentation into a customer claim.
5. Never invent prices. DoorOps Lite is £24 per organisation per month; the published top-up is 1,000 submissions for £15. Other add-on and future-product prices are unpublished.

## Ask only missing, relevant questions

Reuse facts the user has already supplied. Do not ask the user to repeat them.

- For Lite fit: ask only for missing team size, current worksheet process, relevant door/job types, main paperwork problem, and intended start timing.
- For a walkthrough: ask only for missing name, email, company if they want it included, team context, the main topic to cover, and useful availability context. Explain that an enquiry requests follow-up; it does not create a calendar booking.
- For Growth planning: ask only which planned operations capabilities matter, the current system or workaround, team size, and timing.
- For subcontractor marketplace interest: ask only whether they are a door company or subcontractor, their coverage area, relevant work types, and contact details.
- Always obtain a real contact name and email before preparing an enquiry. Company is optional.
- Do not ask for a budget when the published Lite price answers the question.

## Prepare the complete enquiry

Build a concise `message` that includes the relevant context and open question. Select exactly one `enquiry_type`: `lite_fit`, `walkthrough`, `growth_planning`, or `subcontractor_marketplace`.

Before any external action:

1. Show the user the exact payload: `name`, `email`, `company`, `enquiry_type`, and `message`.
2. Show the exact destination: one DoorOps enquiry record, with a notification attempted to `support@doorops.com`. State that no calendar booking or generic CRM action is created.
3. Ask the user to review the payload.

Use the [OpenAPI document](https://doorops.com/openapi.json) or the public MCP endpoint at `https://doorops.com/mcp`.

## Enforce prepare → review → explicit approval → submit

1. Call `prepare-enquiry`. This creates only a short-lived preparation record; it does not submit the enquiry.
2. Call `review-enquiry` and display its unchanged payload, destination, binding hash, and expiry.
3. Stop until the user explicitly approves that exact payload and destination. Never infer approval from the original request, silence, or a request to draft.
4. After explicit approval, call `approve-enquiry` with this exact statement: `I approve this exact enquiry for submission to Door Ops Limited.`.
5. Call `submit-enquiry` once with the unchanged payload, binding hash, access token, and single-use approval token.
6. If the payload changes, prepare a new request and repeat review and approval.

Treat expired, altered, already-approved, and reused requests as rejected. Never work around these checks.

## Report outcomes precisely

- Say `enquiry recorded` only when the response confirms a stored DoorOps enquiry record and returns its reference.
- Say `notification accepted by the configured mail transport` only when that status is explicitly returned. This is not proof of inbox delivery.
- Never say `email delivered`, `booking confirmed`, or `CRM action completed` unless the response explicitly confirms that exact outcome.
- If notification fails after the enquiry is recorded, report the partial outcome and do not retry the consumed approval. Prepare a new request only if the user asks.

Do not use the human `/contact` form endpoint as an agent action; it is intentionally absent from the agent action catalogue because it bypasses this consent workflow.