Found something off? Report it here. This helps us fix issues faster during the Briedo pilot.
← Documentation

Implementation

Four ways to implement Briedo.

Each pattern below is a real path through the product, with the same six facts stated for every one: what starts it, what context Briedo receives, what happens inside, what it produces, where the result goes, and whether you can use it today.

No client loginNo SDKSigned connectionsStructured record, not a paragraph
Pattern 1

Hosted client link

Available now

The simplest client-facing implementation, and the one that needs no configuration at all. Send a branded link when you need context only the client has.

/a/<your-workspace-slug>
Trigger
Someone on your team sends the link. That can be after a meeting is booked, while an opportunity is active, or any time additional context is needed — the link is not tied to scheduling.
Input
Whatever the client brings, plus anything already known about them when the link was sent.
Briedo
The client answers a guided conversation shaped by your service’s requirements. Briedo explains terms they do not know, accepts partial answers, follows up where an answer is thin, and stops when enough context exists.
Output
A structured discovery record, a professional brief for your team, and a client recap.
Destination
Your workspace, plus an email to your team and one to the client.
Availability
Available now
Pattern 2

Embedded client discovery

Available now

The same discovery, running inside your own site. One script tag, no SDK, no callbacks.

/embed/v1/widget.js
Trigger
A visitor opens the page you put it on, and starts the discovery there.
Input
Whatever the visitor brings. Nothing is read from the host page.
Briedo
Identical to the hosted link — same engine, same requirements, same record. Only the surface differs.
Output
Identical to the hosted link.
Destination
Your workspace, plus the same notifications.
Availability
Available now
Pattern 3

Existing system → Briedo

Available now

A system you already run tells Briedo that something exists, and hands over the context it already holds. This is the pattern that makes Briedo part of a workflow rather than a separate step.

/api/integrations/inbound/{workspaceId}/webhook.{connectionId}
Trigger
Your system posts a signed request — when a lead is captured, a meeting is booked, a deal moves, or on whatever event matters to you.
Input
The context your system already holds: who the prospect is, their company, and the meeting or record it relates to.
Briedo
Briedo verifies the signature, records that the event arrived, and routes it into the right discovery workflow. What is already known is not asked again — it becomes part of the record, and the conversation covers the gap instead.
Output
A discovery ready to run with context already in it, and in due course the full record.
Destination
Your workspace. Sending it onward is Pattern 4.
Availability
Available now
Pattern 4

Briedo → existing system

Pilot — configured on request

The finished record leaves Briedo for the tool where the work continues, as a signed webhook, a CRM write-back or a project task.

Trigger
A record is reviewed, or a discovery reaches a ready state, depending on how the destination is enrolled.
Input
The finished discovery record.
Briedo
Briedo builds the agreed payload, signs it and delivers it to the destination you configured. Delivery is bounded and retried within limits — it never loops.
Output
A signed event, a set of fields on a CRM record, or one task.
Destination
Your endpoint, your CRM deal, or your project tool.
Availability
Pilot — configured on request

Pattern 1 — Hosted client link

Every workspace has one. Replace the placeholder with your own, which you set and can change under Settings → Branding.

Your public address

https://briedo.com/a/your-agency

When to send it

Whenever you need context only the client can give. Before a first meeting is the most common case, and it is not the only one — teams also send it mid-opportunity, when a brief turns out to be thin, or when a new requirement appears on an account they already have. Briedo is not bound to a booking.

The client does not create an account, and does not install anything.

Pattern 2 — Embedded client discovery

The embed loads from a single script tag. Put the snippet where you want the discovery to appear; the script finds the element and renders into it.

Two things have to be true first

  • The embed is enabled for your workspace, under Settings → Install.
  • At least one origin is on the allowed list. An embed with no allowed origins is refused — that is deliberate, and it is why copying the snippet onto a site you have not listed will not work.

You list the sites allowed to load your embed, as HTTPS origins or wildcard domains, up to ten. Anything not on the list is refused at load.

Two modes

  • Inline — the discovery sits in the page, in the flow of your content.
  • Bubble — a launcher in the corner of the page, opening the discovery over it. Position, icon and label are yours to set.

One snippet is one service. If your workspace offers more than one service, each snippet must name the one it is for, in a data-briedo-service attribute on the same element. On such a workspace a snippet that names no service does not guess: visitors see a calm “not taking new requests” screen instead. The examples below are for a workspace with one service.

Inline snippet

<div data-briedo-widget="your-agency"></div>
<script src="https://briedo.com/embed/v1/widget.js" defer></script>

Bubble snippet

