Twelve hours, measured both ways.

The five systems.

One per bucket, in the order they shipped. Each section follows the same five questions, then the numbers and the threshold it had to clear before it went live. The totals run to exactly 12.0 hours a week.

1. 01

   Lead and inbound triage

   The inbox stopped being a routing table.

   The inbox pattern on the Work page ↗

   What it looked like before

   Thirty messages a day arrived in three places: a shared ops@ mailbox, the website contact form, and a network inbox nobody owned. Two operations staff read every one and decided whether it was a lead, a support question, a billing problem, a partner note, or spam. Priyra took the ambiguous ones and every message from an account that looked large. Replies went out when someone reached that part of the queue, which on a busy Tuesday could be the next morning. An enterprise prospect got the same two-day response as a password reset.

   The broken mechanism

   The routing decision needed account context, not keywords. The same sentence — can we add three more seats? — is a support task from an existing customer and a sales opportunity from a prospect. A rules-only filter misrouted both ways, and a checklist could not hold the rule because the rule depended on the account, not the words. Nobody could say how many messages had been misrouted, because nobody was counting. That is the difference between a busy inbox and a broken mechanism: the failure was invisible until the counter existed.

   What we built

   A watcher on the mailbox, the contact-form webhook, and a scheduled export from the network inbox push each message into one queue table. A preprocessing step strips signatures and quoted replies, normalises the sender domain, and joins the message against the CRM and the billing system to attach four facts: lifecycle stage, ARR band, open tickets, and account owner. A model call classifies the message into one of five routes and returns a constrained object — route, confidence, reason, suggested owner — with no free text. A deterministic layer above the model handles the cases that must never be guessed: known vendor domains, messages tied to an open ticket, and any account above $150k ARR. Routing writes a task in the ticketing system or a deal task in the CRM, sets an owner, and drafts a first reply for the two lowest-stakes routes.

   Guardrails and escalation

   The system never sends mail. Drafts are created as drafts; a person sends them. It refuses to decide refunds, contract terms, security questionnaires, and anything from a customer flagged at risk — those go straight to a person with the context attached. Any classification below 0.8 confidence, and every enterprise account, lands in an exception queue reviewed twice a day. The queue raises an alert if it holds more than six items or if anything has waited four business hours. Every message row keeps the raw headers, the model version, the classification, the confidence, the rule that fired, and any human override; the override becomes a labelled example in the next week's test set.

   How the saving was measured

   The queue table records received_at and first_human_action_at. The weekly view counts the messages a person had to read and decide, and sums the minutes recorded against each. In the baseline, that was every message: about 6.0 hours a week across two people plus the messages Priyra handled. After routing went live, the counter only advanced for the exception queue, the enterprise route, and any message a person pulled back. The four-business-hour response target is measured from the same timestamps, so speed and volume share one instrument rather than two opinions.

   Before

   6.0 h

   After

   3.0 h

   Saved

   3.0 h

   To go live

   Routing had to reach 92% accuracy on a 200-message set labelled by the team, with zero enterprise leads auto-routed to a low-priority queue, and a median first human action under four business hours. It had to beat the manual baseline on misroutes, not only on time. It cleared the accuracy bar at 94% and the enterprise rule at 100%.

2. 02

   Weekly reporting pack

   The Monday pack assembled itself before she opened the laptop.

   The reports pattern on the Work page ↗

   What it looked like before

   Every Monday, Priyra and a finance analyst built the pack that went to the board and the leadership team: ARR and MRR movement, churn, pipeline, support volumes, onboarding status, and a page of commentary. The numbers came from Stripe, the CRM, the product database, the support tool, and a spreadsheet of onboarding milestones. It took about five and a half hours across two calendars. Most of that was copying figures between tabs, checking that Stripe and the product database agreed, and rewriting the commentary on Monday morning because the numbers had moved overnight. The Tuesday board meeting set the deadline, so the pack was always built under it.

   The broken mechanism

   The pack mixed two jobs. Assembling the numbers is mechanical; explaining them is a judgement call. The mechanical part failed because each source had its own definition, timezone, and lag, and a template could not decide which number was authoritative when two disagreed. The commentary was rewritten every week because it was written against numbers that were still moving. A better checklist would have made the disagreement more organised, not smaller. The failure was the absence of one agreed definition per metric, not the absence of effort.

   What we built

   A nightly job materialises one table with a single agreed definition per metric: ARR as the sum of active subscription MRR, churn on a 30-day trailing window, pipeline by stage, and so on. On Monday at 05:00 a job pulls the week's movement, compares it against the prior week and the same week a year ago, and flags anomalies such as churn above 1.5 times the trailing eight-week median. It writes one structured input row. A model call drafts the commentary from that row only. Every figure in the prose is a substitution from the structured fields; the model cannot introduce a number. The output is a draft in the house format plus a Markdown copy for the archive.

   Guardrails and escalation

   A validation gate reads the draft, extracts every numeric token, and fails the run if any figure is not in the structured input. The gate also fails if a metric is missing or an anomaly is unflagged. The model is not allowed to smooth, project, or round; it can only reference what the job computed. The draft is never sent. Priyra reviews it on Monday morning and edits the narrative herself. Each run stores the input snapshot, the model version, the validation result, and a diff of her edits. A gate that is always bypassed is not a gate, so the pass rate is logged weekly.

   How the saving was measured

   The warehouse records the run start and finish and the hash of the input snapshot. Human time is counted from two places: the one-hour calendar block Priyra keeps for review, and the analyst's time against the reporting ticket in the ops log. Before, the two calendars showed 5.5 hours a week on the pack. After, the counter covered the review hour, the analyst's exception checks, and the occasional definition fix: 3.1 hours. The validation gate's pass rate and the count of editorial edits are logged separately, because a draft that needs a full rewrite has saved formatting time and not judgement time.

   Before

   5.5 h

   After

   3.1 h

   Saved

   2.4 h

   To go live

   The pack had to match the hand-built pack for every figure on two consecutive Mondays, with the validation gate passing, before the analyst stopped building it by hand. It also had to detect one seeded anomaly the team planted in the data. It passed the figure check and the seeded anomaly, and it failed the first gate run because a footnote number was not in the structured input — which is exactly what the gate is for.

