How it works
One client event. One delivery state. The right work in the right tools.
Reconcile the signed proposal with the kickoff and build the first-value plan.
A call, request or project event changes delivery.
Athren reads the signed promise and current plan.
It prepares coordinated work and holds every write for approval.
The decision and the resulting work stay on the record.
A signed deal is not a delivery plan.
The handoff below starts with scattered promises and ends with work the customer can see.
- crm
Open the closed deal and find the delivery owner.
- proposal
Pull every promise sales made.
- contract
Check what the customer actually signed.
- kickoff
Find the requirements and dates added on the call.
- projects
Check capacity, dependencies and the current first-value date.
- No system
One promise conflicts with the signed scope, so somebody has to decide.
And then you wait.
- plan
Turn the result into owners, milestones and dependencies.
- email
Draft the implementation plan for the customer.
That is one signed deal. Now count how many of those steps needed a person’s judgement, and how many needed someone to go and look up a thing a system already knew.
7 of those steps fetched something a system already knew. One needed a person.
The same failure repeats throughout delivery.
- A customer asks for custom analytics.
- callscopeprojectcommercial
- Work can begin before anybody checks whether it was sold or priced.
- A blocker moves the first-value milestone.
- project#deliverycalendaremail
- The owner, plan, forecast and customer update can all tell a different story.
If the reason it is still manual is that nobody was allowed to connect the two systems, that is a question about security and control.
Start with the delivery event, not a prompt.
Say what changed on the client, project or call. Athren turns the same words into delivery state and proposed work. You can type them at your desk too.
- Nothing you said is trimmed
- What you said stays attached to the run in full, so the request and the record of it are the same words.
The request screen on a phone. It is 09:28 and the microphone is open: a bar meter moves beside it and seven seconds have been counted. The sentence said so far is set in full, wrapping over as many lines as it needs and cut short nowhere: Compare the signed proposal with the kickoff and build the first-value plan. Two chips beside it say the words are turned into text on the device, and that it asks before writing. Under that is the plan the sentence has already become: read the signed proposal and kickoff, prepare the first-value plan, and create an unsent Gmail draft for the delivery owner and customer, which is the one step marked as needing approval. Along the foot sit a keyboard, the microphone, the meter and a Done button, and below them the five places the product has: requests, approvals, agents, connectors and the ledger.
Nobody supports the system your work depends on.
A handful of systems carry most of the work and are modelled properly. Everything else connects with a key you already hold.
Adding one yourself takes a server address, or a sentence describing the API.
A proposed connection, drawn dashed because nothing has happened yet. It offers two ways in, a server address or a sentence describing the API, and says at its foot that whatever comes in joins the same list of connections as everything else, with the same scope line and the same approval rule in front of every write.
- Your key
- The key stays yours, and it stays where you put it.
- Missing one
- If the one you need is not there, say so and it gets added.
Finish the client call with the work already mapped.
Send one recent client meeting. Leave with the actions, follow-ups and exceptions a person can approve.