Portfolio / Government contracting and enterprise sales
A government buyer doesn't buy promises. They buy the record.
WE PRO INC answers phones, staffs dispatch desks and runs administrative programs behind awarded primes and large enterprises. The previous site described that as a call-answering service. Someone evaluating vendors inside a procurement process is not looking for that: they are looking for whether you are registered, under which codes, for how long, and who picks up at three in the morning. We rewrote the site to answer those questions before any other.
01The brief
The problem was not the service. It was being legible.
WE PRO INC — trading as WeAnswer — had been doing the work for years: night shifts, dispatch, bilingual answering, administrative programs. What it did not have was a way to prove any of it to someone who had never heard of it. Its site spoke the language of services marketing: fast, friendly, available. The buyer it wanted to reach does not speak that language.
A subcontract administrator, a contracting officer or the procurement team at an awarded prime evaluate against a different list: whether the vendor is registered and active, under which codes it can receive an award, whether it has worked inside a prime's framework before, whether the documentation exists before anything is signed, and whether coverage holds on a holiday at three in the morning. The brief was to build the site that answers that list.
What the site had to solve
- 01Make the company verifiable, not just likeable
- 02Separate the prime from the enterprise buyer
- 03Put the credential ahead of the promise
- 04Publish the codes it can be awarded under
- 05Convert without asking for a blind call
- 06Tell a briefing from a quote at the first click
Our role
Positioning and content architecture, visual system, frontend in React on Vite and Tailwind, forms with accessible validation and an anti-spam layer, a PHP endpoint that logs inquiries and hands them to the CRM, and automated deployment from GitHub Actions to the client's host.
02The rule
What decided the order of the whole page.
The credential comes before the promise.
The headline does not say we answer quickly. It says registered, documented, and ready to answer. To its right, before any scroll, sits the vendor snapshot: active SAM.gov registration, UEI TN6ZDJGJNQJ5, 24 / 7 / 365 coverage and the two sites. It is the information a buyer would copy in order to check it independently — which is exactly why it sits where it can be copied.
That inversion — hard fact first, argument second — governs all six sections of the page. Every block ends in something that can be checked outside the site: a registration, a code, a coverage figure. Nothing asks to be believed.
RegisteredDocumentedAvailable
03Entry paths
Four different buyers, four doors.
A service catalogue makes the visitor translate their problem into the vendor's vocabulary. The page does the opposite: it introduces itself by the situation the visitor is arriving from, and only then names the matching service.
The prime that needs a subcontractor.
They hold an awarded vehicle and need a registered, documentation-ready partner to carry the phones, the dispatch desk and the administrative scope. They keep the client relationship; we carry the operation and the paperwork.
Public sector with continuity to hold.
Switchboards and dispatch desks that cannot go uncovered. The argument here is not price: it is redundancy across two sites and a stated answer target.
The multi-site enterprise.
Volume, hours and escalation across several locations at once. They arrive by RFQ rather than briefing, and the form knows it: it asks for volume, timeline and operational scope.
Anyone exploring AI voice agents.
Automation with people behind it. Presented as one more capability of the same vendor rather than a separate product — which is exactly how it gets bought by someone who already has enough on their plate onboarding one new vendor.
04The snapshot
The figures the site publishes so they can be checked.
None of these is a performance promise: they are service parameters and registration facts, published so a buyer can verify them before writing. They were read off the page in production.
- TN6ZDJGJNQJ5
- SAM.gov UEI
- 4
- registered NAICS codes
- 24 / 7 / 365
- stated coverage
- < 20 s
- answer target
- EN / ES / TL
- languages answered
- 2
- operating sites
05Classification
The codes it can be awarded under.
NAICS is not an industry label: it is the code under which an entity can surface in a vendor search and receive an award. Publishing them with their official descriptions saves the email where someone asks whether you qualify.
- 561421
- Telephone Answering Services
- 561210
- Facilities Support Services
- 541611
- Administrative Management and General Consulting Services
- 561422
- Telemarketing and Call Center Operations
06The page
Six sections that read like a vendor file.
The headline, the vendor snapshot and the two conversion paths. The gold badge carrying UEI TN6ZDJGJNQJ5 is the only use of gold on the whole site: it is reserved for the credential.
The four situations a buyer arrives from, opened one at a time. Anyone who recognises themselves in one never has to read the other three.
Registration, subcontracting experience and documentation, each with the figure that holds it up: two operating sites, continuous coverage and sustained weekly delivery.
The 4 codes with their official descriptions and, below, entity, UEI and headquarters. This is the table a subcontract administrator copies into their file.
One form, two modes. 8 visible fields, scope checkboxes before any writing, and a promise about what comes next: a capability statement and a proposed agenda, ahead of the call.
07Conversion
The form asks what a contracting officer asks.
A generic contact form asks for name, email and message, and leaves the qualifying work to the first call. This one asks for the agency or contract vehicle, the timeline, the writer's role, and the scope they need covered — ticked before anything is typed. That is 8 visible fields, and each exists because its answer changes who should call back.
The two modes — Capability briefing and RFQ / subcontract — share one form and change what is asked and what is promised. Someone arriving from a prime asks for a briefing and receives a capability statement with an agenda before the meeting. Someone from an enterprise sends a quote request with volume and timeline. One component, two different conversations.
The defence against noise starts in the served HTML: there is a ninth field, `company_website`, that no visitor sees and no screen reader announces. A bot fills it; a person cannot. The rest of the checks happen on the server and are deliberately not detailed here — publishing the back of an anti-spam filter is publishing the manual for getting past it.
What is not published
Credentials, internal endpoints and server configuration live outside the repository and outside this case. The CRM integration is handled server-side, with keys that never enter versioned code.
08The route
From a submission to a qualified opportunity.
What happens between someone pressing the button and the contracts desk holding an opportunity in the CRM. The order matters: the inquiry is stored before delivery is attempted.
Form
Briefing or RFQEndpoint
ValidationLog
Inquiry storedEmail
Contracts deskCRM
Opportunity
- 01
Scope gets ticked
The visitor picks a mode and checkboxes before writing. By the time the message arrives, it is already classified.
- 02
Noise gets filtered
The decoy in the HTML and the server-side checks discard the automated traffic before it costs anyone a minute.
- 03
Stored before delivered
The inquiry is written to the server log before email is attempted. If the mailbox fails, the opportunity is not lost — which is the failure that ruins a lead form.
- 04
Receipt acknowledged
The visitor gets a reference code. It stops being a submission into the void and becomes something they can ask about.
- 05
Delivered
The email reaches the contracts desk and the opportunity enters the CRM, where it is worked like any other.
The diagram is the path an inquiry travels. How many travel it is the client's data and is not published here.
09The visual system
Operations room, not call centre.
The whole category is illustrated with headsets and smiles. That register works against you when the reader is a government buyer: it promises friendliness where reliability is being assessed. The system points the other way.
Near-black, status green, credential gold.
A #07120B ground with a green cast, #74CC48 reserved for action and status — what is active, what is covered — and gold #C9A94A used once per screen, always on a credential. An accent that appears everywhere stops meaning anything.
Sora titles, Poppins reads, mono measures.
Operational data — UEI, codes, coverage targets, section labels — is always set in monospace. It is the register a file is written in, and it separates at a glance what is a claim from what is a fact.
Editorial grid and compact panels.
Hairlines, cards, tables and restrained duotone photography. The page looks like an operations board rather than a brochure, which is the promise the service then has to hold up.
10Delivery
What was built and what is missing.
The site in production is 6 sections on a React frontend compiled with Vite, with the design system centralised in Tailwind tokens, a PHP endpoint of its own for inquiries, and automated deployment: every push to the main branch builds, publishes and checks that the site is still answering.
What is still outstanding gets said just as plainly, because a case that tells only the good half is useless for deciding anything. There is no analytics or error tracking instrumented. There is no uptime monitor beyond the deploy check. Images are served as JPEG, with no automated WebP or AVIF pipeline. Fonts load from Google Fonts rather than being served from the domain itself. And the inquiry log needs a formal retention, access and backup policy as volume grows.
None of that is a hidden defect: it is the next stretch of work on a base that already does what it was asked to do — present the company to a government buyer, let itself be verified, and catch the conversation when it comes.
Delivered
- 01Positioning and content architecture
- 02Visual system and design tokens
- 03React frontend on Vite and Tailwind
- 04Verifiable vendor snapshot and NAICS table
- 05Dual-mode form with accessible validation
- 06Anti-spam layer and inquiry endpoint
- 07Inquiry logged before delivery is attempted
- 08Server-side handoff to the CRM
- 09Automated deployment with a post-deploy check
11The value
What changes when a vendor lets itself be checked.
Stop asking for trust. Start handing over proof.
The site does not claim to be the best answering provider. It publishes its registration number, its codes, its coverage and its sites, and lets whoever is evaluating do what they were going to do anyway: check.
That is the difference between a brochure and a file. A brochure needs a call in order to explain itself. A file lets the buyer get on alone as far as the point where the call is finally worth having.
VerifiableClassifiedOperational
beleafdesign
Would your site survive a vendor review?
If you sell to large companies or the public sector, your site gets read with a checklist in hand. We can look at what it answers today and what it should answer before the first email.
Let's talk about your project