3. 03

   Approvals and document generation

   Approvals stopped waiting on whoever noticed.

   The ops pattern on the Work page ↗

   What it looked like before

   Requests for spend, vendor onboarding, contract review, and new-hire setup arrived by email or in a message thread, in no particular format. Priyra approved most of them, but only after asking for the missing information that should have been there the first time. The same three documents — an SOW, a vendor security summary, and an onboarding checklist — were rebuilt from scratch every time. Nobody could say what was waiting on whom. The work was small and constant: four hours a week, rarely in one block, always interrupting something else.

   The broken mechanism

   The bottleneck was not the decision. It was that the request arrived without the facts the decision needed, and the chase for those facts was manual. A checklist sent to the requester did not fix it, because people filled in the checklist after the fact and the approver still had to verify each line. The documents were rebuilt because the source data lived in three systems and a person was the join. Automating the approval click would have moved the same chase around; the fix had to be the schema and the joins.

   What we built

   One request form, a small internal page, with a fixed schema per request type. Submitting it creates a row with a status. A rules layer checks the request against policy: spend under a threshold in the requester's budget, a vendor already approved, a standard contract template. If everything passes, the system generates the document from the request row plus the CRM and finance records, files it in the right folder, and moves the status to approved. If a fact is missing, the system asks the requester for that one fact and re-enters the queue; it does not send the request to Priyra until the schema is complete. A separate queue holds anything the rules cannot clear.

   Guardrails and escalation

   The system refuses to approve anything that touches pricing, headcount, legal terms, or a new vendor it does not already know. It cannot sign, send externally, or change a contract clause. Any request that mentions a regulated data category or a non-standard liability term is routed to a person and flagged. The audit trail stores the request row, the policy checks with their inputs, the generated document hash, the approver, and the time from submission to decision. Documents are versioned; the generated file is never overwritten. Human decisions stay with every exception, every request above the spend threshold, and every contract that is not the standard template.

   How the saving was measured

   The request table has submitted_at, ready_at, and decided_at. The weekly counter sums the minutes between submission and ready, and between ready and decided, per request type, and counts how many requests needed a chase. In the baseline, the chase and the rebuilding were the four hours. After, the counter only advanced for exceptions and for the standard decisions Priyra still made. The time from submission to a complete request fell from about two days to under four hours, which is the number the finance team actually felt. Counts come from the table, not from anyone's recollection.

   Before

   4.0 h

   After

   2.4 h

   Saved

   1.6 h

   To go live

   It had to clear 90% of standard requests without a person touching them and produce documents that matched the previous hand-built versions field for field on a 30-document sample. It also had to bring median submission-to-ready below four hours. The first build passed the document check and failed the chase counter, because requesters emailed Priyra directly instead of using the form. The form went into the mailbox auto-reply in week five, and the counter moved.

