Case Studies

The situation

Research briefs were the firm's quiet bottleneck. Preparing a single brief meant a partner or senior associate spending four or more hours searching case law, reading precedents, and assembling the argument structure — supported by three paralegals working on research full time. Client work queued behind it, and the most expensive hours in the firm were going into document retrieval rather than legal judgment.

What was at stake

Partners bill at the highest rate in the firm. Every hour they spent locating precedents was an hour not spent on strategy, client counsel, or new matters. At the firm's volume, research alone was consuming an estimated $180,000 of senior time per year.

What we built

• ▸A research system with access to the firm's full case-law library — over 200,000 documents — that reads a research question in plain language, locates the relevant precedents, and drafts a structured brief with each citation linked to its source.
• ▸A mandatory partner review step: nothing produced by the system reaches a client or a court without a named lawyer reading and approving it. The system prepares; the lawyer decides.
• ▸A complete audit trail. Every brief records which sources were consulted and why, so the firm can demonstrate the basis for any document it produces.

How it rolled out

Weeks one and two covered the document library and security review — the firm's case files never left its own environment. Weeks three to five were spent testing drafts against briefs the firm had already produced manually, with partners scoring the output blind. By week six the system was in daily use for live matters, with the partner review step as the permanent quality gate.

The results

The three research paralegals moved to case preparation, where the firm was understaffed. Partners describe the change simply: research stopped being a scheduling constraint. The firm has since expanded the system's library twice, on its own, using the documentation we handed over.

The situation

The compliance team was the firm's single source of truth for policy questions — and its single point of congestion. Staff across the firm emailed questions about internal policy, regulatory requirements, and procedure; the compliance team searched thousands of documents manually and answered four to six hours later. Regulation prohibited any of this material from leaving the firm's premises, which had ruled out every cloud product they had evaluated.

What was at stake

Slow answers delayed client onboarding, transaction approvals, and audit responses across the whole firm. The deeper risk was inconsistency: under time pressure, different compliance officers occasionally gave different answers to the same question.

What we built

• ▸A private knowledge system installed entirely inside the firm's own building, on its own hardware. Nothing — documents, questions, or answers — ever touches an external network.
• ▸Coverage of all 10,847 policy and regulatory documents the firm holds. Staff ask questions in plain language, in Arabic or English, and receive a precise answer citing the exact document and page it came from.
• ▸A review dashboard for the compliance team showing what is being asked and answered, so they supervise the system rather than answer each question by hand.

How it rolled out

The first two weeks were installation and document ingestion inside the firm's premises, with their IT security team observing every step. Weeks three and four were a supervised trial: the compliance team compared the system's answers to their own before any staff access. General rollout came in week five, department by department, with the compliance team retaining authority to correct or annotate any answer.

The results

The compliance team's role changed from answering repetitive questions to supervising answer quality and handling genuinely novel matters. Answer consistency — one question, one answer, one cited source — turned out to matter as much to the firm as speed. The regulator's audit team was shown the citation trail during a routine inspection and raised no objections.

The situation

One front-desk employee handled every inbound call alongside walk-in patients. During consultations, calls rang out; after 6 PM and on Fridays, they went entirely unanswered. The clinic estimated thirty to forty percent of after-hours calls were lost — and each lost call was a patient who often simply booked with the clinic next door.

What was at stake

For a private clinic, a missed call is a missed booking, and a missed booking is revenue that does not return. The clinic was effectively closed to new business for two-thirds of every day, while paying for advertising that generated calls nobody answered.

What we built

• ▸An AI receptionist that answers every inbound call immediately, day or night, and speaks naturally with patients in Arabic or English — whichever the caller uses.
• ▸Direct connection to the clinic's appointment calendar: it offers genuinely available times, books the appointment during the call, and sends the patient an SMS confirmation before they hang up.
• ▸Judgment about its own limits: medical questions, emergencies, and unusual requests are passed to staff with a recorded summary, never improvised.

How it rolled out

Week one mapped the clinic's booking rules — consultation types, durations, physician schedules, insurance questions. Weeks two and three ran the system in parallel: it answered, but staff monitored every call and could step in. Full operation began in week four, starting with after-hours calls only, then extending to daytime overflow once the clinic was confident in it.

The results

