001 / Engagement
Law & Legal · 9 staff
Triage.

A client-intake bot that filters before the fee-earner picks up.

Service line: Custom Build + AI Build Build: ~6 weeks Engagement: Mid-scope build + Web Care Growth retainer

The brief

The firm — a nine-person solicitor practice running immigration, conveyancing and small-business employment work — was receiving 60–80 enquiries a week across the website contact form, a WhatsApp Business number on the homepage, and inbound email. Each one had to be read, classified by practice area, conflict-checked at a basic level, and assigned to a fee-earner.

Triage was eating roughly twelve hours a week of paralegal time before any matter reached billable hands. Out-of-hours enquiries — meaningful for immigration in particular — were dropping into the Monday queue cold.

The build

A multi-channel intake layer sitting in front of the firm's existing matter manager (Clio). One website widget, one WhatsApp Business webhook, and one inbound-email parser feed a single intake engine, which routes each enquiry through a practice-area-specific qualification flow.

The flow runs a basic conflict pre-check against the Clio contact graph, captures the structured fields a fee-earner actually needs (matter type, opposing party, jurisdiction, urgency, source of referral), and writes a triaged matter record straight into Clio with a draft first-reply. Out-of-hours, the bot sends a holding message and books a callback slot — the firm's response window for new enquiries went from "next working day" to under an hour for 90%+ of qualified leads.

Stack

Next.js widget Twilio WhatsApp Claude Sonnet Clio API Postgres n8n

What changed

  • Paralegal triage time dropped from ~12 hrs/week to ~2 hrs/week of exception review.
  • Out-of-hours capture rate increased materially — every enquiry gets a structured holding response within the minute.
  • Fee-earner first response inside one working hour for 90%+ of qualified enquiries.
  • Conflict-check pre-flagged at intake stage, not when a fee-earner opens the file.
002 / Engagement
Law & Legal · Conveyancing
Assemble.

Lender bundles built, indexed, and validated before they leave the firm.

Service line: Custom Build + AI Build Build: ~8 weeks Engagement: Medium build + AI Build Growth retainer

The brief

A conveyancing-focused practice closing roughly 18–25 files a month. Each file required a bundle of fourteen-to-twenty-two documents — contract pack, local searches, replies to enquiries, signed transfer, completion statement, mortgage deed, ID verification — assembled by hand, indexed, named to the firm's matter-coded convention, and uploaded to the lender's portal.

Two paralegals were spending around six hours per file on assembly alone. Worse, lenders rejected ~8% of bundles for missing pages or signature inconsistencies, which sent the file back to the queue and pushed completion dates.

The build

A document workflow service that watches the matter folder in SharePoint, ingests source documents as they land, and runs each through a structured pipeline: name-mapping to the firm's matter convention, OCR for non-text PDFs, page-count and signature-page validation, and indexed PDF assembly.

Every bundle is run through a checklist verification pass before it's allowed to leave the firm: required documents present, page-count thresholds satisfied, signature pages flagged on signed instruments, completion statement totals reconciled. Anything the pipeline can't validate cleanly drops into a paralegal exception queue with a short reason. Validated bundles upload directly to the lender's portal via API, with a confirmation written back to the matter file.

Stack

Python FastAPI pdfplumber AWS Textract SharePoint Graph API Power Automate Postgres

What changed

  • Per-file assembly time from ~6 hrs to ~45 min of focused exception review.
  • Lender-side bundle rejections dropped to near-zero — every bundle pre-validates required pages.
  • Paralegal capacity redirected to closing-stage client communication, where it earns more.
  • Audit trail for every document touched — useful at file review and at SRA inspection.
003 / Engagement
Accounting & Tax · 7 staff
Track.

A back-office agent that watches every deadline so the partner doesn't.

Service line: Custom Build + AI Build Build: ~5 weeks Engagement: Small build + AI Build Growth retainer

The brief

A seven-person accountancy practice with about 340 active client engagements — corporation tax filings, VAT returns, payroll RTI, Companies House confirmation statements, self-assessment. Statutory deadlines lived in Karbon. Workload routing — who actually had time this week to clear the deadline list — lived in the partner's head.

Deadlines were missed in busy weeks not because the practice didn't know about them, but because the daily reconciliation between deadline pressure and fee-earner capacity was a 90-minute manual exercise the partner kept skipping when client work spiked.

The build

An autonomous back-office agent that reads Karbon's deadline data and engagement statuses every morning, cross-references upcoming deadlines against open-matter workload per fee-earner (with rough hours-to-completion estimates per matter type), and produces a five-minute morning digest in Slack: today's at-risk deadlines, who has bandwidth, which client reminders are queued.

The agent drafts client reminder emails for the partner to review and release with one click — never sends a client-facing communication on its own. It also flags drift: clients whose reminders have been queued for more than seven days, engagements where the fee-earner has gone quiet, and matters where the deadline keeps moving without a written reason.

Stack

Python LangChain Karbon API Postgres Slack webhook Claude Sonnet

What changed

  • Missed statutory deadlines tracked to zero in the engagement period.
  • Partner's daily deadline review compressed from ~90 minutes to a five-minute digest.
  • Client-reminder drafting offloaded — partner releases, doesn't write.
  • Quiet drift surfaced: stuck engagements get flagged before they become awkward client conversations.
004 / Engagement
Recruiting · Boutique search
Productise.

A client-facing portal that turns service delivery into a SaaS surface.

Service line: Custom Build (Large) Build: ~10 weeks Engagement: Large build + Web Care Pro retainer

The brief

A boutique recruiting firm placing around eighty candidates a year across twenty-five-to-thirty active client briefs at any time. Clients were constantly asking the same question — where is the candidate I shortlisted last week? — and the team was spending six-plus hours a week answering pipeline-status questions across email, phone and WhatsApp.

The firm wanted to differentiate from larger search houses on responsiveness, but the responsiveness wasn't scaling. Every client portal product on the market was either built for high-volume staffing agencies or required ripping out their existing ATS.

The build

A multi-tenant client portal — a small SaaS product, owned and operated by the firm — sitting on top of their existing ATS. Each client logs in to see their open briefs, the live candidate pipeline (sourced / screened / interviewed / offered / placed), and the firm's curated shortlists for each role.

An AI layer auto-generates short candidate summaries from CVs and consultant interview notes, so what the client sees is the consultant's narrative, not a raw CV dump. Clients can leave inline feedback on shortlisted candidates ("not for us, the commute") which writes straight back into the ATS as a structured note. The portal replaces an estimated 75–80% of pipeline-status conversations.

The firm now leads sales conversations with the portal — "you'll get a private dashboard for your search" — which has shifted the conversation away from headhunter-fee anchoring.

Stack

Next.js Supabase Postgres (RLS) Bullhorn API OpenAI Stripe (optional) Vercel

What changed

  • Pipeline-status conversation time cut by ~75% — most clients self-serve before they email.
  • Candidate-feedback loop tightened: client feedback writes into the ATS as structured data, not buried emails.
  • Sales differentiator: the portal is now part of the engagement pitch, not an afterthought.
  • Firm retains every line of code — Praxline operates the retainer; the IP belongs to the firm.

Recognise your firm somewhere in here?

If one of these engagement profiles feels familiar, the conversation usually starts with thirty minutes — what you're running today, where the friction sits, and whether a productised retainer is the right shape for it.