Deliver an FDE project
A forward deployed engagement turns what a client asked for into a workspace their team runs on. Scope it so it can be accepted, build it so the permissions hold, hand it over so it survives you leaving.
Scope it so it can be accepted
Most delivery arguments are scoping arguments that surfaced late. The interview, the boundary and the acceptance standard are one piece of work, and all of it happens before anyone opens the workspace.
Interview the people who do the work
Not only the buyer. The person who runs the process every week knows the exceptions, and the exceptions decide whether the App gets used after you leave.
Write the process as it runs today
Who does what, in what order, how often, and where it stalls. This is the document the build gets measured against, so it is worth two pages rather than a paragraph.
Draw the boundary out loud
What is in this project and what is the next one. Naming the second phase explicitly is what stops it from living on as an expectation.
List the deliverables
Rooms, agents, connections, apps and workflows, written down as a list. A client accepts a list. Nobody accepts an impression.
Agree the acceptance runs
The specific flows that have to work, on real data, on the client's own accounts. Write them before you build them, not after.
Name who owns it afterwards
The person at the client who will edit guidelines, add members and read a run history once you are gone. If nobody is named, the project has no ending.
A project is finished when someone at the client can change it without calling you.
Kylon Partner ProgramPermissions and connections first, screens second
A Kylon delivery is a working workspace rather than a codebase: rooms, agents, connections, apps, and the workflows between them. What breaks after handover is almost always access, so access is what gets built and tested first.
Permissions before features
Members, roles, room visibility and what each agent may reach. Give the least access that still finishes the work, and say what happens when someone leaves.
Connections per agent
Mail, CRM, CMS, dashboards and the rest attach to a person or to an agent, with a reason, rather than to the workspace as a whole.
Guidelines carry the working rules
A room's standing instructions are where most of a client's rules end up living, because agents read them before replying. Write them with the client, not for them.
Apps on the data agents already hold
Build the business app inside the workspace, on the same context and records the agents work with, instead of beside it.
Workflows with a run history
A trigger, runs you can point at, and an approval step wherever a person has to sign off. A workflow nobody can inspect is a workflow nobody will trust.
Ship it the same way twice
Rooms, agents, permissions and skills go out through the CLI, so a build you designed once is repeatable on the next client instead of rebuilt by hand.
Finished means they can change it
Acceptance is a session, not a mail. You run the agreed flows on the client's own data, with the people who will own it, and you leave them able to change what you built.
Run the acceptance flows together
The runs you wrote into the scope, on real data, in front of the owner. Anything that fails here is cheaper to fix than the same thing found in month two.
Train the owner, not the room
One named person who can add a member, edit guidelines, read a run history and tell you what changed. Everyone else can learn from them.
Hand over the map
What sits where, which connection belongs to whom, and what to do when a run fails. A page of this is worth more than a day of training.
Agree what maintenance means
What you watch, what they watch, and how a change request reaches you. Ambiguity here is what turns a finished project into an open-ended one.
Book the first change
Something small, a few weeks out. It proves the handover worked and it is where the second project usually comes from.
Keep what you learned
The exceptions and the shortcuts from this build are what make the next one faster to quote and faster to deliver.
You are not starting from an empty workspace
Scenario and industry builds, the product reference, and working templates you can open and adapt rather than design from nothing.
What partners build
Client builds by scenario and by industry, and the three working templates partners start most projects from.
See what to buildTraining and support
The three moves every build repeats, the workspace walkthrough, and the contact you reach while a client build is live.
See trainingProduct documentation
Agents, skills, workflows, apps and the CLI, kept current with the product. Keep it open while you build.
Open docsIndustry CRM Gallery
Eight industry CRM starters on live data, useful as the first screen of a scoping conversation.
Open the galleryWorkspace Quick Start Guide
Rooms, agents and members step by step, with a cheat sheet for the moves you repeat on every build.
Open the quick startPartner toolkit
The program story and the apps you can demo live, for the meetings before the project starts.
Open the toolkitOne client project through acceptance, with a named owner on the client's side.
Bring a project to us before you quote it
Tell us the client and the work, and we will go through the scope and the acceptance standard with you while it is still cheap to change.