First-party case study · Sales Operations

How AlchemyWorkflow built its own inquiry-to-opportunity workflow.

AlchemyWorkflow used its own operating model to connect website demand capture, server-side validation and an AWS Lambda webhook into one consistent sales intake process.

BeforeUnstructured inquiries risk losing business context between the website and the sales conversation.
ImplementedA single structured payload moves from the website to the backend webhook.
Operational valueDiscovery begins with the customer’s original systems, team and automation goals already captured.
01

Business context

AlchemyWorkflow is sold through consultation rather than public self-service signup. A qualified engagement begins with process discovery, followed by solution design, a statement of work, dedicated tenant provisioning and implementation. The website therefore needs to collect more than a name and email address: it must capture enough operational context to support a useful first conversation.

02

The challenge

A generic contact form would force the sales and implementation teams to ask for the same information again. It would also make it difficult to understand whether the request concerns marketing, sales, customer operations or a cross-functional process.

  • Preserve the prospective customer’s original description.
  • Capture current systems and team context.
  • Keep the browser isolated from the external webhook endpoint.
  • Return clear success and failure feedback to the visitor.
  • Support the existing sales-led delivery model rather than creating an unqualified self-service account.
03

The implemented solution

The website uses a dedicated Contact Sales page with structured fields for company, work email, job title, team size, primary operating area, current systems and automation goals. The browser submits the form to an internal Next.js route. That route validates required fields, adds a source and timestamp, and forwards the normalized request to the AWS Lambda Function URL.

Why the server-side proxy matters

The external webhook URL is not called directly from the browser. This avoids making the front end responsible for cross-origin behavior and creates a controlled point for validation, rate limiting and future security controls.

04

The workflow

1

Website inquiry

A prospective customer submits business context, current systems and the process they want to automate.

2

Server-side validation

The Next.js API checks required fields and prevents incomplete requests from being forwarded.

3

Lambda webhook delivery

A server-side request sends a normalized payload to the configured AWS Lambda Function URL.

4

Qualification context

The payload preserves company, team size, business area, current systems and automation goals.

5

Sales and implementation handoff

The inquiry is ready for discovery, solution scoping and SOW preparation without re-entering the original context.

05

Operational controls

Required field validation

Name, work email, company and automation goal must be present before the request is accepted.

Normalized payload

The backend adds a consistent source identifier and submission timestamp.

Server-side delivery

The Lambda Function URL is called from the application backend rather than the visitor’s browser.

Visible submission state

The visitor sees loading, success and error feedback instead of an ambiguous form submission.

Consent capture

The form requires explicit agreement before the request can be submitted.

Implementation-ready context

The original systems and desired process remain attached to the inquiry for discovery and scoping.

06

Current outcomes

This implementation is intentionally described without invented performance statistics. The current, verifiable outcome is an operationally complete intake path in the website codebase.

  • A visitor can submit a structured enterprise inquiry.
  • The request is validated by the application backend.
  • The normalized request is forwarded to the configured Lambda webhook.
  • The business context needed for discovery is included in the payload.
  • The website provides explicit success or failure feedback.

Response time, conversion rate and sales-cycle metrics should be published only after production traffic has been measured over a meaningful period.

07

Next implementation steps

The workflow is designed to expand without changing the website’s core intake experience.

  1. Persist inquiries in a CRM or lead store.
  2. Add duplicate detection and account matching.
  3. Introduce qualification rules based on company and operating context.
  4. Assign an owner and create a follow-up SLA.
  5. Notify the sales or implementation team through the selected channel.
  6. Report on submission volume, response time, qualified opportunities and SOW conversion.
“The first workflow we built was our own: preserving customer context from the first inquiry through the start of solution discovery.”

AlchemyWorkflow product implementation note

Apply the same model

Turn your own intake process into a governed workflow.

Bring one recurring process, the systems involved and the handoffs that currently slow it down.

Request a consultation