4. 04

   Market and competitor digest

   The reading nobody had time for, triaged and cited.

   The research pattern on the Work page ↗

   What it looked like before

   Priyra read for the job: a dozen industry newsletters, three competitor alert feeds, a channel of shared links, and the analyst notes the sales team forwarded. She read to stay credible in board and customer conversations, not because anyone asked her to. It took six hours a week and much of it was the same story in three places. When she travelled, the reading did not happen, and by the next week the pile was unreadable. The reading list was also the first thing to be cut when something urgent arrived, which meant the most valuable part of it arrived late.

   The broken mechanism

   The reading was not one task. It was collection, de-duplication, triage, and interpretation tangled in the same hour. The cost was not only reading time; it was that the reading happened late, so the useful signal reached a customer conversation after the fact. A faster reader would only have read the duplicates faster. The mechanism needed a stage that removed repeats before a person saw them, and a source of record so an item could be reopened without re-reading the pile.

   What we built

   A scheduled collector pulls an allowlisted set of sources: newsletters by mailbox rule, competitor feeds by RSS, and the saved-links channel. Each item is reduced to its text, de-duplicated against the last 60 days by near-duplicate similarity, and tagged by topic and source reliability. A model call writes a two-sentence summary per item and extracts the claims with a source link attached. A ranking step orders items by relevance to a fixed set of business themes — pricing changes, product launches, funding, regulation, hiring signals — and writes one page with a short list of items that may need a response. The digest is not a report; it is a reading list with the repeats removed and the yes/no left to her.

   Guardrails and escalation

   The system cites a source for every claim and refuses to state an implication or a recommendation. It does not summarise paywalled content it cannot access; it flags the headline only. Anything below the relevance threshold is dropped, and anything the classifier marks as a rumour or unverified is labelled as such. The digest is capped at one page so it cannot become another pile. Every item keeps its source URL, the similarity cluster it belonged to, and the score it received, so a dropped item can be explained rather than mourned.

   How the saving was measured

   The collector logs items in, items deduplicated out, and items kept. The weekly counter measures the hours Priyra spends reading the digest and the hours she spends reading raw sources, separately, because the whole point was to move time from raw reading to the digest. In the baseline, both were the same six hours. After, the digest read was 2.8 hours and raw reading was near zero unless she chose to open a source. The duplicate-removal rate is logged per week and settled between 40% and 55%, which is the finding the audit predicted.

   Before

   6.0 h

   After

   2.8 h

   Saved

   3.2 h

   To go live

   It had to drop duplicates without dropping a competitor pricing change, keep the digest to one page, and hold a source link on every claim. On a two-week trial it missed one relevant item the team had seen, which was enough to keep a weekly human sweep of the source list for the first month. After the sweep found nothing for three weeks, it was retired.

5. 05

   Invoice reconciliation

   Month-end matching down to genuine exceptions.

   The reconciliation pattern on the Work page ↗

   What it looked like before

   Every month end, a bookkeeper and Priyra's operations lead matched purchase orders to invoices to payments line by line. The average week was 4.7 hours, most of it in the last three days of the month. The work was checking three lists against each other and writing down the differences. Two errors reached payment in the previous year, both caught late by the vendor rather than by the process. The whole task waited on two people's calendars, so a holiday week pushed it into the next month.

   The broken mechanism

   The matching rule was simple in the common case and impossible to write down in the edge cases. Partial payments, credits, currency, and multi-line invoices each needed a different comparison, and the rule depended on the vendor's own history. A template could not hold it, and a person could not apply it consistently under time pressure at month end. The reconciliation also had no memory: every month the same vendor's same quirk was rediscovered. The mechanism failed on memory and consistency, not on diligence.

   What we built

   Invoices arrive in a dedicated mailbox or through the finance system. A parser extracts header fields and line items with a confidence per field. A matching engine compares against open purchase orders and recorded payments under rules that are specific per vendor: tolerance band, currency handling, partial-payment logic, and credit-note treatment. Exact matches are written to the ledger and marked reconciled. Everything else goes to an exception queue with the evidence assembled: the three documents, the fields that differ, and the vendor's prior handling. A model call drafts a plain-language reason for each exception, never a decision. Human decisions stay with every mismatch, every payment over a fixed threshold, and every first-time vendor.

   Guardrails and escalation

   The system never releases a payment. It writes a reconciliation record and a status; a person approves the payment run. It refuses to match across currencies without a same-day rate, refuses to net a credit against an unrelated invoice, and refuses to touch an invoice flagged as disputed or under legal review. The audit trail stores the parser confidence, the rule-set version, the three source documents, the match decision, and the approver. A mismatch approved with an override is recorded and becomes a rule candidate, so the same quirk is answered by the system the second time.

   How the saving was measured

   The reconciliation view has invoice_received_at, matched_at, and approved_at. The weekly counter sums the bookkeeper's and operations lead's logged minutes on reconciliation tasks and counts the exceptions a person had to open. In the baseline, the counter showed 4.7 hours. After, it showed 2.9 hours, nearly all of it in the exception queue. The count that moved most is the exception rate: from treating every line as an exception to roughly one invoice in six, and falling as vendor rules were added.

   Before

   4.7 h

   After

   2.9 h

   Saved

   1.8 h

   To go live

   It had to match to the penny on a sample of three months of historical invoices with no false match, and hold every genuine mismatch for a person. A false match is worse than a missed one, so the bar was zero. It passed the historical sample after two rebuilds of the currency rule, and the first live month produced eleven exceptions against an expected nine.