<div
  data-briedo-widget="your-agency"
  data-briedo-mode="bubble"
  data-button-label="Tell us about your project"
  data-bubble-position="bottom-right"
  data-bubble-icon="chat"
></div>
<script src="https://briedo.com/embed/v1/widget.js" defer></script>

The exact snippet for your workspace — with your address and your bubble settings already in it — is generated under Settings → Install. The examples here use a placeholder address.

An older iframe embed pointed at a different address. It still redirects, but it is not the supported way to embed and it will not work without the two requirements above. Use the script snippet.

Pattern 3 — Existing system → Briedo

A signed inbound connection lets anything you run hand Briedo the context it already holds. It is provider-neutral: Briedo knows a connection and a signature, not what is on the other end. That is what makes it work with a CRM, a scheduling tool, an automation platform or something built in-house, without any of them being a named integration.

What it is for

Two things. Starting a discovery from an event in your own system, and starting it with context already in it so the client is not asked what you already know.

Endpoint

https://briedo.com/api/integrations/inbound/{workspaceId}/webhook.{connectionId}

Authentication

Each connection has its own endpoint and its own signing secret, which Briedo generates. Your system signs the request body with that secret and sends the signature and a timestamp as headers. Briedo trusts the signature and nothing else — not the path, not the payload, not the sender’s address.

Signature

X-Briedo-Signature: v1=HMAC-SHA256(secret, timestamp + "." + rawBody)

The secret is shown to you exactly once, when the connection is created or rotated. Briedo stores it encrypted and no screen or endpoint can show it again; if it is lost, you rotate it. Connections are independent, so rotating or removing one never affects another.

What a request carries

An identifier for the event, so a resend is recognised rather than duplicated; who the prospect is; and the record or meeting it relates to. The exact schema, with a working example, is shown beside the connection in Settings — there is no separate credential to fetch and nothing to read here first.

What happens next

A verified request is recorded, and the connection’s routing rules decide what it means for your workspace — which discovery workflow it belongs to, and how its fields map. A connection with no routing rule is recorded and does nothing, which is the correct default: Briedo never guesses which service a lead is for.

What comes back

Accepted requests are acknowledged immediately. A bad signature is refused. A request that arrives faster than the limit is throttled and can be retried. A request Briedo cannot act on is refused with a reason rather than silently accepted — nothing is ever acknowledged and then dropped, so your system can always trust an acknowledgement.

You create, rotate and remove these connections yourself, under Settings → Integrations → Before. No provider is named in that surface, because none is required.

Pattern 4 — Briedo → existing system

A destination is where a finished record goes. Three kinds exist today, and all three are off by default.

  • Signed webhook — the record, signed, posted to an endpoint you run. Anything that can receive JSON can be a destination.
  • CRM write-back — a fixed set of Briedo outputs written onto the deal the discovery came from: Briedo status, discovery coverage, the brief link and the Briedo reference. That set is closed; nothing outside it can be written.
  • Project task — one task opened where the work continues, carrying the context. Nothing is read back.

Configured is not the same as automatic

Creating a destination enrols it in nothing. Sending a record automatically is a separate, deliberate switch — and receiving reviewed briefs and receiving readiness conclusions are two more separate switches, because they are different things leaving your workspace. Nothing is ever sent because something else was connected.

This is a targeted handoff, not a general project-management framework. One task, the fields listed, nothing configurable beyond that.

Destinations are built and running, and switched off by default. We turn them on per workspace — tell us what you want the record to reach and we will set it up with you. Pilot — configured on request

Contact details

After the conversation, the client is asked for contact details. First name and email are always collected; the rest your workspace chooses, and separately chooses whether each one is required.

First nameAlways on
Last nameConfigurable
EmailAlways on
PhoneConfigurable
CompanyConfigurable
RoleConfigurable
WebsiteConfigurable
Estimated budgetConfigurable
TimelineConfigurable
How they found youConfigurable
Company registration numberConfigurable

The company registration number is the identifier company lookups use where Briedo’s registers reach. Without it, a discovery still runs — it simply has less that Briedo can establish on its own.

Which pattern do you need?

They combine. A team can run Pattern 1 on day one, add Pattern 3 when it wants discoveries to start from its own system, and add Pattern 4 when it wants the result to land somewhere else.

  • If you are starting: Pattern 1. It works immediately and needs nothing configured.
  • If discovery should happen on your site: add Pattern 2.
  • If your systems should start it: Pattern 3, self-serve today.
  • If the result should leave Briedo: Pattern 4, configured with us.

Want a pattern set up for your workspace?

Patterns 1 and 2 are waiting in your workspace. Patterns 3 and 4 we configure with you.

Go to your workspace →