The booking increase came almost entirely from calls that previously went unanswered — evenings, Fridays, and times the desk was busy. The front-desk employee now handles patients in the building rather than juggling the phone. Patient feedback on the Arabic call experience has been strong, which the clinic credits for bookings from callers who prefer not to conduct medical conversations in English.

The situation

Every supplier invoice — PDFs, scans, photographed paper — was read by a person, checked against purchase orders, and typed into the accounting system. The finance team lost over three hours a day to this, and the error rate ran around eight percent: wrong amounts, wrong codes, duplicates. Errors surfaced weeks later as payment disputes and reconciliation work.

What was at stake

Beyond the daily three hours, errors had a compounding cost: supplier disputes, late-payment penalties, and month-end closes that dragged. The team was due to grow with invoice volume — automation was the alternative to a new hire.

What we built

• ▸A processing system that receives invoices in any format, reads them, matches each against its purchase order, and enters verified invoices directly into the company's accounting system.
• ▸A confidence rule: invoices the system is certain about flow straight through; anything unusual — a mismatched amount, an unknown supplier, a possible duplicate — is held for a person to review, with the discrepancy highlighted.
• ▸A complete audit log: every invoice records what was read, what it was matched against, and who (system or person) approved it.

How it rolled out

Weeks one and two connected the system to the accounting software and trained it on a year of historical invoices. Weeks three and four ran in shadow mode — the system processed every invoice but a person verified each entry before posting. Automatic posting was enabled in week five for the invoice types where the system had proven itself, expanding from there.

The results

Month-end close shortened by two days because reconciliation issues stopped accumulating. The planned additional hire was not needed. The finance team's daily involvement is now reviewing the handful of flagged invoices — the exceptions where human judgment genuinely matters.

The situation

Four support agents handled more than six hundred tickets a week, and the same questions — order status, returns, product specifications, delivery times — made up the great majority. Average resolution time was 48 hours, customers escalated while waiting, and the team was burning out on repetition while genuinely difficult cases sat in the same queue as everything else.

What was at stake

Slow support in online retail translates directly into refund requests, chargebacks, and lost repeat customers. The company faced a choice between doubling the support team or changing how routine questions were handled.

What we built

• ▸A support system grounded in the company's actual material: 3,200 product documents, the returns and warranty policies, and live order data — so it answers from facts, not guesses.
• ▸Automatic resolution of routine enquiries: where's my order, how do I return this, does this product fit my use — answered immediately, around the clock, with the relevant policy or order detail cited.
• ▸A clean handover for everything else: when a case needs a person, the agent receives the full history and the customer's details already assembled, instead of starting from scratch.

How it rolled out

Weeks one and two ingested the product library and connected order data. Weeks three and four, the system drafted replies that agents reviewed and sent — building an accuracy record before any customer received an unreviewed answer. From week five it handled routine categories autonomously, with the team monitoring a daily quality sample.

The results

The four agents now work only the cases that need a person — disputes, special orders, complex complaints — and resolution quality on those improved because the queue pressure was gone. Customer satisfaction scores rose in the first quarter after deployment. The company scaled into a new product line without adding support headcount.

The situation

The founder had proven demand for property investment analysis — clients were paying for reports he assembled manually over days. What he did not have was a technical co-founder, a development team, or eighteen months to learn to build software. Investors wanted to see a product, not a spreadsheet service.

What was at stake

Manual delivery capped the business at a handful of clients. Every month without a product was a month competitors could close the gap, and the founder's window with early customers and investors was finite.

What we built

• ▸A complete commercial software product: customer sign-up and accounts, subscription billing, and the analysis engine that turns property data into the investment reports clients were already paying for.
• ▸The analysis capability at its core — the system evaluates properties against market data and produces the structured assessment the founder previously built by hand over days, in minutes.
• ▸An operations view for the founder: customers, subscriptions, usage, and revenue in one place, manageable by one person without technical staff.

How it rolled out

Weeks one and two locked the product scope to what customers had already proven they would pay for — nothing speculative. Weeks three to seven were the build, with the founder reviewing a working version every week and course-correcting twice on report format based on customer feedback. Weeks eight and nine covered billing, onboarding, and launch to his existing client list.

The results

The founder raised his next conversation with investors on the strength of a live product with paying users and recurring revenue, rather than a service business. Because he owns the system outright, subsequent feature development has been done at his pace, with his choice of engineers — including, on two occasions since, us.