The go-live date does not move
Sign-offs, adaptations and layout have to be ready on the agreed date. A rollout project cannot slide into next quarter just because development happens to be at capacity.
ERP for software vendors: customer requests and your own standard in one release cadence.
A software vendor sells licences, and with them the promise that the software stays current. teamspace holds customer orders, release planning, support and recurring billing on one basis. So you know how many development hours are left before the next release, before you promise a date.
Three open fronts at once
The rollout is pushing towards a fixed date, the licence count keeps moving, the release has to be tested.
Anyone building their own product keeps three things open at the same time, and each follows its own rhythm. How that can be ordered we describe first hand: we are in it ourselves.
The licence count keeps moving
Seven licences are added, five fall away again, and the next invoice still has to be right. Anyone piecing the current figure together from individual documents bills late or bills wrong.
Every change to the standard has to be tested
Whatever goes into the software ends up with every customer. Testing only works in batches, not per individual request, and that is precisely what the release cadence hangs on.
Two clocks
Development follows the release, the rollout follows the customer.
What project software assumes
- Every customer gets their own project and their own date, including for the product.
- Whatever has been sold gets built; the order of work sorts itself out.
- Revenue comes from the project and ends with sign-off.
- Support is a side issue after go-live.
Daily life with your own product
- Whatever is built into the product runs in the release cadence, no matter which customer it came from.
- Paid customer requests compete with your own roadmap for the same hours.
- Rollouts run alongside, per customer, with their own date and their own fee.
- Licences, maintenance and support run on regardless of both, and carry the revenue.
From our own house
“Without teamspace we could not run our business. We build software ourselves, and for all our administrative processes we use teamspace, no other system.”
Thorsten Lenk Founder and CEO of 5 POINT AG
From invoicing through release planning to the support ticket. What that looks like day to day is shown in the first-hand account further down this page.
From sale to delivery
Sell, schedule and ship, with no break in between.
A software vendor holds three things at once. In teamspace they sit on one data basis.
The order becomes the work package
Once the adaptation is sold, the order follows in one click, and from it the project with its work packages. What the customer paid for stays attached to the package until it ships.
The release date is a milestone
Every delivery date is a milestone with work packages and people attached to it. Whether you ship monthly, every six weeks or twice a year is your cadence to set.
The recurring base bills itself
Licences and maintenance run on as a recurring contract in the rhythm you set. Support beyond the included hours is added on a time and material basis.
The release cadence
Two sources, one capacity, one window after another.
The paid customer request and your own roadmap pull on the same development hours. Both are bundled because every change to the standard has to be tested before it reaches all customers: without fixed windows, testing spirals. You can only decide between things that sit in the same window.
Bezahlter Anpassungswunsch Ein Kunde zahlt für eine Erweiterung und erwartet sie zu einem Termin
Eigene Roadmap Was die Software für alle Kunden aktuell hält, auf eigene Kosten
Q1 v9.2
ausgeliefert Kapazität 700 h
Schnittstelle Kunde Nord 160 h
E-Rechnung Empfang 120 h
Q2 v9.3
ausgeliefert Kapazität 680 h
Rechte-Modell 210 h
Import Altdaten 90 h
Q3 v9.4
in Arbeit Kapazität 720 h
Freeze 24.07., danach nur noch Test
Auswertung Kunde Süd 120 h
Suche im Standard 80 h
Pflichtfeld Steuer 64 h
Q4 v9.5
geplant Kapazität 640 h
Mobiler Zugriff 180 h
Zweite Auswertung Süd 40 h
aus Q3 verschoben
Der Vertrieb sagt keinen Termin zu, den die Entwicklung nicht halten kann: was nicht mehr hineinpasst, steht sichtbar im nächsten Fenster.
The example shows our own cadence with four deliveries a year. Yours might be monthly, every six weeks or twice a year: a milestone in teamspace is a date you set, not a prescribed quarter. And the plan stays movable until the freeze. Good forward planning, not set in stone.
Before you promise
What fits into the next window is settled before the sales conversation.
The expensive promise is the one someone makes before they know the free hours. In the backlog everything sits side by side: whatever has a promised date carries a date, everything else carries a priority. Some of it belongs to a connected project, some stands on its own as a single work package.
- The release feeds off the backlog: the most important items first, until the available hours are used up.
- Available hours up to the cut-off: from the capacities assigned to your people, with leave and absence already deducted.
- The difference is the answer: whatever does not fit moves visibly to the next window, instead of quietly slipping.
If someone calls in sick or an order falls away, that hits the plan immediately, not in the next status report. Until the freeze the planning stays movable; only after it is the window closed, because the test phase begins.
“Time tracking is far simpler and more convenient than in Excel.”
What vendors gain
Cadence, recurring base and support on one foundation.
The release cadence holds, the recurring revenue runs by itself, and support knows which hour is paid for.
Cadence
The date holds because the hours are counted.
Work packages hang on the release milestone, and so does your people's capacity. Both sit side by side before anyone promises anything.
- Every delivery date as its own milestone
- Available hours against required hours
- Leave and absence already deducted
Recurring base
Recurring revenue runs without anyone touching it.
Licence and maintenance fees run as a recurring contract in a fixed rhythm, renew automatically and bill themselves.
- Recurring contract on a monthly, quarterly or annual cycle
- Flat rate with an hour quota, overflow on a time and material basis
- Incoming payments reconciled daily
Support
Every support hour knows its contract.
Requests by email and phone become tickets that carry the promised service level as remaining time. Paid support is booked on the ticket.
- Service level per customer, remaining time as a traffic light
- Time booked on the ticket and billed through the contract
- Open tickets, projects and quotes on the same customer
Between request and version
What gets lost when sales and development keep separate lists.
- A date is promised before anyone knows the free development hours up to the release.
- Small adaptations get built with no order behind them, and never appear on an invoice.
- Support works through hours that have long since exceeded the quota in the contract.
- Work has been done and handed over, but the invoice is still waiting because nobody triggered it.
teamspace keeps order, release plan, ticket and invoice on the same basis, so that work delivered does not end up stranded between two lists.
The path of an adaptation
From customer request into the shipped version.
One continuous path, with no re-keying between quote template, ticket tool and development plan.
- 1
Cost the quote
This is where the real work sits: scope, effort and price of the adaptation. Everything after it follows from here.
- 2
Order and project follow from it
The accepted quote becomes the order, and the order becomes the project with its work packages. No project without an order.
- 3
Queued in the backlog
With a date if one has been promised, otherwise with a priority. The next release draws the most important items from it until the hours are used up.
- 4
Worked off in the sprint
The sprint takes on as many packages as your people's available time allows. How long it runs is your call; ours is two weeks.
- 5
Freeze, then the test phase
After the freeze nothing else enters the window. Whatever is not finished by then sits in the next one. After that comes the testing of everything that goes out to all customers.
- 6
Reported complete, invoice triggered
The person handling it reports the handover. The invoice comes out of the project, without anyone hunting down the line items again.
- 7
Carried into the maintenance contract
The delivered extension runs on within the customer's standing order, with service and licence data on the same contact.
How we run our own house on it
We are software vendors ourselves, and we steer our administration, our planning and our billing in teamspace. In this first-hand account our CEO walks through what that looks like day to day: from the standing order per customer through our quarterly delivery cadence to the ticket with a promised response time. The cadence is ours, not one teamspace imposes.
How do we use teamspace? A first-hand account
Invoicing, order handling, release and sprint planning, support with service levels, HR and sales: a walk through 5 POINT AG's own processes.
Sprint
The sprint is filled with the time that is actually there.
Between the release window and the individual working day sits the sprint. It only holds up if it is filled with the time the team present actually has.
- Before the sprint the team assigns the packages, as far as each person's available time reaches.
- Classic and agile side by side: the same work package can be moved onto a board and worked on there, two views of one element.
- Booked hours flow back into the project's plan against actuals and into the team's utilisation.
By the end of planning everyone knows what to do, and nobody has to work out whether the week even holds that many hours.
First conversation
Tell us about your next release.
A sentence about your cadence and about whatever is currently in the way is enough to start. There is nothing to prepare.
Recurring base
Licences and maintenance bill themselves, without anyone remembering to.
A house with its own product does not have many orders per customer, but one that never ends. It holds the service and licence data, and it issues its own invoice without anyone thinking about it each month.
- The order runs on instead of being closed: as a duration item in the rhythm you set, renewing automatically until someone cancels or pauses it.
- Support is covered up to the quota, and only what goes beyond it is added on a time and material basis. Both on the same document.
When you sell an extension, it gets its own order alongside the standing one. It becomes a project in one click and, once shipped, runs on inside the standing contract.
Licence count
Seven added, five gone, and the invoice is still right.
With resold third-party licences the quantity is a purchasing question. With your own it is the basis of the invoice. Every increase and every cancellation at the customer shifts the amount due in the next period, and if it slips through, nobody notices.
- The figure comes out of the documents: teamspace consolidates the line items from all of a customer's orders into one figure with a cut-off date.
- The movement stays visible: the history shows when the count went up and when it came down.
So the current figure is ready when the next recurring invoice comes round. A systems house asks the same question from the purchasing side; for a house with its own product it is the revenue question.
Comparison
Four tools or one data basis.
A development board does not know the order, and the accounts do not know the work package. Whatever sits in between, someone does by hand.
Feature
Board, spreadsheet, ticket tool, accounts
teamspace
Recommended Development hours available up to the next release
Order and work package belong together
manual
Invoice triggered from the project
Licences and maintenance as a recurring invoice
manual
Support ticket with promised remaining time
Paid support billed through the contract
ZUGFeRD and XRechnung with no extra tool
Hosting in an ISO 27001 certified data centre in Frankfurt
varies
After the invoice
Open items surface without anyone going looking.
Anyone issuing many small recurring invoices cannot watch them one by one. That part the system takes over.
- Daily reconciliation of incoming payments through the banking interface. It checks receipts and does not initiate any payments itself.
- The dunning run is staged: a payment reminder after a grace period, then the further stages with their own templates.
- Unbilled hours and costs can be reported on deliberately, so nothing sits around for months.
The banking interface belongs to the enterprise edition, the dunning run to invoicing.
Who it suits
Which software vendors get the most out of this.
teamspace suits vendors who build their own product, keep developing it and support their customers' day-to-day operation. Three shapes in which that shows most clearly.
Vendors of their own standard software
- Customer adaptations and your own standard in one release plan
- Delivery dates as milestones with resources, in your own cadence
- Licence and maintenance as a standing contract per customer
Providers of software on subscription
- Recurring billing in a fixed rhythm
- Incoming payments and dunning run automatically
- Support with a quota, overflow on a time and material basis
Development houses with customer projects
- No project without an order, almost no order without a quote
- Plan against actuals and contribution margin per project, up to date daily
- External people in the same resource pool as the permanent team
Sales
An enquiry from the website becomes a sales opportunity.
Anyone selling a product usually sells it to many similar customers. What counts then is less the individual conversation than the view across all the conversations under way.
- The enquiry becomes a sales opportunity, together with the contact, if one was not on file yet.
- Duplicate enquiries from the same company stand out straight away, instead of two advisers meeting each other in the middle.
- The funnel shows the stage at which conversations most often break off, and how many quotes lead to a close.
Quote, order, project and the later tickets then all hang on the same customer. Sales opportunities and the funnel belong together in the enterprise edition; customer management itself is included from office upwards.
Scope
Features for software vendors at a glance.
Included in the plan, with no per-module surcharge. A few things belong to the enterprise edition: capacity planning, the sales forecast, the banking interface and the DATEV handover.
Product and release
- Project milestones for release dates, with an early warning date
- Global milestones spanning several projects
- Work packages with plan against actuals and assigned resources
- Classic and agile in the same project, with backlog and sprint
- Milestone trend analysis from the project reports
Order and billing
- Order and project from the quote in one click
- Paid adaptation at a fixed price or on a time and material basis
- Recurring contracts for licence and maintenance fees
- Support contract with a quota, overflow on a time and material basis
- E-invoicing as ZUGFeRD or XRechnung, with no second tool
Operation and control
- Service tickets from email, phone and a web form
- Service level per customer, remaining time as a traffic light, escalation before the deadline
- Capacity planning across teams, with absence netted off
- Time booked to a project, ticket or contract
- Post-costing of the adaptation: sold against actually built
Next step
We speak as one vendor to another.
Show us a customer order that is meant to go into your next release. We will show you how it runs here, through quote, order, milestone and invoice.
Module overview
What borders on planning, recurring revenue and support.
Six areas in which a software vendor's work comes together, from release planning to the recurring invoice.
Project management
Work packages on the release milestone, classic and agile in the same project, with backlog and sprint.
Learn moreCapacity planning
How many development hours are actually available up to the next delivery date.
Learn moreOnline time tracking
The booked hour lands on the work package and becomes the release's plan against actuals.
Learn moreCRM software
The customer with their contract, their service level and everything they draw in licences.
Learn moreService desk software
Enquiries about the shipped product, with a promised remaining time and booking onto the contract.
Learn moreInvoicing software
Licences and maintenance on a fixed cycle, open items in view, e-invoicing with no extra tool.
Learn moreWhat software for software vendors has to do
The release cadence and the standing contract belong in the same system.
Software for software vendors carries three strands on one data basis. Development on your own product hangs on the delivery date. The rollout at the individual customer hangs on their date. Licences, maintenance and support run on regardless of both. That is what separates a software house from a systems house, which resells third-party hardware and licences, and from an IT service provider, who delivers and operates projects for individual customers.
The second difference lies in the revenue. A house with its own product lives off its recurring base: licences, maintenance and support contracts run on whether or not a project happens to be under way. Software that fits carries these as recurring contracts, reconciles incoming payments and bills support beyond the quota on a time and material basis.
The difference from ordinary project software lies in the bottleneck. Anyone planning customer projects plans per customer. A software vendor plans against a finite development capacity that all customers draw on at once. It therefore needs a view in which order, work package, date and capacity show the same picture. That is exactly what decides whether a promised date holds.
Why teamspace
What stands behind the software.
A vendor ourselves, since 1999
We have been building this product out of Darmstadt for over 25 years, self-funded and without an investor. Whoever decides on the roadmap here knows your question from their own Monday morning.
Operated from Frankfurt
Your data sits in an ISO 27001 certified data centre in Frankfurt am Main and is processed exclusively within the EU. The certification is held by the data centre, not by teamspace; we keep that line clean, tenders included.
One system instead of four tools
The request that was sold, the work package in the release, the booked hour and the invoice are the same record seen from four angles. None of it is exported.
Terms
Six terms from a software vendor's working day.
Words that keep coming up between sales, development and support.
- ERP for software vendors
- An application that carries a software vendor's product development and commercial business on one data basis: quote, order, work package, release milestone, support ticket and recurring invoice.
- Release window
- The period up to the next delivery date, bounded by the development hours available until then. In teamspace it is a milestone with assigned resources and work packages. How long the window runs is yours to set: monthly, every six weeks, quarterly or twice a year.
- Work package
- The smallest schedulable unit in a project. It carries planned and actual hours, hangs on a milestone, and can be moved onto a board for agile work.
- Recurring contract
- The order that is never closed: it renews itself and issues its invoice on the cycle you set. For a house with its own product it is the form in which licences and maintenance make revenue.
- Hour quota
- The time included as a flat rate in the maintenance or support contract. As long as it lasts, the work is covered; only the overflow is billed on a time and material basis.
- Service level
- The response time promised in the support contract for the product. It runs on the ticket as remaining time, so support can see what comes first before the deadline is reached.
Other industries
Solutions for other service firms.
teamspace exists for several industries. Here are five alongside the software vendor.
Management consulting
Days of clever people, utilisation across teams and fee invoicing.
Industry pageIT service providers
Projects and ongoing operation, every hour on the right contract.
Industry pageFit
Which software vendors teamspace suits, and which it does not.
Less of a fit
- Pure development teams with no commercial processes and no billing of their own.
- Houses looking for a development environment: teamspace manages the work, not the source code.
- Products with no customer contract, such as purely ad-funded offerings without maintenance and support.
- Solo developers with no team, contracts or support requests.
A good fit
- Vendors of their own standard software with a fixed release cadence.
- Houses whose revenue comes from licences, maintenance and support contracts.
- Providers with paid customer adaptations alongside their own development.
- Vendors with five to 250 staff, from a small team to a grown house.
Common questions about software for software vendors
What is the difference between a software house and an IT systems house?
A software house makes its own product and sells its licences, maintenance and further development. An IT systems house additionally resells third-party hardware and licences, which appear as separate items alongside the work on the invoice. Both run support and maintenance, but the commercial centre is a different one: here the release cadence of your own product, there the mixed business of product and service. More on that in the overview for systems houses.
How do we see whether a customer request still fits into the next release?
The release date sits in the project as a milestone, and both the work packages and the assigned resources hang on that milestone. That puts the sum of required hours next to your people's available hours, with leave and absence already netted off. Whatever no longer fits is visibly moved to a later window. Capacity planning belongs to the enterprise edition; more under capacity planning.
Does this still work if we do not ship quarterly?
Yes. The quarterly rhythm on this page is our own and serves as an example; teamspace prescribes no cadence. A milestone is simply a date you set and to which you assign work packages and people. Whether you ship monthly, every six weeks, twice a year or continuously changes nothing about the mechanics: before every date the sum of required hours sits next to the available ones. Anyone shipping continuously usually works without a delivery milestone at all and plans purely through sprints and capacities.
Does everything really run through the release cadence here?
No, and it should not. Only what is built into the product itself is tied to the release cadence. Rollouts run as separate projects per customer, with their own date and their own team. Licences, maintenance and support run on regardless of both as standing contracts. teamspace holds these three strands on one data basis rather than splitting them across three tools, but it does not force them into a shared rhythm.
Can we work in a classic and an agile way within the same project?
Yes. teamspace supports classic, agile and hybrid ways of working, with the approach configured per project. A work package can be moved onto a Kanban or Scrum board and worked on there; it stays the same element in two views, so booked hours still flow into the project's plan against actuals. A product backlog and sprints are available for this. More under project management.
How do we bill licence and maintenance fees on a recurring basis?
The order is not closed but runs on as a duration item and issues its own invoice, on the cycle of your choice. For a house with its own product this is the revenue form: the recurring base carries you without anyone thinking about it each month. A price increase takes effect in the next period if you wish, so a running cycle does not tip over mid-month; cancellation and pausing also hang on the contract. More under recurring invoices.
How do the support contract and the ticket fit together?
The support contract comes with an hour quota, and the tickets book their time against it. Once the quota is used up, teamspace switches to a time and material basis through the allocation rules, rather than someone having to keep track of it. The ticket also carries the response time you promised that customer, so support can see what comes first. More on service desk software.
Does the invoice really come out of the project?
Yes. When the person handling it reports completion or handover, invoicing can be triggered straight from the project. The line items come from the order and the booked hours, not from a list someone has pieced together again. Unbilled hours and costs can also be reported on, so nothing sits around for months.
Does teamspace check whether our invoices have been paid?
In the enterprise edition the online banking interface reconciles incoming payments daily. It checks receipts and does not initiate any payments itself. If an invoice stays open, the staged dunning run starts, beginning with a payment reminder after a grace period. More on invoicing software.
Does teamspace replace our development tooling?
No, and that is deliberate. teamspace manages the work around development: order, work package, release milestone, booked time, ticket and invoice. The source code, version control and the delivery pipeline stay in your development tools. The link is the work package, which names the same task in both worlds.
How do many small licence invoices reach the accounts?
That volume is exactly what hurts with recurring billing. The invoices are produced on the cycle you set as ZUGFeRD or XRechnung, without anyone opening a second tool, and go on as a batch. Through the certified interface to DATEV Unternehmen online, invoices and credit notes run straight into the DATEV cloud with no CSV file in between; that interface belongs to the enterprise edition. There is no direct connection for Lexware or Sage, where the standard export takes over.
Our customers ask about our operation. What can we tell them?
As a vendor you get asked in your customer's procurement about the chain behind your administration, so concretely: teamspace runs in an ISO 27001 certified data centre in Frankfurt am Main, and processing takes place exclusively within the EU. The certification is held by the data centre, not by teamspace itself; that line is worth keeping clean in a tender. The contracting party is 5 POINT AG under German law, and released documents remain audit-proof in GoBD mode.
We are only twelve people. Is it worth it yet?
You do not need all of it at once. The sensible entry point is where the money sits: billing licence and maintenance contracts cleanly and having the hours on the work package. Release milestones with assigned capacities pay off as soon as more than a handful of developers compete for the same weeks, and the service desk as the customer count grows. Adding to it means configuring, not migrating, and you move between the light, office and enterprise editions without a data move.
Does 5 POINT AG use teamspace itself?
Yes, entirely. Invoicing, order handling, the quarterly release planning and the two-week sprint planning, support with service levels, HR and sales all run in teamspace. What that looks like in detail is described in the first-hand account in the video further up this page.
First conversation
Fifteen minutes to see whether teamspace fits your release cadence.
We go through your delivery dates, your customer orders and your standing contracts. You get a clear assessment, not a presentation.