Agency operations
Agency platform
The platform a technology services business runs on: enquiries, proposals, project tracking and the public site, in one codebase.
Interface built in code for this case study — not a client screen capture.
01Business problem
A services business loses more time to its own admin than to the work. Every enquiry becomes a document written from scratch, and no two documents agree with each other.
Who feels it
The pattern in small technology services companies is consistent. Enquiries come from four or five places — a form, an email address, a WhatsApp number, a referral, sometimes a phone call — and they all end up in different inboxes. The first response is often the slowest part of the whole engagement, not because nobody cares but because nobody is sure whose turn it is.
The second cost is proposals. Each one is written by copying the last one and editing it, which means scope language, exclusions and payment terms drift apart over time. By the tenth proposal there are four different versions of the same paragraph in circulation, and the one a client signed is whichever copy happened to be open that week.
The third is delivery visibility. Once work starts, status lives in messages. A client asking "where are we" triggers a small internal investigation, and the answer given is usually optimistic because it is assembled from memory rather than from anything recorded.
None of this is a software gap in the abstract sense. It is a gap between a public website that generates interest and an internal process that has no system underneath it.
02Product overview
One codebase carrying the public site and the platform behind it, so an enquiry that arrives on the website becomes a tracked record without anybody retyping it.
Engineering notes
The public site and the internal platform share a deployment and a data layer. That is unusual for an agency site — the normal arrangement is a marketing site somewhere and a CRM somewhere else, joined by copy-paste — and it is the single decision that removes the most manual work, because the enquiry form writes directly to the record that the rest of the process reads.
Proposals are assembled from a block library rather than written from a previous file. Scope sections, exclusion clauses, payment terms and timelines are stored once and composed per proposal, with the composed output frozen when it is sent. Editing a block afterwards updates the library for future proposals and leaves every sent document exactly as the client received it.
Project tracking is deliberately shallow. There are phases with dates, deliverables with states, and a note thread. There is no burndown, no time tracking, no resource allocation. A business of this size does not have a capacity planning problem; it has a "what did we tell the client, and is it still true" problem, and those are solved by different software.
Language handling is the part visitors notice least and I spent the most time on. The public site had to serve content that changes without a redeploy, which meant treating page content as data and building the editing path for it, rather than shipping a site that requires an engineer for a price change.
On AI: there is one place in this platform where a model is involved, and it is narrow — turning a long unstructured enquiry into a short structured summary so the first responder can see what is being asked before reading three paragraphs. It runs after the record is already saved, its output is stored as a suggestion beside the original text rather than replacing it, and if it fails the record is unaffected. Nothing else here is model-backed, and describing the platform as AI-powered would be inaccurate.
03Key features
8 capabilities, of which 1 are model-backed. The rest are ordinary deterministic software, and the distinction is marked so the AI claim stays honest.
The website form, the published email address and the referral path all create the same record shape, with the source recorded. First response time stopped depending on which inbox someone happened to open.
New, claimed, quoted, won, lost, dormant — with one owner at a time. The states are few on purpose: a pipeline with eleven stages gets maintained for two weeks.
A model condenses a wall of text into what is being asked for, what is not specified, and the apparent budget signal. It sits beside the original message, never in place of it.
Scope, exclusions, terms and timelines are stored once and assembled per proposal. The inconsistency that comes from copying last month’s document is structurally impossible.
The composed document is snapshotted at send. Later edits to a block affect future proposals only, so what a client agreed to stays exactly what they agreed to.
Phases with dates and deliverables with states, so a status question is answered by opening a page rather than by asking three people.
Services, pricing structure and case content are data, not JSX. Copy changes do not require an engineer, which is the difference between a site that stays current and one that quietly goes stale.
Which routes produce enquiries, and which of those reach a proposal. Counts of the business’s own records — no attribution modelling, and nothing inferred.
04User flow
The path from the trigger to the finished record, with each step attributed to whoever performs it — a person or the system.
05Architecture
The processing path first, then the layers it runs on, then the constraints that shaped both.
Path through the system
Public form and inbound mail normalise to one enquiry shape. Source is recorded at capture because it cannot be reconstructed later.
Immediate automated reply to the sender. Separate from the summary step so a model outage never delays the only message the client is waiting for.
Structured condensation of the enquiry text, stored as a suggestion with the model and prompt version alongside it. Strictly non-blocking.
Ownership claim and state transition. Unassigned enquiries surface by age, not by size, so nothing sits because it looked small.
Blocks composed into a document, priced, then snapshotted on send with a version identifier.
Phases and deliverables derived from the accepted proposal timeline, with the client-visible view generated from the same records the team edits.
Layers
Why it is shaped this way
06Technical decisions
Every decision here was contested by a reasonable alternative. The trade-off column is the part usually left out.
Why
The enquiry form is the top of the funnel and the enquiry record is the rest of it. Splitting them across two systems guarantees a manual copy step at the most important moment.
Trade-off
The marketing site now inherits the platform’s deployment discipline, so a copy change goes through the same pipeline as a schema change. Acceptable at this size; it would not scale to a large marketing team.
Why
Copy-and-edit is how contradictory scope language spreads. A library makes the terms singular and the composition explicit.
Trade-off
Blocks have to be written to stand alone, which is harder than writing prose in place, and a genuinely bespoke proposal needs an escape hatch — so there is one, and it is used sparingly.
Why
A proposal is a commitment. Rendering it from current blocks would mean the version a client re-opens next month is not the version they read.
Trade-off
Storage of near-duplicate documents, and a fix to a typo in a sent proposal requires issuing a revision instead of editing quietly. That is the correct behaviour and it is occasionally inconvenient.
Why
The only place a model was clearly better than a form field was condensing long unstructured enquiry text. Everywhere else in this platform, deterministic code is more accurate and cheaper.
Trade-off
It would be easy to market this platform as AI-driven and it is not. Being specific about where the model is used costs a marketing line and buys the ability to answer a technical question honestly.
07Challenges
Not the setup work. These are the problems where the first implementation was wrong and had to be reconsidered.
Approach
Rewrote the blocks to carry their own transitions and added per-proposal connective fields, then tested by reading finished documents aloud rather than by reviewing the block list.
Outcome
Composed proposals stopped sounding mechanical. The block library only works if nobody receiving the output can tell it exists.
Approach
Split the output into what was stated, what was missing, and what was inferred — with the inferred section explicitly marked. A vague enquiry now produces a long "not specified" list instead of an invented brief.
Outcome
The summary became useful precisely because it stopped filling gaps. It tells the responder which questions to ask.
Approach
Moved content resolution to build time with an on-demand revalidation path for edits, rather than fetching content per request.
Outcome
Editable content without a per-request cost. The marketing pages render as static output while remaining changeable by a non-engineer.
08Business value
Stated qualitatively on purpose. Invented percentages are the easiest thing to put on a portfolio and the easiest thing to see through.
Operational effect
What would change at scale
09Interface
Dense operational views rather than dashboards. These are used for hours at a time, so the priorities are legibility, keyboard flow and state that is never ambiguous.
Enquiry queue
Unassigned first, ordered by age, with the arrival route on each row.
Enquiry detail
Original message beside the structured summary, with the inferred parts marked as inferred.
Proposal composer
Block library on one side, the composed document on the other, with the send-time freeze indicated.
Project phases
Phase dates and deliverable states — the same records the client-visible view reads from.
The screen above is built in HTML and CSS for this case study. It reproduces the layout, states and vocabulary of the real build without exposing client data, which is why it exists rather than a screenshot. It is evidence of design and of the decisions behind it. It is not a photograph of a deployed system, and no part of it is a capture of anyone else’s product.
10Technologies
Chosen for the shape of the problem, not for novelty. Anything unusual is justified in the decisions section above.
Implementation detail
11Technical preview
This build was delivered to a client, so the source belongs to them and is not republished here in any form — not as excerpts and not as a repository link.
Delivered work
For private client work, contact me for a walkthrough. On a call I can screen-share the build, go through the component structure, the decisions behind the interaction work and the parts that needed rewriting — the same ground a technical preview covers, without republishing a client's property to do it.
Or email directly: surajk86808@gmail.com
What is not published here
Next step
Send the process, the constraints and the deadline. You will get an honest scope, an architecture sketch and a timeline before any commitment.